CDISC Standards Energize EDC

Very recently, the Clinical Data Interchange Standards Consortium, also known as CDISC, released version 1.3 of its Operational Data Model (ODM). With this new version of the standard, the CDISC ODM team has been able to realize a good number of enhancements and new features. These new features allow the use of ODM for many more purposes than originally envisaged by CDISC when developing the first version of the ODM (i.e., the standardized exchange of clinical data).

The CDISC ODM

The CDISC ODM is a data exchange standard for describing study metadata, administration data, and collected clinical data. Its audit trail system is fully 21 CFR 11 compliant. Extensions to the ODM are and will be used as carriers of information from protocol description to submission of metadata and data to the FDA. As such, the CDISC ODM and its extensions can be regarded as the end-to-end solution in clinical data management.

Figure 1. An eCRF automatically created for use on a PDA, in French. The ODM standard enables automatic generation of eCRFs in different languages.

ODM use in EDC

One of the implications of the new version is that it becomes very interesting to use in EDC. For example, if the study metadata are defined and described in ODM format, then eCRFs (and also paper CRFs) can be created automatically and on the fly from the study description. To make this possible, the ODM team strongly improved the support for internationalization in the standard; whereas in version 1.2 translations could only be provided for the questions in the forms, in the new version a set of descriptions in different languages can be provided at each level of the study design. This allows automatic generation of labels in the desired language on the paper or electronic form. For example, with one click of the button all necessary forms in the French language can be generated, and with a second click all the corresponding German forms (Figures 1 and 2).

Figure 2. The corresponding eCRF translated into the German language, deployed in a browser application.

The second EDC-related major improvement is the ability to define conditions under which a visit must not be executed, a form or item group must not be used, or an item must not be collected. The conditions can as well be defined in human readable format (multilingual) for use on paper forms, as in machine readable forms. A typical example of such a condition is not collecting data about pregnancy if the subject is male. Another example is not having a subject answer questions about smoking habits if in a previous question it has been confirmed that he/she is a nonsmoker (Figure 3).

Figure 3. When the user indicates that the patient is a nonsmoker (3A), all subsequent questions about smoking habits are automatically blanked out (3B).

The machine readable condition expression can be an XML XPath expression (probably the most suitable way to implement this new feature) or any other machine readable expression or code snippet that evaluates to "true" or "false." This can be a piece of PL/SQL code, SAS script, Java or Visual Basic code. The "Context" attribute defines which computer language should be used to correctly evaluate the expression.

With this new feature, it finally becomes possible to fully automate the creation of intelligent, dynamic eCRFs. A transformation stylesheet or software program can easily transform the form definitions in the ODM file into vendor-specific eCRF implementations. This eliminates the need for designing eCRFs from instructions delivered by the sponsor in nonstandardized or nonelectronic form—as is usually done. Using the ODM, creation of all necessary electronic or paper forms can be done in a matter of a few seconds.

Let's not reinvent the wheel

But let's go a step further. If we can standardize on the description of the forms, why not think about using an open standard for the implementation of the forms themselves? There is such a worldwide, open standard: it is named XForms and it is a W3C Recommendation. Just like the CDISC ODM standard, it is one of the members of the XML family. As a virtue of this, form descriptions in ODM format can easily be transformed in forms based on the XForms standard. Since a typical XForms implementation also sends its data back to the server in XML format, the received data can immediately be transformed again into ODM clinical data (Figure 4). XForms implementations now already exist for PDAs, smartphones, tablet PCs, and other PCs either as standalone software programs or as plugins for browsers.

Figure 4. The EDC process using the CDISC ODM 1.3 standard (simplified) to implement an eCRF created in the XForms standard.

The new version of the ODM standard also offers other benefits. Because basically everything needed for EDC can be described in the Study Description section of the ODM file, an EDC system—including the complete database—can be set up automatically. Some commercial (and also open-source) CDM systems already have this feature, but with the new version of the standard this will become even more attractive.

In a typical ODM 1.3 scenario (Figure 5), the sponsor describes the study events, forms, item groups, items, codelists, conditions, etc., in CDISC ODM format. Tools for doing so in a user-friendly way are already available on the market. The extra benefit of doing this in a standardized way is that forms and groups of items can be re-used in other studies just by storing them in a database or file system after design. Since such standard forms are described in the CDISC format, a change of study design tool, EDC vendor or CDMS has no negative impact. The standardized forms can also be used in other systems.

Figure 5. Clinical data setup and collection process using the CDISC standard (simplified). A change in study design tool, EDC vendor, or CDMS has no negative impact because the forms are compatible between systems.

Of course, this means a responsibility shift. The forms are essentially designed (except for the layout and look and feel) by the sponsor. The EDC vendor or EDC implementor, which can also be the CRO, automatically creates the eCRFs in all the required languages, and depending on the type of media in which they need to be deployed (PDA, tablet PC, browser, paper), adds styling and layout. In the past, it was usually the EDC vendor who designed the eCRFs from information delivered (usually in Word or PDF format) by the sponsor.

At the same time, the EDC and/or CDM system can also be created automatically from the information in the ODM file. Once the study is running, clinical data are collected and exchanged using the same CDISC ODM format and stored in a relational or native XML database. After the study is closed, the data are analyzed and transformed into CDISC SDTM data, either using classic SAS transport files or (in the future) using the upcoming, extended define.xml format, which not surprisingly is an extension of the ODM standard.

ODM for submission data

The extended define.xml standard is indeed the next step in the evolution of CDISC standards. In current define.xml files, only the submission metadata can be described; its successor, however, will allow for the addition of case report tabulations (probably as hyperlinks), and these will be in CDISC ODM format. As such, there will be no need anymore for SAS Transport files. All data will be delivered to the FDA in XML format.

Conclusion

Using the new version of the CDISC ODM standard, EDC in clinical research becomes a lot easier to implement. Improved internationalization and the ability to define conditions have removed the last barriers to fully automating the process of creating eCRFs. If the EDC system then also uses XML as its internal data standard, transformation of captured data into ODM clinical data and to SDTM submission data becomes very easy. The future version of the define.xml standard will further enable an all-XML solution for submitting clinical data to the authorities.

References

1. The CDISC ODM Standard: http://www.cdisc.org/standards/index.html.

2. S. Bassion, "The CDISC Lab Model: Saving Users Time and Money," Applied Clinical Trials, 42–46 (November 2005).

3. D. Iberson-Hurst, "The CDISC Operational Data Model: Ready to Roll?" Applied Clinical Trials, 48–53 (July 2004).

Jozef Aerts is CEO of XML4Pharma, Schlossbergstr. 20, 78224 Singen, Germany, +49 7731 975044.