documents.html

---
layout: master
title: hData Documents
selected: documents
---
<div id="content">
  <div id="logo">
    <a href="index.html"><img src="images/hData_logo.png" alt="hData Logo"></a>
  </div>
  <div class="projectDescription"><h2>Documents</h2></div>
  <div class="questionAnswer firstQuestion">
  <div id="specifications" class="question">Specifications</div>
    <p><b>HL7 hData Record Format v1.0</b> (<a href="http://www.hl7.org/v3ballot/html/infrastructure/hdata/hdatadf.html">html - HL7 ballot site</a>) (<a href="/documents/pubs/HL7 hData Record Format 1.0-working copy 20110720.docx">docx - submission copy</a>) </p>
    <p>The HL7 hData Record Format (HRF) specifies an abstract hierarchical record organization, packaging, and metadata for individual documents (referred to as “Section Documents” within the HRF specification). Section Documents can be of any type, either XML documents (such as CDA documents, H7v3 messages, or simplified XML wire formats, etc.) or of other media types (such as e.g. MS Word documents or DICOM files). 
    Also contained in this specification is the format for specifying the content that goes into an hData record, which is called the hData Content Profile (HCP) format.</p>
    <p>The HL7 hData Record Format 1.0 has passed HL7 DSTU ballot in September 2011 and is currently undergoing ballot reconcilliation. A final DSTU release is expected soon.</p>
    <p><b>hData REST Binding for RLUS version 1</b> (<a href="http://www.omg.org/cgi-bin/doc?health/11-09-04">pdf - RFC issued in September 2011</a>)</p>
    <p>The hData REST Binding for RLUS (formerly: OMG hData RESTful Transport) defines how the abstract hierarchical organization defined within the HRF specification is access and modified through a RESTful approach, using HTTP as the access protocol. It creates a unique mapping to an URL structure, and defines how HTTP verbs such as GET, PUT, DELETE, etc. affect the underlying information. </p>
    <p>The conceptual relationship between these specifications is illustrated in this UML diagram:</p>
    <center>
    	<img src="/images/Specification UML Model.png" width="300px" />
    </center>
    <p><b>Template for hData Content Profiles</b> (<a href="/documents/pubs/hData Content Profile Definition Template-v1.docx" >docx</a>)</p>
    <p>This template may be used to create a complete hData content profile documentation package, as outlined in Section 3 of the HRF specification. This document, along with the HCP.xml document and the schemas, XSLTs, etc. make up the HCP documentation package.</p>
    </div>
  <div class="questionAnswer">
  <div class="question">Historic Publications and Presentations</div>
    
    <p><b><a href="/documents/pubs/hData-A Simple Approach to Health Data Exchange-Balisage final.pdf">hData: A Simple Approach to Health Care Data Exchange (old paper)</a></b> (pdf | 612KB)</p>
    <p>This was the original paper on hData that outlined our initial thinking and stacked a roadmap for the program. Since then, we have made some significant progress through the standardization process. Most of that is properly documented in the specification documents above, which are by now a much more accurate depiction of the hData program. 
    </p>
    <p><b><a href="/documents/pubs/hData - Secure and Scalable RESTful Health Data Exchange.pdf">hData: Secure and Scalable RESTful Health Data Exchange (old presentation)</a></b> (pdf | 5.34MB)</p>
    <p>This old presentation describes how a patient-centric access control may allow better control of the release of health information. It utilizes a model pioneered for the Kantara UMA Working Group. This is also documented in the <a href="http://kantarainitiative.org/confluence/display/uma/Health+Data+Exchange+Test+Cases" >UMA hData use case</a>.
  </div>

  <div class="questionAnswer">
  <div class="question">Historic Schemas</div>
    <p>The majority of the hData schemas within the <a href="http://github.com/projecthdata/hData/tree/master">Github project</a> should be considered for informational purposes only. In the beginning of the project hData created a number of highly-simplified schemas, which were directly derived from the HITSP C32 profile of the HL7 CCD. The idea was to create a simple wire-level representation of the data underlying the CCD. While we succeeded in creating these schemas and demonstrate the usefulness of simple exchangable documents, we fully understood that the hData schemas were never vetted or verified by clinicians or data modelers. </p>
    <p>Today, there are many new approaches available (Detailed Clinical Models, greenCDA, Resources For Health, etc.) that can provide much simpler representations of clinical data on the wire.</p>
  </div>
  <p>
  <a href="/documents/atom.xsd">Atom.xsd used for 2013 normative version of hData Record Format</a>
  <a href="/documents/root.xsd">root.xsd used for 2013 normative version of hData Record Format</a>
  </p>
</div>