ODMv2: Renovating the ODM Standard

 ODM, CDISC's Operational Data Model, version 1.x will be 17 years old in October, making it a mature standard. ODM has come of age, and it's time for ODM to take on a bit more responsibility around here. Toward this end, a new XML Technologies development team has recently started work on ODMv2, a substantially updated version of ODM that breaks backwards compatibility with version 1.3.x to add a number of significant new features. This post highlights some areas of new development for ODMv2. As ODMv2 is still in the early stages of development, the scope of the project and specific features are subject to change.

Among the more important new ODMv2 features will be a RESTful API that specifies standard methods of data and metadata exchange. The RESTful architecture uses specific URLs and the HTTP protocol to leverage pervasive, scalable web technologies to simplify data interchange. Lack of a common API for data exchange in clinical research has limited the available interoperability opportunities. Some EDC vendors have successfully implemented their own RESTful APIs based on ODM v1.3.x, such as Medidata Rave and OpenClinica. HL7 FHIR (Fast Healthcare Interoperability Resources) provides a useful example of applying RESTful APIs to the problem of healthcare interoperability, and alignment with FHIR is an important ODMv2 requirement.

ODM has become the most accepted way to represent CRF metadata, and we seek to build on this success in ODMv2 by addressing some acknowledged limitations. For example, support for repeating ItemGroups in CRFs, visual analogue scales, images, simple check-all-that-apply question implementation, CRF completion guidance, and a number of other improvements are planned. The ODMv2 CRF representation improvements will ensure that more common eCRF features will be supported without the need for extensions.

Although ODMv2 will cover more use cases without requiring extensions, the extension mechanism will continue to be an important part of ODMv2. As with ODM v1.x, ODMv2 will strive to handle the most common 80% of the usage scenarios well, while leaving the remaining 20% for extensions. This will help keep the standard from becoming too bloated and will allow implementers to extend ODMv2 to add support for innovative, proprietary new features.

Most CDISC XML standards are ODM extensions. ODMv2 will bring some of these standard extensions into the core model. For example, SDM-XML is an ODM extension for representing study designs. We plan to incorporate this standard in ODMv2, in addition to certain protocol elements useful for driving study setup and execution. CTR-XML is an ODM extension used to simplify clinical registry submissions, and the ODMv2 study design and protocol enhancements are important components needed to support the CTRv2 standard that's currently being planned.

Define-XML and Dataset-XML are important ODM extensions, and standards in their own right. As part of ODMv2, we plan to support the exchange of operational datasets generated by EDC systems or CROs for sponsors that prefer to process SDTM-style operational datasets. To simplify the implementation and exchange of operational datasets, ODMv2 will support tabular data structures in addition to the hierarchical CRF data structures.

CRFs and datasets are among the most common clinical research data artifacts. In addition to support for these data structures, ODMv2 will provide support for the relationships needed by systems that support more sophisticated models. For example, CDISC SHARE supports the maps-to relationship for a CDASH variable that maps to a specific SDTM variable. In cases where variables are related, it's important that ODMv2 provide a mechanism to identify that relationship.

Improved semantic annotations are needed for ODMv2 to take advantage of formal vocabularies and code systems such as LOINC, SNOMED CT, other healthcare standards, and eventually CDISC Biomedical Concepts. They will also help to more completely represent the CDISC Controlled Terminology. The Alias element has been broadly used to capture semantics, but a more formal approach is desired for ODMv2. Support for semantic annotations will advance the use of data from EHR systems that utilize terminologies different from those in clinical research.

As we consider shifting our data exchange focus from one file format or another to the use of standard APIs in ODMv2, we are also expanding the ODM data formats beyond XML. XML remains an important exchange format, especially for documents, but for API use we will also support JSON. Other formats, such as RDF, may also be supported.

Before we break ground on ODMv2, it's important to account for what ODM currently does well to build on those successes. After 17 years of ODM v1.x, a significant number of new feature and change requests have accumulated, and many are listed on the ODMv2 backlog. ODMv2 represents both the modernization of ODMv2 to meet new interoperability needs, as well as an opportunity to refine those things it does well based on feedback from implementers that have successfully applied ODM v1.x.

If you're interested in participating on the ODMv2 development team or in providing input into the ODMv2 requirements, please join us by completing the volunteer form on the CDISC web site. It's particularly important that technology implementers that work with clinical research data participate to ensure they both contribute to and influence the development of this significant new version of ODM.