Clinical data management

It is noted several times in this book that the goal of experimental methodology is to provide optimum quality data for subsequent statistical analysis. This is true, but there is also a very important intermediary between data acquisition and data analysis this is the field of clinical data management. In many cases, Data Management and Statistics fall under the same division within a company, and in some cases these tasks are handled by different divisions. Whichever is the case, it is vital to have statisticians involved in all discussions regarding database development and use. 

Ensuring that all of these data are in the database correctly is an enormous task, and one that is covered in this chapter only briefly. Section 10.14 provides a brief discussion of safety databases. For more detailed discussions, see Prokscha (2007). 

The quality assurance component is vital. Quality assurance (QA) is a process that involves the prevention, detection, and correction of errors or problems, and quality control (QC) is a check of the process (Prokscha, 2007). The data stored in the database need to be complete and accurate. Processes that check data and correct them (i.e., make a change to the database) where necessary need to be documented, and all corrections need to be documented in an audit trail such that a later audit can reveal exactly how the final database was created. 

It is helpful to utilize electronic data capture when possible. Computer-assisted data entry, or electronic data capture, at the time of the subject s clinic visit or procedure makes the data entry process quicker and less susceptible to error. It also offers the chance to monitor data collection in a timely manner as the clinical trial progresses, which facilitates the opportunity to detect trends toward poor quality or unexpected data that may be the result of the investigator site failing to adhere to the protocol. Early detection and correction are much preferable to the alternative. 

Having collected optimal quality data, first-rate data management is also critical. Many data that are collected can now be fed directly from the measuring instrument to computer databases, thereby avoiding the potential of human data entry error. However, this is not universally true. Therefore, careful strategies have been developed to scrutinize data as they are entered and once they are in the database. The double-entry method requires that each data set be entered twice (usually by two operators) and these entries compared by a computer for any discrepancies. This method operates on the model that two identical errors are probabilistically very unlikely, and that every time the two entries match the data are correct. In contrast, dissimilar entries are identified, the source (original) data located, and the correct data point entry confirmed. 

---

Clinical Data Management Envisioning the future. SCDM Spring Forum 2005. 

ECG Holter monitor, etc.) loaded into your clinical data management system, and you will want the specifications for those data as well. 

In an optimal world, the CRF is perfectly designed to answer the questions of the study and the clinical data management group will have cleaned the data to perfection. However, to be a good statistical programmer in the clinical trial arena, you must always keep a lookout for errant data and program defensively. Defensive programming lets you account for all possible clinical data permutations. 

Before the statistical programmer receives data that are ready for analysis, the clinical data management group cleans the data. This is done through a query process, which is built into the clinical data management system. The clinical data management query process usually looks like this ... 

The clinical data management group updates the database or CRF based on the response from the clinical site. 

In order to reduce unnecessary data queries, the statistics group should be consulted early in the clinical database development process to identify variables critical for data analysis. Optimally, the statistical analysis plan would already be written by the time of database development so that the queries could be designed based on the critical variables indicated in the analysis plan. However, at the database development stage, usually only the clinical protocol exists to guide the statistics and clinical data management departments in developing the query or data management plan. 

There is only one good solution to handling free-text variables that are needed for statistical analysis. The free-text variables need to be coded by clinical data management in the clinical database. If the adverse events were coded with a dictionary such as MedDRA, the previous example might look like Program 2.3. 

In this example, it is known from non-database sources that at study termination, subject 101-1002 died. That information is hardcoded into the program and overrides the information coming from the clinical data management system. Here are two reasons why hardcoding is a bad practice ... 

Hardcoding overrides the database controls in a clinical data management system. With hardcoding there is no clear audit trail of data change and CFR 21 - Part 11 controls might be considered compromised. 

Laboratory data may consist of many different collections of tests, such as ECG laboratory tests, microbiologic laboratory tests, and other therapeutic-indication-specific clinical lab tests. However, laboratory data traditionally consist of results from urinalysis, hematology, and blood chemistry tests. Traditional laboratory data can come from what are called local laboratories, which are labs at the clinical site, or from central laboratories where the clinical sites send their samples for analysis. Often when the laboratory data come from a central laboratory, there is no physical CRF page for the data and they are loaded into the clinical data management system directly from an electronic file. Local laboratory data may be represented with a CRF page such as this ... 

