HData Template Sub Project
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.
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.
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.
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.
Prepare/Generate sample CDA IG based on hData
Develop the Implementation Guide
Show how the hData Record can be transported via the RESTful interface.