CCB Study Data Validation Rules Charter

From PHUSE Wiki
Jump to: navigation, search

Change Control Board (CCB) for Study Data Validation Rules – Charter


The purpose of the Change Control Board (CCB) is to deliberate on change requests provided by the stakeholder community to publicly available validation rules that are used to validate standardized study data. The CCB will also manage and coordinate the vetted changes.


Study data standards support the exchange and analysis of study data (1). One of the benefits of standardized study data is that it supports the automation of standard data quality checks, or validation rules. In general, there are two types of validation rules. Standard Compliance rules help ensure that the data conform to the data standards. Data Quality rules help ensure that the data will support business processes that rely on the data (i.e., support meaningful analysis of the data).

Once a data standard is defined, the standard compliance rules are rather static. They are not expected to change substantially unless the standard itself changes. Data quality rules may evolve over time as new analysis requirements are identified and incorporated into data validation processes.

Currently, there is no recognized process or governance structure to manage changes to the validation rules. Some rules may be retired if they are found not to be useful or no longer applicable. Some rules may need to be refined so they are more useful. New rules also need to be added over time.

(1)The term "study data" as used in this document refers to both the raw data collected from experimental subjects (both human and animal) in a study as well as derived data (i.e., the data calculated from the raw data).
2 See


The scope of the CCB is to manage, coordinate, and approve changes to publicly available validation rules for standardized study data.

The scope of the CCB does not include the creation or modification of existing rules, or the evaluation of the usefulness of the rules. Rather, the CCB evaluates change requests provided by the stakeholder community.


The CCB consists of three voting members and a project manager.

• One member is appointed by the FDA,
• One member is appointed by the Clinical Data Interchange Standards Consortium (CDISC)
• One member is a volunteer from the regulated industry (e.g. regulated product manufacturer) or service provider (e.g. contract research organization) that is selected by the other two members
• The Project Manager is a volunteer from any of the interested stakeholder community, and is selected by the three voting members

Each voting member serves for three years. Membership is staggered for continuity so that one member is up for re-appointment each year (2). The project manager serves indefinitely at the discretion of the voting members.

One of the voting members serves as Chair for one year. The three voting members select the Chair.

Any number of observers (non-voting members) is permitted at the discretion of the Chair.


1. Chair

• Coordinates the activities of the CCB
• Runs the meetings
• Serve as the primary spokesperson to the stakeholder communities regarding the validation rules

2. Project Manager

• Supports the activities of the CCB by managing schedules, communication, and meeting minutes
• Tracks and manages change requests and documents the CCB’s recommended changes to study data validation rules
• Documents differing opinions
• Works with the appropriate webmaster(s) to get approved changes posted on a publicly available website

3. Voting Members

• Possess knowledge and experience in the validation of standardized study data
• Serve as active participants on the CCB

(2) At CCB start-up, one member serves for one year, another member serves for two years, and the third member serves for three years, by mutual agreement.


1. Guiding Principles

The CCB operates under a spirit of transparency and consensus. Transparency is supported through the publication of all documents (e.g. change requests, decisions).

2. Change Requests

Any member of the stakeholder community can propose a change to the publicly posted validation rules. It is the responsibility of the requester to vet the change request within his/her organization to ensure some level of consensus.

The CCB reviews the change request, solicits public comments, and makes changes to the resource. The CCG will consider:

• The scope of the change requested
• The timing requested for implementation
• The proper versioning of the new content

Once approved the CCB updates and posts the new set of validation rules. See 6.3 Decision Making Process for more details.

3. Meetings

The CCB meets at the discretion of the Chair as needed to address change requests. Meetings are typically teleconferences. The project manager, in consultation with the Chair, creates the meeting agenda. The project manager circulates the agenda and any other relevant materials at least four (4) days in advance of the meeting. The Chair runs the meeting and the project manager takes the minutes. Draft minutes will be sent to the CCB for comment. Final minutes will be archived on a network resource available to all members (e.g. PhUSE wiki).

4. Decision Making Process


1. A requestor completes submits a change request (CR) to the project manager. The CR contains the following minimum information:

• Requestor
• Date of request
• Urgency (routine/expedited)
• Type of change (new/modify/delete)
• Rationale for change
• Description / definition (e.g. pseudo code using rules definition best practices)
• Standard / Version / Domain / Rule identifier (for existing rules)
• Rule categorization (business vs. technical)

2. The CCB does an initial assessment. Reasonable requests are posted for a two-week public comment period. Corrections (e.g. bug fixes) bypass public comment.

3. The CCB reviews the public comments and makes a disposition. Expedited changes are posted immediately. Routine changes are enacted at the next scheduled release. Scheduled releases are typically every six month, subject to change by the CCB. Expedited changes (typically corrections/bug f

General discussion

Please use the Discussion Tab.

Back to Working Group 1:Data Validation and Quality Assessment Homepage

Last revision by Hany.aboutaleb,07/13/2012