Frequently Asked Questions
- What is hData?
- How will hData be used to exchange EHR health data?
- What is the standardization status of hData?
- How does hData relate to the recently proposed Resources For Healthcare idea?
- Isn't hData all about simplified data models, XML, and that stuff?
- Who is using hData?
- Where will all the data models and their rendering come from?
- Do I need to be an EHR vendor to use hData?
- What programming languages will hData use?
- What is the significance of the name hData?
hData is a simple health IT exchange framework for the creation, storage, and exchange of health data. The core hData specifications contains two components:
- HL7 hData Record Format (HRF): The HRF describes an abstract architecture of how data is stored in multiple XML documents and is organized in a hierarchy. It also contains a concrete schema for the HRF meta-data. Records conforming to the HRF are called hData Records (HDRs).
- OMG hData RESTful Transport (HRT): When the HRF is represented as a web resource, this RESTful specification allows for modifying section documents, creation of new data, record transport, and management of the entire record through a simple Web API.
In addition to the above technical specification, hData uses hData Content Profiles (HCP) to specify the actual content included in a particular hData record. These content profiles detail what fields are required to capture an allergy or condition. The philosophy is to use simple XML documents mapped directly to existing healthcare information models. For the purposes of compliance with the National Information Exchange Model (NIEM) lifecycle process, an hData Content Profile may be understood to be a specialization of the NIEM Information Exchange Package Documentation (IEPD).
The hData project had initially created schemas for a Continuity of Care Content Profile, as well as lab orders and results. It is expected that Content Profiles will be submitted to standards organizations. Additionally, it is assumed that Content Profiles will be created to address different medical domains.
At its core, hData is a simple way of organizing data into small pieces in folders, with a corresponding set of XML Schemas or other appripriate media types (such as e.g. PDFs, PNGs, or DICOM containers) to describe the small pieces. Because of this simplicity, it is easy to exchange information using hData.
Currently, hData has one RESTful transport binding, which is being standardized at the Object Management Group.Future transports may include SMTP or XMPP transports.
hData has been reviewed by HL7 and OMG and is in the process of becoming a normative standarf. Please check the Standardization page for a detailed status.
Resources For Healthcare (RFH) was recently (09-2011) proposed as a reponse to the HL7 Fresh Look Task Force question: "How would a complete health IT software stack look like, if HL7 re-did it today?"
Conceptually, RFH is using a RESTful transport to allow the exchange of the simplified content. There is a signficant overlap with hData of the way transport within the RFH proposal is realized, so that it should be quite easy to reformulate RFH in hData terms. Based on discussions with the RFH authors, they are starting to find similar issues that drove hData development (such as metadata definition) - these problems have largely been solved within hData.
Going forward, the RFH content model can be understood as a hData Content profile. This will require some work on the OMG hData RESTful Transport, and the formulation of a comprehensive HCP covering the RFH data model.
When hData was started by MITRE, one of the guiding principles in creating hData was (and still is!) developer friendliness and simple-to-implement. Part of this approach was to create a number of HITSP C32 derived schemas covering a simple continuity of care profile. When we created these schemas (which are still available in the github repository) we understood them to be placeholders for simplified schemas and models derived from a comprehensive clinical information model through a more rigourous process.
With the advent of HL7 greeCDA, RFH, DCMs, and similar approaches, HL7 is now able to start developing such simplified models that can be vetted by the clinical subject matter experts.
Since hData was until recently actively being developed from a standards perspective, there have so far been only a few limited proof-of-concepts and pilots. As hData is now stablizing, there are a number of projects starting to use hData. At the September 2011 workgroup meeting, the HL7 SOA and Pharmacy workgroups have agreed to create an hData content profile for Pharmacy. This work will be sponsored by epSOS, Cerner, MITRE, and others. Other projects are expected to follow soon.
hData seprates the technical framework (packaging, metadata, transport, security, etc.) strongly from the content modeling aspect of health IT. As a result, the hData specification are largely content agnostic and will rely on clinical subject matter experts and data modelers to create hData Content Profiles specifying the payload model and rendering. This can happen at a variety of places, including within the domain specific working groups with existing standards development organizations, such as HL7. In fact, this process has already started, with the Pharmacy WG at HL7 agreeing to create an hData Content Profile for a medications service. Other workgroups are expected to follow soon.
No. hData can be used by anyone interested in working with Health IT systems. hData is designed to make implementation fast and simple. Its simple serialization format and RESTful API make hData highly portable as well. While an obvious use of hData would be to expose the information stored in an EHR System, we hope that it will ease the development of all health applications by lowering the barrier to creating and consuming health data.
hData is based on XML, so it can be used with virtually any programming language. The MITRE team is working on developer kits in Ruby and Java. The hData project will gladly accept any contributions for generating or consuming hData in other programming languages.
hData is a contraction of “health” and “Data;” with the capital “D” emphasizing the core importance of data. The hData team's goal is to make the creation, exchange, consumption, and storage of health data simple, secure, and private. As a result, we believe better health outcomes are sure to follow.