Clinical Data Management – Processes Before Data Collection

Clinical Data Management – Processes Before Data Collection. A good data management method involves the defining of processes for collection of data and its management even before we begin to collect data. The processes involve identifying how data needs to be collected and what clinical data management system would be used to manage the data. If the CDMS needs to be purchased from the vendor, then the necessary actions that are needed are decided. If the system is to be built in-house, then it is developed before the collection begins. Also before the collection of data the procedures for the patient recruitment, enrollment, screening, randomization and dispensation of the treatment are decided.

Before the data is collected it is essential to have a CDMS in place, for hybrid studies and to make sure that the CDMS has been validated and the study has been designed in it. In Oracle Clinical, the study design involves the following:

• Defining the Programs (Synonymous with therapeutic area)
• Defining the Project (Synonymous with Indication)
• Defining a Study (Synonymous with Drug being tested)

While defining the study we create enter the study sites and investigators and link the sites to the study. We also add the phases in which the study will be completed (Termed as Intervals), the Treatment Pattern, Patient Positions and Visits to be conducted in the study (Termed as Clinical Planned Events –CPEs).

During the study incomplete, missing, inconsistent or out of range data may come in. All of it cannot be checked manually as this takes time and is not error free. Validation Procedures are electronic checks designed to check the entered data for errors and automatically raise discrepancies that need to be queried to the investigator via the DCFs.

Selecting a Clinical Data Management System (CDMS)

The choice of the CDMS depends on the size of the CRO that would be managing the data and the strategies of their scalability. Typically the three categories of CDMS to choose from are:

• In-House CDMS
• Vendor supplied CDMS
• Open Source CDMS

The type of CDMS adopted as said earlier depends upon the strategy, growth plans of the CRO and most importantly the need of the sponsor, for whom they are conducting the trial.

Some key points that are involved in the decision making process while selecting a CDMS are:

• Date of start of the project
• Sample size
• Length of the trial
• Complexity of the trial
• Number of participating sites
• Size of the CRF booklet
• Type of the study/ data collected.

The process of selection of a CDMS is thus not an isolated decision and depends on many factors of the trial both clinical and technical. The process of choosing a CDMS has to be matched against what is expected out of it, and thus it has to be decided, what data collection method will be used, paper or electronic CRFs or whether EDC will be used. If the CRFs are being used and they will be scanned and made available (Hybrid System), then the CDMS should have the capability to be integrated with the images from the scanned system etc.

Finally, choosing the CDMS requires the following considerations:

• Cost
• Compliance with federal regulations such as the 21 CFR
• Time required Install, configure  and  train staff
• Type of database and its ability to be integrated to other systems
• Ability to perform blinded double data entry as per necessary guidelines.
• Capability to program checks/procedures to identify incomplete, inconsistent or missing data.
• Ability of the CDMS to integrate with medical dictionaries like MedDRA and WHO Drug, so as to provide coding capabilities
• Support a time-stamped audit trial or any changes to the database as per regulatory requirements
• What are the maintenance/administrative costs/resources required?
• Does the CDMS have documentation to be referred to for training/troubleshooting purposes?
• Number of users that can simultaneously log in and use the system.
• Ability of the system to generate custom reports
• Provisions within the system to ensure logical security through passwords that retire/get locked if not changed regularly.

All these things need to be kept in mind when purchasing a CDMS from a vendor or building one in house.

Choosing Hardware and Software

After choosing a CDMS, the hardware and software (Operating System in this case) should be purchased considering the installation requirements for the CDMS. For example Oracle Clinical is a CDMS which requires an Intel Pentium 4 processor with minimum 2GB RAM and operating system to be Windows 2000 or 2003 Server. It can’t be installed on a hardware having an AMD processor or an operating system such as Windows XP as it is not recommended for that. Thus the choice of the CDMS dictates what hardware should be bought and which operating system should be licensed.

Also the type of collection systems that would be a part of a trial dictates what hardware and software is needed. For example for paper based methods it would be useless to invest money on scanners and OCR/OMR software, however for a trial using hybrid methods where paper CRFs need to be filled up and then scanned and made available centrally, in this case the OCR/OMR software as well as the scanner need to be purchased. Similarly if we are doing an EDC trial then additional PCs need to be bought for those sites that don’t have a computer so as to get them connected with the centralized system.

Also in case the CRFs need to be Faxed, then faxing machine should be made available for the study.

Form and System Design

The quality of a trial depends on the data that is collected in the trial. Thus it is essential to design data collection instruments (CRFs) in such a way that accurate, consistent, complete, necessary data is collected. If the CRFs are well designed, the data collected is apt for proving that the drug is safe and efficacious and hence we get good datasets that can be submitted to the regulatory authorities with better chances to get approval.

Some of the key aspects in developing a good CRF are:

• Identify the major data points to be collected.
• Group related questions into a single section
• Do not include unnecessary questions that would add no value in analysis.
• Lay emphasis on critical variable collected during a study.
• Avoid duplication in collection of data fields (no question should be collected twice, unless it is necessary in the study to collect it more than once)
• Minimize the number of validation procedures to be created across different visits.
• Make responses to the questions more objective type or closed ended. (For e.g. options given as Yes/No for Adverse Event, Male/Female for Gender etc rather than a blank line to be filled up)

The forms within the system should be designed exactly like the CRFs look so as to prevent data entry errors. Range and consistency checks should be used to ensure completeness and accuracy of data.

Thus a combination, of a good CRF and a well designed system, makes the process of data collection and management much shorter, simpler and accurate.

Protocol and System rules

These rules streamline how the trial works, as in the design of the trial. The protocol may contain exceptions and rules such as:

