HData
Return to Main Innovations Page
Overview
hData is a set of specifications that have been developed with ease-of-implementation in mind. hData was first presented to a wider audience within HL7 as the September 2009 meeting in Atlanta, GA. Since then, hData has first been evalauted as a HL7 research project within the ITS working group. The research project culminated in a "For Comment" ballot in January 2011. After a carefull analysis, HL7 decided to standardize hData under the leadership of the SOA working group with ITS and MnM as interested parties.
Specifications
hData requires strong separation of the technical representation and transport technology on the one side, and the clinical content of an electronic health record on the other side. To this end, hData has the concept of hData Content Profiles (HCP), which define what kind of content is represented and transport through hData. It should be note that conceptually CDA and hData are similar in their approach to representing data points in a hierarchical way.
It should be noted that the two specification are not an ITS in the traditional sense, since they do not determine how a logical model is implemented and rendered on the wire. Instead, the HRF organizes existing “exchangeable goods” such as HL7 artifacts, other XML documents, and other media types (including images and other binary data) in a hierarchical structure and provides data pedigree meta data.
hData records may adhere to the content required by an hData Content Profile (HCP): a content profile prescribes the required and optional content a record must provide, and allocates the place for the Section Documents within the hierarchical structure. Note that a single hData record can be compliant with multiple HCPs.
HCP Example
The following record would be compliant with all three HCPs: / -
+ /ccd
+ /imaging/x-rays
- /simple -
+ /allergies
- /meds
Other combinations are possible as well. |
Relationship with HL7 Framework
The illustration below was created by the ArB and annotated by hData to illustrate how hData fits into the HL7 SAIF:
Documentation
Overview Video
The MITRE Corporation has created a set of overview videos here.
Documentation
ITS Draft Specifications
- The basic hData Record Format (HRF) specification describes the overall data organization. Central to the idea of data representation within hData is the ideal of linked documents: while individual data points (such as e.g. a specific allergy or medication) are accessible directly, their entirety and their explicit relationship within an hData record reflect the complete EHR record.
- An example hData Record, capturing a lab order and result. Again, for this example it is important to note that the content of the structure is independent of its structure.
- In its initial phase, the hData project created a set of simplified XML schemas to represent continuity of care data. This collection is often referred to as hData Continuity of Care Content Profile
- The hData RESTful API specification describes the RESTful API defined of an hData record and a simple messaging interface. It should be noted that this transport-oriented specification was separated from the HRF document to ensure that other transport could be used with hData. In its current form, it should be straightforward to create a transport binding/profile using SMTP, XMPP, or SOAP-based transports.
Requirements Document
- The hData Security Requirements paper outlines the concepts and requirements for securing RESTful hData exchanges.
Structured Document Template Design Pilot
hData is part of the Structured Document Template Design Pilot, progress can be tracked on the HData Template Sub Project page. Within this pilot it is demonstrated that hData can be made conceptually equivalent to a CDA based approach: the content of an CDA document and an hData record following the rules of the HRF specification are isomorphic, as long as an hData Content Profile is used that supports all features used in the CDA instance.
Example Schemas for Simplified C32/C83 content
Project hData produced simplified schemas for content at http://github.com/projecthdata/hData These schemas were derived from the content of the HITSP C83 profile of the HL7 CCD. It was not created with a rigorously defined algorithm (like greenCDA or microITS). Instead it is focused on simple constructs, removal of static content, and business names for elements.
Presentation Material
Links
Project hData was started by MITRE and is currently hosted on http://projecthdata.org/
Example Walkthrough
In this example, we will show a hData record that contains patient information, results and dicom images. The definition of what those components are is out of scope for the record format. If we have serialized this record to disk, this is what the structure would look like:
example-hrd/ |-- images | |-- mri_of_knee.dicom | `-- section.xml |-- patient_information | |-- 1.xml | `-- section.xml |-- results | |-- vital_signs | | |-- 1234abc3248.xml | | `-- section.xml | |-- labs | | |-- 4567asdf8976.xml | | `-- section.xml | `-- section.xml `-- root.xml
The contents of the hData Record are described within the root.xml. document. Here is what an hData Root document for this example might look like:
<?xml version="1.0" encoding="UTF-8"?>
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://projecthdata.org/hdata/schemas/2009/06/core">
<documentId>125123124312</documentId>
<version>0.10</version>
<created>2010-02-09</created>
<lastModified>2010-02-09</lastModified>
<extensions>
<extension>http://projecthdata.org/hdata/schemas/2009/06/patient_information</extension>
<extension>http://projecthdata.org/hdata/schemas/2010/01/result</extension>
<extension>http://projecthdata.org/hdata/profile/2010/06/dicom_image</extension>
<extension>urn:empty</extension>
</extensions>
<sections>
<section typeId="http://projecthdata.org/hdata/schemas/2009/06/patient_information" path="patient_information" name="Patient Information"/>
<section typeId="urn:empty" path="results" name="Results">
<section typeId="http://projecthdata.org/hdata/schemas/2009/06/result" path="vital_signs" name="Vital Signs">
<section typeId="http://projecthdata.org/hdata/schemas/2009/06/result" path="labs" name="Labs">
<section>
<section typeId="http://projecthdata.org/hdata/schemas/2010/06/dicom_image" path="images" name="Images"/>
</sections>
</root>
This root document contains some basic metadata about itself: an identifier, the version of the hData Record Format that it conforms to, as well as its created and modified date.
Also contained is a list of used extensions. Extensions identify the content of sections. The record format only requires that a globally unique string is used to identify an extension. It is recommended, but not necessary, that the string be a URL where information can be found about the extension. Note that the use of URLs with the domain part of the author guarantees global uniqueness. If the extension is describing XML documents, it is again recommended that the URL resolve to an XML Schema for the documents that this extension is describing. For non-XML content, a description of the content type (such as e.g. DICOM documentation) should be provided at the URL used for identifying the extension.
For example, an extension may be identified by a URL that points to a CDA Template Registry that lists templates that should be applied to CDA documents that would be stored in a hData section. Alternatively, an extension may be identified by a URL that resolves to an XML Schema that has been derived by a microITS or greenCDA process.
Extension identifiers may also resolve to documentation on what may appear in sections. An extension may describe the structure of JSON documents it expects to be used in a section.
Note in this example that sections can be nested. In this case we have a results folder. This folder is expected to have no section documents. It will still have an Atom feed which will provide links to the nested sections. It contains two nested sections: Labs and Vital Signs. Both conform to the same extension, but this is not required. The rules for determining what section documents go into which section is out of scope of the specification, and would be determined by the content profile.
The section feeds (named "section.xml") contain a feed of all child elements - either sections or section documents, including the identifiers (typically URLs for the RESTful API to hData Records) of the child resources.
