Tuesday, September 25, 2012

Electronic Health Records within ODM

One of the arguments that some at the FDA have for choosing HL7-v3-CDA as a future format for SDTM submissions is that CDA can carry electronic health records (well, that's the only use-case HL7-v3 has been successful in). As SDTM is clinical information is medical information these persons (who are not experts them selves, but who listen to hear-say) believe that CDA is also a suitable format for SDTM data.

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.

9 comments:

  1. Hi Jozef, I like your comment about "downgrade" from ODM to SAS Transport. How about "upgrade" to a RDF version of ODM?

    ReplyDelete
  2. Thanks Kerstin,

    Good idea - would be a great project for a student!
    We do not teach RDF at my university, so if you know one that would be interested, I will surely want to provide help.

    ReplyDelete
    Replies
    1. Could be a task for the W3C HCLS-IG in the workstream that Charlie Mead and Eric Prud'hommeaux restarted - Checkout http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability

      Delete
  3. This comment has been removed by the author.

    ReplyDelete
  4. Thanks to Kerstin for bringing me in contact with Charlie Mead.
    By the way, there was a post at http://hl7-watch.blogspot.co.at/2012/10/cdisc-discovers-concept-maps.html from Barry Smith about the CDISC efforts on this field.
    Kerstin, can you react on that?

    ReplyDelete
    Replies
    1. Hi Jozef, I pointed Barry to the presentation from CDISC/GSK as I saw interesting connection to Barry's work on formal models for the biomedical and clinical reality (OBO), especially the Ontology for General Medical Science (OGMS). I think CDISC's efforts on mind maps (or rather concept maps) do "just beg for" RDF triples and also for formal models, i.e. disease models based on OGMS, see my recent blog post http://kerfors.blogspot.se/2012/09/mind-maps-just-begging-for-rdf-triples.html

      As highlighted by many, recently in an excellent presentation by Vicki Seyfert-Margolis, FDA, in the IOM workshop: Sharing Clinical Research Data 1,) data standards must start from a clear definition of the disease and related processes to understand the disease course and treatment response. Hence my interest in what I learned the last 2-3 years about biomedical ontologies for representing the biomedical and clinical reality underlying clinical research data.

      1) http://www.iom.edu/Activities/Research/SharingClinicalResearchData.aspx

      Delete
  5. How about: the problem of hyperthyroidism started at approximately age 50 (approx. date). The patient is taking thyroid drug X since age 52 and it is now active and treated.

    Then the patient had pneumonia at age 54 which is now inactive.

    The patient's bone mineral density (done outside of protocol, not on any CRF and present only in this patient) Z score is
    1.3.

    --------
    EHR standards and SDTM data standards are close but have differences.

    SDTM is structured - same data on all patients.
    EHR data is variable - some people have a stroke and all details about it and many don't.


    for data outside research protocol (when important to collect), we perhaps should not twist arm of a SDTM standard to try to capture it.

    ReplyDelete
  6. Hi Vojtech, good to hear from you.

    Well, if you can capture the above medical statements in CDA, you can also capture it in ODM (using the CDA snippets).
    What is needed to go into SDTM is not decided by us (protocol or not) but essentially by the FDA. If the above medical event happened during the trial and was not related to the trial, it will probably not go into SDTM. If it was part of the medical history, it will probably go into the MH domain, but only part of it (those parts the FDA wants) and categorized.

    It is not the task of CDISC to describe such medical statements in a structured way (we are not over-ambitious). This is already done by organizations like OpenEHR and HL7.

    What I meant is that ODM CAN keep EHR information, not that it MUST keep EHR information. My statements were triggered by some FDA people who said that this will be a requirement in the future. They just didn't realize that it is already possible now.

    ReplyDelete
  7. Electronic Health Records within ODM offer a seamless solution for managing patient data. Integrating registros médicos electrónicos streamlines processes, enhances accuracy, and facilitates better-informed healthcare decisions, ultimately improving patient care and operational efficiency.

    ReplyDelete