This wiki has undergone a migration to Confluence found Here

Product hData

From HL7Wiki
Jump to navigation Jump to search

Product Brief - hData Specifications

back to Main_Page
back to Product_List

Product Name - hData Specifications


  • hData Record Format
  • hData RESTful API

Standard Category

  • Health Information Exchange Standards

Integration Paradigm

  • Messages, Documents, Services, Foundation




  • HL7 Version 3 Specification: hData Record Format, Release 1 (V3_ITS_HDATA_RF_O1_2011JAN)
  • HL7 Version 3 Specification: hData RESTful API, Release 1 (V3_ITS_HDATA_REST_O1_2011JAN)


The hData Specifications: hData Record Format and hData RESTful API, are specifications for capturing, managing, and exchanging electronic health data.

The hData Record Format is designed for ease of implementation and improved efficiency by reducing the size of the data set, implementing a single way to represent data, and using standard XML best practices for the storage and exchange of various forms of health content including, but not limited to: CDA, messages, message or CDA fragments, snippets of clinical data, etc.

The hData RESTful API provides the specification of how to use Representational State Transfer (REST) based Web Services to exchange packages of health related data, hData Records, which via the internet. hData is designed for ease of implementation and improved efficiency by reducing the size of the data set, implementing a single way to represent data, and using standard XML best practices.


Electronic documentation of health care data is currently at the heart of the U.S. national discussion on healthcare reform. Electronic health records (EHRs) have the potential to increase physician efficiency, reduce costs, and promote standardized care. However, health data exchange interoperability and other usability issues have plagued system-wide adoption and have thus limited the expected benefits. hData offers a solution to these problems by using a simple XML framework for the creation, storage, and exchange of health data.

Standards development of EHRs began with Health Level Seven (HL7) in the late 1980s. HL7, comprised of healthcare subject matter experts and information scientists, developed standards for the exchange, management, and integration of electronic healthcare information. The group first created the clinical document architecture (CDA), which was designed to address most of the documentation needs of any health care system. Consequently, this approach made the schema extremely flexible but overly complex, hard to implement interoperably, and difficult to manage. Around the same time, in a separate effort, a simplified continuity of care record (CCR)--not based on the CDA-- was created. Eventually, ASTM International, a highly regarded standards organization, adopted the CCR as its continuity of care record standard.

Later, HL7 reconciled its standards with ASTM by taking data elements from the CCR and encoding them in the CDA, resulting in a new standard called the Continuity of Care Document (CCD). The American National Standards Institute (ANSI) and its affiliated Health Information Technology Standards Panel (HITSP) recommended the CCD as an input standard for creating a national continuity of care standard. The result was initially published as the HITSP Construct 32 standard (C32), which has since expanded and grown more complex.

CDA, C32, and related standards contain a number of significant shortfalls. These include the repeated use of overly abstract data structures and underspecified implementation, including lack of normative schema, lack of a clearly profiled code system, and imprecise data types. HITSP has recognized the complexity of these existing standards and completed an effort to “streamline” documentation on how to use them. However, while this document reordering may provide some help, exchanging continuity of care information will still take place in the same overly complex format, and the entire existing HITSP framework is not always able to deliver a comprehensive, interoperable set of specifications.

hData was created to address these shortcomings. hData lowers the barrier to Health IT integration by focusing on ease of implementation.


Business Case (Intended Use, Customers)

All Healthcare Stakeholders


For some health industry stakeholders, some xml based content exchange models are more complex than required or perceived as diffficult to implement. hData provides a simpler framework for the exchange of that same semantic content, and the hData RESTful API provides a REST based Web Services excahnge protocol as an alternate to WSI (SOAP) based Web Services.

Implementations/ Case Studies (Actual Users)


Work Groups


Certification Available
  • none


Relationship to/ Dependencies on, other standards

Links to current projects in development