CDISC ODMv2 Development Progress: A 2018 Q1 Update


Since starting work on ODMv2 last year the CDISC Data Exchange Standards Team, formerly known as the XML Technologies Team, has made substantial progress towards completing the backlog tasks and updates planned for ODMv2. Much of this work is progressing concurrently, creating a broad set of ongoing discussions. To follow the ODMv2 development work the best place to begin is the ODM-XML page in the XML Tech space on the CDISC Wiki, where you can find a list of the most recently updated pages, a link to the decision log, and links to other relevant aspects of the project. You can also find the notes from our meetings, and if you miss a meeting, a recording of it is available through the notes for a few weeks after the teleconference.

The Data Exchange Standards Team's goal for 2018 is to release a first draft of ODMv2 for trial use by the end of year. We then plan to test and revise the draft for final release during 2019. This post, some of which was included in the Q4 2017 CDISC newsletter, highlights examples of ODMv2 development progress towards this end-of-year draft release, including updates on our three large sub-projects: the ODM API, updating the study design model (SDM-XML) and merging it into the core ODM model, and adding support for operational datasets in ODM.

The team posted an early draft of the ODM RESTful API for metadata for review in Q3 of 2017, and a draft data API will be available for review before the end of March 2018. The initial draft API features JSON support, and we will add the XML schemas after drafting the full API specification. During Q2 of 2018 we will add the AdminData and ReferenceData API specifications. To support API use, we will register new ODM media types with the Internet Assigned Numbers Authority (IANA). The following example shows the form metadata API.

The team is in the process of moving content created as ODM extensions back into the base ODM standard for Define-XML and SDM-XML. For the Define-XML standard, we’re reviewing elements and attributes created in the Define-XML namespace to determine which should become part of the core ODM standard. We are also evaluating the implementation of Dataset-XML for EDC, or support for the exchange of operational datasets. Since many sponsors request EDC data as datasets, this will provide a standards-based dataset format for creating and exchanging raw data.

Work is also underway to update SDM-XML and to make this part of the ODM model. This will encourage broader use of the study design model, and expand ODM’s use in study setup.

The ODMv2 backlog includes a number of enhancements and new features beyond the three major sub-projects. We are working through these as well as addressing a few open items in the ODM v1.3.2 specification. These enhancements include topics like extending multi-language support, support for formatted text strings, improving the length and significant digit attributes, what to do with the placeholder Presentation element, and a longish list of other enhancements. For the remainder of this post I’ll highlight progress against these tasks.

One CRF representation improvement includes an enhanced version of the ODM Repeating ItemGroup that drives the repetition using a code list so that each term in the code list represents one or more questions on a CRF.  Dynamic repeating ItemGroups can represent multiple observations per code list term, while static repeating ItemGroups are restricted to one observation per code list term. Repeating ItemGroups can optionally include a dynamically added “other” observation. The example below displays a Medical History CRF generated based on a body system code list.

As a data exchange standard, ODM supports a range of semantics. We have long used the Alias element to represent alternative semantics, but we plan to implement a more formal mechanism for this purpose. For example, we will use this new element to represent standard terminologies such as LOINC, SNOMED-CT, as well as the CDISC Controlled Terminology. There is active development underway exploring this new element for use in MeasurementUnit, ItemDef, CodeList, EnumeratedItem, and CodeListItem. For example, using an approach based on HL7 FHIR, the new element looks something like the following:


<odmv2:Coding Code="C38008" CodeSystem="http://ncicb.nci.nih.gov/xml/odm/EVS/CDISC" CodeSystemName="CDISC/NCI CT" CodeSystemVersion="SDTM 2014-12-19" Display="AFTER"/>

In an effort to simplify ODM implementations, we have decided to settle on one element for ItemData instead of supporting two ways to implement this as exists in the current version. This means that ItemData[Type] will be deprecated, but ItemData will change to be more aligned with ItemData[Type], including moving the @Value into the element text and adding schematron rules into the schema to provide data type checking. Overall, the new ItemData implementation will more closely resemble ItemData[Type], and will simplify implementations by merging the two different ItemData approaches into one. Using one ItemData element instead of a long list of ItemData[Type] elements simplifies implementations, including the API. We will also develop a transformation tool to migrate ODM v1.3.2 ItemData[Type] and ItemData elements to the ODMv2 ItemData to ease the implementation burden.

We have added a TranslatedText/@Type attribute to support formatted text to allow for better control over displaying text on CRFs and other user facing artifacts. The @Type attribute will take a media-type setting such as “text/plain” or “application/xhtml+xml”. The “text/plain” type will be required to ensure an unformatted version of the text is available, and we anticipate that XHTML will be among the most common formatting types used. We plan to support a limited subset of the most relevant XHTML tags so that ODMv2 will support text formatting, but not allow scripting or other features that could cause security or other implementation problems. Markdown is a popular way to express simple formatting that can be represented in the restricted XHTML implementation. Providing support for formatted text means that we can deprecate the largely un-used Presentation element.

We identified data queries as a gap in the current version of ODM. While we can represent data queries in the current model, we believe that, given their importance, data queries should have a more pronounced representation. As a result, we have started working on a new construct for representing data queries in more detail so that a receiver could easily extract the data query content. EDC vendors should take particular care in reviewing this new feature.


As we debate and develop new features, we will examine their impact on the ODM model closely prior to implementation. In addition to refining the existing model, we plan to enhance the schema to represent more of the model’s rules and constraints. This approach has the benefit of enhancing the coverage provided by schema validation, as well as benefiting those that generate code based on the schema. A new set of schema naming conventions has been documented to support this work. We will also review the existing schema for consistency.

I plan to provide another ODMv2 update early this summer. This update will provide additional insight into the ODMv2 draft version the Data Exchange Standards Team will publish by the end of the year.


Comments

  1. This is a great public update (with no login needed) on ODM development.

    ReplyDelete

Post a Comment

Popular posts from this blog

Value Level Metadata, Vertically Structured Datasets, and Normalizaton

Define-XML v2.1 – What do you think?

What’s the difference between iSHARE and eSHARE?