The problem is that the regular-trial adverse events database and the serious adverse events database do not join well if at all programmatically. You can attempt to join or merge the two databases by event start date and coded term, and that will join many regular-trial adverse events to the serious events. However, this is far from foolproof, because of mismatches in adverse event start dates and because the adverse events may have been coded slightly differently in the two systems. The best way to link the serious adverse events and adverse events databases is to have the clinical data management system create a linking variable key for you. In lieu of that, the only way to reliably link the two data sources is manually. 

In the end, because of the importance of the data, it is imperative that the entire adverse event form data are cleaned. Reconciling the adverse event data with other clinical data in the clinical data management system can be very difficult if the data management system does not provide variable keys for linking such data. Adverse event data fall into the safety area of statistical analyses and are considered an event from a CDISC perspective. 

The randomization of a patient in a given therapy is the cornerstone of a randomized clinical trial. You may find these data in more than one place. They are often found within some form of Interactive Voice Response System (IVRS), but they may also be found in an electronic file containing the treatment assignments or on the CRF itself. If randomization data are found on the CRF, they usually consist only of the date of randomization for treatment-blinded trials. IVRS data are often found outside the confines of the clinical data management system and usually consist of the following three types of data tables. 

Importing Relational Databases and Clinical Data Management Systems 42 SAS/ACCESS SQL Pass-Through Facility 42 SAS/ACCESS LI BN AM E Statement 43 Importing ASCII Text 44... 

Importing Relational Databases and Clinical Data Management Systems... 

Most clinical data management systems used for clinical trials today store their data in relational database software such as Oracle or Microsoft SQL Server. A relational database is composed of a set of rectangular data matrices called tables that relate or associate with one another by certain key fields. The language most often used to work with relational databases is structured query language (SQL). The SAS/ACCESS SQL Pass-Through Facility and the SAS/ACCESS LIBNAME engine are the two methods that SAS provides for extracting data from relational databases. 

Supportive trial data not in the clinical data management system... 

Once the raw clinical data have been imported into SAS, the next step is to transform those raw data into more useful analysis-ready data. Raw data here mean data that have been imported without manipulation into SAS from another data source. That data source is likely to be a clinical data management system, but it could also be external laboratory data, IVRS data, data found in Microsoft Office files, or CDISC model data serving as the raw data. These raw data as they exist are often not ready for analysis. There may be additional variables that need to be defined, and the data may not be structured in a way that is required for a particular SAS analysis procedure. So once the raw data have been brought into SAS, they usually require some kind of transformation into analysis-ready files, which this chapter will discuss. 

Typically, clinical data come to you in a shape that is dictated by the underlying CRF design and the clinical data management system. Most clinical data management systems use a relational data structure that is normalized and optimized for data management. Much of the time these normalized data are in a structure that is perfectly acceptable for analysis in SAS. However, sometimes the data need to be denormalized for proper analysis in SAS. 

Medical dictionaries often need to be referenced when creating various analysis data sets For instance, perhaps the raw adverse event database in your clinical data management system contains only the MedDRA code. The code is worth having, but you would need the adverse event body system and preferred medical term to provide a useful summary of events. 

The Association for Clinical Data Management (ACDM) and Statisticians in the Pharmaceutical Industry (PSI) publish an excellent document called Computer Systems Validation in Clinical Research A Practical Guide, which can be found at http //www.cr-csv.org/. 

Society for Clinical Data Management, at http //www.scdm.org... 

Campbell H, Sweatman J. Quality assurance and chnical data management. In Rondel RK, Var-ley SA, Webb CF, eds. Clinical Data Management, 2nd edn. Chichester, UK John WUey 2000 123Mrl. 

DIA Annual Clinical Data Management Meeting in Philadelphia held on March 31,2003. 

Impact of Regulations on Data Management Practice, Randy Levin, MD, DIA Twelfth Annual European Clinical Data Management Conference, November 5,2002 (Posted November 14,2002)... 

Prokscha, S., 2007, Practical guide to clinical data management, 2nd Edition, Taylor Francis. 

---