HData Template Sub Project

Back to Structured Document Template Design Pilot

Overview

The goal of this effort is to demonstrate that hData can be used to capture and exchange information in a similar fashion to CDA. Using hData, we will translate a CDA based progress note into an hData Record and then back into a CDA R2 document. The translations should not introduce any data loss and the hData Record Format should not impose any restrictions that would hinder the representation of clinical information.

Assumptions

This project assumes that prior to the Execution Phase, the following artifacts will be available:

• Templates required for a progress note
• Example progress note documens

Project Execution Phase

Status at Feb 19th

A quick status update that I can give is that I am making good progress on the work with hData. I have been able to model the CDA R2 Progress note, and have been working on the transforms back and forth between CDA and hData (so I'm actually a little ahead of schedule.

Status at Feb 26

The CDA Progress note has been modeled in hData. The modeling effort was fairly trivial due to previous work on the hData project. We have been working on a Continuity of Care Content Profile which is based on the HITSP C32, which is a profile of the HL7 CCD. Since this pilot uses CCD results and organizers, as well as person information to be used in the CDA header.

An exmaple hData root document would look like the following:

<?xml version="1.0" encoding="UTF-8"?>
<root xmlns="http://projecthdata.org/hdata/schemas/2009/06/core"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://projecthdata.org/hdata/schemas/2009/06/core file:/Users/andrewg/projects/hData/schemas/2009/06/root.xsd">
    <documentId>documentid0</documentId>
    <version>0.8</version>
    <created>2010-02-09</created>
    <lastModified>2010-02-09</lastModified>
    <extensions>
        <extension requirement="mandatory" contentType="http://projecthdata.org/hdata/schemas/2009/06/patient_information"/>
        <extension requirement="mandatory" contentType="http://projecthdata.org/hdata/schemas/2009/06/result"/>
        <extension requirement="mandatory" contentType="http://projecthdata.org/hdata/schemas/2009/06/result_organizer"/>
    </extensions>
    <sections>      
        <section typeId="http://projecthdata.org/hdata/schemas/2009/06/patient_information" path="patient_information" name="Patient Information"/>
        <section typeId="http://projecthdata.org/hdata/schemas/2009/06/result_organizer" path="result_organizers" name="Result Organizers">
            <section typeId="http://projecthdata.org/hdata/schemas/2009/06/result" path="1" name="First Set of Labs" />
        </section>
    </sections>
</root>

In the above example, the data is modeled as followed:

• Patient information present in the CDA header is collected in the Patient Information Schema.
• Results Organizers are captured in the Results Organizer Schema (yet to be published)
• Results will be captured in the Results Schema. Results will be nested in folders underneath the organizer folder. Folders are used to group results by organizer. In the above root document, there is a single organizer with one set of results.

To map the hData Record back to a CDA document, we will again be leveraging existing work. MITRE had previously produced a project called L32. This was an effort to create a strongly typed XML Schema for HITSP C32 documents. We are reusing the L32 Schemas for Person Information and Results, with modification to help us map to CDA. We are using Altova MapForce to map hData Schemas to CDA-based Schemas. MapForce will create XSLT that can be used in conjunction with XProc to go from hData to/from CDA. Initial progress has been made on mapping result and person information hData Schemas to CDA Schemas.

Status at March 26

Work is complete on mapping and transforming hData to/from CDA. The plan described in the February 26 status update was followed and the hData team has been able to successfully translate between hData and CDA for the TB Progress note. The source code and other artifacts related to this are currently awaiting public release from MITRE. Once the code has been approved, it will be published and linked to from this page.

Build an end-to-end CDA CDA R2 progress note using hData

This effort will focus on building an hData Content Profile to represent the progress note. This means that we will devise simple schemas (where element and attribute names match business names) for the content of the progress note. Schemas will be designed "by hand", which means that the team will look at the template definitions and then create an XML Schema using an XML editing software suite (such as XML Spy or oXygen). We will also specify the folder structure of the hData Record. Once the content profile has been established, we will hand code the given examples using hData.

Develop template-related services using hData

In this phase, we will create XProc pipelines that will utilize XSLT to translate the CDA R2 based progress note to hData and vice-versa. The process will look like:

When translating from CDA to hData, you need more than just XSLT since hData is a multi-file format. XProc allows the orchestration of running several XSLT processes and saving the results to different files. In the case of the TB Progress Note, we will run three separate stylesheets on the CDA document to get the resulting hData Record.

Depending on timing this phase may also involve collaboration with the MDHT Template Sub Project. This collaboration could take place in two possible ways:

Using hData Schemas - In this case, the hData team would create XML Schemas that will be used in the hData Record. These schemas would be created by hand (as described above in the Project Execution Phase). The MDHT would then map these hand crafted schemas into their models. With the mappings in place, MDHT should be able to produce tools to translate from CDA R2 to hData, eliminating the need for hand coded XProc and XSLT.

Using MDHT Schemas - The MDHT project would generate XML Schemas that have business names for element names. The hData Content Profile would consist of these schemas and the only input into the content profile by the hData team would be the folder structure. Again, the MDHT tools would eliminate the need for hand coded XProc or XSLT. This would be an ideal case because it involves the smallest amount of hand coded work. However, it is also probably the most difficult path to take for the project due to the collaboration necessary between the hData and MDHT teams and the readiness of tools by both efforts.

Released Software

You can find software developed for this effort under the HL7 TSC Project at hData's GitHub site.

Delivery Phase

Prepare/Generate sample CDA IG based on hData

Develop the Implementation Guide

Bonus

Show how the hData Record can be transported via the RESTful interface.