Clinical data management systems

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

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 ... 

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. 

Clinical data management systems can be used in a wide variety of applications. At the study level, it should be possible to set up the database efficiently to allow easy access to the data. Where the functionality is available, points to consider during the validation include the following ... 

---