• There will be 7 visits as per the protocol however any number of interim visits may be conducted between any two visits
• The visit 2 will take place 3 days after visit 1; however, it can take place a day before the scheduled date or after.
• The subject can only go to Visit 3 if his Systolic Blood pressure was in the normal range in Visit 2 as defined in the study.

Such rules may dictate how we design our study. Also on the other hand there are system rules which deal with how the system is set up and used. For example, the system only requires a password to be entered once to access the database. There might be other system rules as per liking such as:

• The screens can only be closed with customized button or command
• The verification of the subject is requires to access records
• Log records cannot be deleted for patient data.
• The age of a patient is calculated using his date of birth and Visit date.

There might be many more of such rules, which are specified in the protocol and implemented through system rules, thus allowing a complete control over the proceedings of the study data.

System Installation and Configuration

The process of system installation and configuration varies between CDMS. For in-house CDMS, priorities can be defined as to which modules are crucial to beginning a study and those can be created, installed and configured in the crunch of time. However since a vendor based system such as Oracle Clinical is integrated, it has to be installed all at once to provide all its functions.

During the installation and configuration, certain aspects need to be taken care. Some of them are as follows:

• System should be installed taking care that there are no errors at the end of installations. If there are any errors they need to be documented and rectified before the system can be declared fit for configuration.

• No changes should be made to the code of the CDMS before/during or after the installation.

• The installation process and logs should be documented. Such a documentation showing no more errors are present in the system is called Installation Qualification (IQ).

• During installation and configuration care should be taken if any third part system/tools/applications need to be integrated with the CDMS. For such integrations API (Application Programming Interface) to the application should be used.

• All configurations made to the system should be tested to check whether the system is behaving in a manner that it is intended to work.

The process of installing some CDMS such as Oracle Clinical is a tedious task and a complete clean installation may itself take 3-4 days.

System Validation

Once the CDMS is bought, hardware and software finalized and it has been installed and configured, the next thing to do before using it to collect the data is test whether the system is working as it is intended to do. This process is called system validation.

The process of validation of a system is composed of the following parts:

• Installation Qualification (IQ)
• Operational Qualification (OQ)
• Performance Qualification (PQ)

IQ involves the validation of the system during the time of installation. It involves checking of the installation logs while installing and configuring a CDMS to see if there were any errors during any step and then rectifying these errors until all the errors have been taken care of, resulting in a clean install. The result of this is an IQ document which is nothing but a printout of the installation process consisting of codes that had run at the backend during installation and showing success in the execution of those codes.

OQ involves validation of the CDMS once the installation is through by checking that the system is behaving in the right way when operated that is if a module of the CDMS is clicked and it is supposed to bring up a window, then that is exactly what it should do. This is the test of whether the CDMS is operating correctly. The result of this is screenshots/document listing the execution of buttons/ procedures within the system and the output of such action, either supplemented by a screenshot or a verbal description of the output. For example:

Action: Clicked on the Launch button

Output: Brought up the login screen

Action: Entered user name and password and hit enter

Output: The system accepted the credentials and logged on the user.

This results in an OQ document listing all the actions and the output. If any output is something it is not intended to be, then the CDMS needs to be tweaked till it gives the right result.

PQ refers to performance qualification. Once the IQ and OQ are completed means the CDMS has been installed successfully and is operating correctly. The PQ tests that once the clinical data is entered into the system its procedures are functioning like they should.

For this we design a dummy study, and create CRFs for that study. We then design this study in the database and do a test data entry such that some of the data points are filled in by valid values and some by invalid values or dirty data. We then see the response of the systems functions to this entry. For example we have designed a validation procedure such that the gender can only be Male or Female. For some patients the data entry is done such that the value of gender is either filled in as Male or Female. For some patients the value of gender is entered as Not Done. For all those patients for whom gender is entered as Not Done, discrepancies should be raised and present within the discrepancy database. This is just one example but PQ involves testing for all functions such as the right forms are being pulled up for the right DCMs during entry etc.  The PQ ensures that the database/ system are ready for use in a live study.

The result of this PQ is a document that outlines the test plan that was used to carry out testing and the results achieved out of that.

Staff Training

It is must that the staff being used to collect and manage the data should be trained on the CDMS and study specific material being used, irrespective of which CDMS is being used.

The training generally involves going through the protocol, CRFs, how to log in to the CDMS, major screens, data handling plan, data management plan and  data entry and review guidelines.

Staff training is not only essential for the staff to perform their day to day functions accurately and efficiently but is also a regulatory requirement as the auditors want to check whether the staff handling the data are qualified /trained.

Thus documentary evidence of the training is maintained in the form of a training log as well as individual training folders.

When any data management site is audited, the training records are checked by the auditors to see whether the people responsible for handling the data are well equipped with the knowledge required to do so. Thus there are trainings for each study which involves reading the protocol, going through the CRF and other study documentation.

On the other hand site staff (CRAs and Investigators) needs to be trained on certain study specific guidelines in a regular trial. For EDC studies additional staff training is required to make the investigators aware of how to use the systems, login and perform data entry etc and all these records are documented for reference when the study is audited/ inspected.

This completes our discussion on Clinical Data Management – Processes Before Data Collection. We hope this helped you get an insight into Clinical Data Management – Processes Before Data Collection.

For a deep insight into the world of Clinical Data Management, subscribe to our Clinical Data Management Knowledgebase

Want a explore a career in Clinical Data Management? Join our Diploma in Clinical Data Management program and kick-start a career in Clinical Data Management and Oracle Clinical.

Already completed a program in clinical data management. Enhance your expertise on the Oracle Clinical software by pursuing our Oracle Clinical Fundamentals program. You can also subscribe for 24×7 access to the Oracle Clinical software for practice.

You may be interested in…