This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "HData"

From HL7Wiki
Jump to navigation Jump to search
Line 82: Line 82:
 
</root>
 
</root>
 
</pre>
 
</pre>
 +
 +
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.
 +
 +
The document then goes on to register extensions. These extensions provide rules on what can appear in sections that register themselves with the extension. How these rules are defined is out of scope for the record format. The record format

Revision as of 14:10, 25 June 2010

Overview

hData is a set of specifications that have been developed with ease-of-implementation in mind. This page is a placeholder for a more comprehensive introduction to hData and its relationship to Micro ITS and greenCDA.

HData Specification Suite.png

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.

Micro ITS and hData are complimentary. Conceptually, Micro ITS provides a generalized mechanism for defining Domain Specific Markup Languages (DSML) to represent RIM content models. The following diagram illustrates the integration pattern:

HData-HL7 Layer Cake.png

Documentation

Strawman 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.
  • The hData RESTful API specification describes the RESTful API defined of an hData record and a simple messaging interface.

Requirements Document

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.

Presentation Material

Links

Project hData was started by MITRE and is currently hosted on http://projecthdata.org/

Code

Sample code and XML schemas capturing the HITSP/C32 profile of the HL7 CCD can be found on http://github.com/projecthdata

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
|   |-- 1234abc3248.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 requirement="mandatory">http://projecthdata.org/hdata/schemas/2009/06/patient_information</extension>
        <extension requirement="mandatory">http://projecthdata.org/hdata/schemas/2010/01/result</extension>
        <extension requirement="mandatory">http://projecthdata.org/hdata/profile/2010/06/dicom_image</extension>
    </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" path="results" name="Results"/>
      <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.

The document then goes on to register extensions. These extensions provide rules on what can appear in sections that register themselves with the extension. How these rules are defined is out of scope for the record format. The record format