CDISC ODM has already been proven to be able to carry submission (SDTM) data: at least 3 vendors of mapping software use CDISC-ODM to store SDTM data, and only in the very last step of their transformation process, they "downgrade" it to SAS Transport 5.
But let's have a look whether CDISC ODM is capable of containing information from health records.
This becomes more and more important due to the upcome of "single source", the technology to capture data only once and store it as well in the EHR system as in the EDC system simultaneously. Another reason is that within the FDA there is a "vision" that reviewers in future should not only have access to the collected data from the study, but also to (some of) the electronic health record data of the subject.
So how can we incorporate EHR data into an ODM?
Let us start with a simple ODM file containing the study definition. One ItemGroup (subform, page) may look like this:
and one the corresponding ItemDef is:
[as you see, this is an international study, running in the US, France, Germany and Korea]
The ItemDef contains a good amount of additional information, such as that the height can either be measured in inches (for the US) or in centimeter (in the other countries).
Also the edit checks in the form of allowed ranges (both for inches and for centimeter) is added.
Last but not least, it is stated that this data point will later go into the value for the SDTM variable VSORRES for the case that VSTESTC is "HEIGHT". We call this "SDTM annotation in ODM".
The data points themselves in the "ClinicalData" section of the ODM then look like:
stating that the collected value for the "height" is 193 and the unit is "cm".
Now we also want to include the original source of the data, which is a data point in the EHR.
How can this be done?
The ODM has an excellent "extension mechanism", allowing to add extension elements and attributes which "live" in another namespace and come from other standards, and still have the possibility to validate such "mixed" files against the XML-Schemas of both standards.
HL7-v3 does not have such an extension mechanism: although you can add elements and attributes from other standards, you loose the ability to validate mixed instance files.
As the information from the EHR "lives" in the HL7 namespace you first need to declare that namespace, which is usually done at the top level element of the XML document.
In our case:
stating that all elements prefixed by "cda:" (which is an arbitrary choice) live in the namespace "urn:hl7-org-v3" which is "owned" by the HL7 organisation.
We can now generate an "extension" XML-Schema according to the rules given by the ODM standard (I can send a copy of that to those that are interested), in which we describe that the HL7-v3 element "observation" (corresponding to a single observation in the EHR) is a legal child element of the ODM element "ItemData".
Piece of cake!
This now allows to incorporate the source data point of the EHR into the ODM data point. For example:
In the EHR, "height" was coded using the SNOMED-CT coding system, the data point was collected on 13 March 2010 (remark the stubborn refusal of HL7 of using ISO-8601 format), the value was "193" and the unit (which is a UCUM unit as always used in HL7-v3) was "cm".
So we now have the source data point within the ODM file within the ODM data point itself!
What can of course also be done additionally is to add a reference (e.g. using an "href") to the location of the EHR of this specific subject in the EHR system.
Some people will immediate ask: "what about ISO-21090" datatypes?
ISO-21090 datatypes are envisaged to become the "datatypes" (i.m.o. the name is inherently wrong) or better "data objects" of the future for the healthcare world. They have been developed as a joint effort between different standardization organizations (well, sort of - essentially only HL7 and ISO were involved. Others such as CDISC and OpenEHR were not asked).
CDISC uses ISO-21090 in BRIDG. However, until now there is no real XML implementation of BRIDG. ISO-21090 also violates ISO-86012, but that is another story I need to write a separate blog entry about.
Another problem is that implementing ISO-21090 is extremely expensive. If you want to obtain a copy of the specification, you need to pay ISO the humble amount of 238 Swiss Francs (about 200€ or 250US$). If you pass that specification to your colleague, he/she also needs to pay that amount, as the document is copyrighted. Not a good way to promote a standard isn't it?
Furthermore noone is actually using ISO-21090 yet. HL7 plans to implement it in the future release 3 of the CDA standard. Release 3 however is currently only in the mind of some persons, even not on the drawing board yet. Some people have criticized ISO-21090 to be too complex to be implemented in any standard anyway.
So, if you would like to implement ISO-21090 data (types) points in ODM, what needs to be done?
Essentially, through the ODM extension mechanism, this is a piece of cake again. One just needs to write a simple "envelope" XML-Schema, and a small "extension" schema, in which you define that "ItemData" is allowed to contain ISO-21090 data points. That's it. In principle, the ISO-21090 elements and attributes will then "live" in the namespace "uri:iso.org:21090".
Again, if you need any technical details or an example set of file, just send me a mail.
