hData Record Format, Release 1

This document uses the following namespaces. This specification uses a number of namespace prefixes throughout; they are listed in Table 1. Note that the choice of any namespace prefix is arbitrary and not semantically significant. Note that namespace identifiers are not necessarily resolvable links. 

Table 1. Namespaces referenced in the hData Specification

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [5]. 

When describing concrete XML schemas, this specification uses the following notation: each member of an element's [children] or [attributes] property is described using an XPath notation (e.g., /x:MyHeader/x:SomeProperty/@value1). If present, the pair in parenthesis after the element name definition contains the data type and the multiplicity (such as 0..1, 1, 1..*, etc.). 

Note also that only the W3C XML schemas linked in Section 3 at the end of this document are normative – any schema fragment or other schema description within the main body of this document are informational only. 

The overall structure of an hData Record is a hierarchy, similar to the folder-file paradigm of many computer file systems. The root of the hierarchy can correspond to an individual patient, and thus all documents in the hierarchy of such a record are typically associated with that patient. As mentioned earlier, the hierarchy is typically not an actual data repository, but rather an abstract arrangement of information from the repository, whose form we do not specify. Note that there is no need to have an hData record instance to correspond to a single patient: hData MAY be used for other use cases (such as e.g. a hospital ward management system or a lab order system), as well. 

To draw a distinction from an actual file system, we use the word “section” instead “folder” and “section document” or “document” instead of “file”. At the top of the hierarchy is a special document which is called the “root document”, which describes many of the properties of the hierarchy (see 2.2). Sections themselves can be specified as optional or required in the root document. Implementers can either extend existing sections or define new sections. Such newly created sections MUST be registered in the root document to be accessible, and included in the corresponding Atom feed (see 2.3.2). 

Each section contains a set of subsections and/or documents. Typically, all documents are grouped into sections by purpose, and thus share the same format, which is declared in the root document. For example, a section may contain laboratory result documents. Sections can also contain other Sections, for example, a section for radiology under laboratory results. The semantics and rationale for the grouping is to be documented within the hData Content Profile (HCP) description package (see section 3.2). Since hData can accommodate multiple HCPs concurrently, multiple groupings MAY be established in parallel, and the same document can exist in more than one place in the hierarchy. 

The root document (root.xml) is located at the root of the hierarchy. It contains the following elements (REQUIRED if not marked otherwise):  

• /hrf:id (xs:string, 1) - This element uniquely identifies the root document and the hData record itself. This element has no specific semantics or meaning attached to it. A possible implementation could be  through a textual representation of a UUID.
• /hrf:version (xs:integer, 1)- The version of the hData Record Format used within this document. It is an integer that corresponds to the version number of the hData Record Specification that is implemented. The version number for records complying with this version of the specification is 1. 
• /hrf:created (xs:dateTime, 1)- Creation date of the root document, using the W3C XML Schema Date data type. This data SHOULD be significant to at least the second. 
• /hrf:lastModified (xs:dateTime, 1)- Last modification of the root document, using the W3C XML Schema Date data type. This data SHOULD be significant to at least the second. 
• /hrf:extensions (hrf:extension, 0..*) - Node containing a list of extensions (list of hrf:extension elements). Any extension to this specification MUST register itself here.  The list of children of this element represents the list of HL7 RLUS semantic signifiers, as required by [4], Section 5.2.1.
• /hrf:extensions/hrf:extension (xs:string, 1) - This text element contains a unique identifier for the extension. It is RECOMMENDED to use an URL. For elements of content type “application/xml”, it is RECOMMENDED that the text element contains an URL that provides a RDDL document [3] that describes the format of instances of XML document of this extension type by including a <rddl:resource> element with the xlink:role attribute set to the schema definition. For other content types, it is RECOMMENDED that the RDDL document resolves to documentation of the section document format, such as a PDF or HTML description. To allow sections that store no section documents, a root.xml MUST define an extension node of value “urn:empty”. 
• /hrf:extensions/hrf:extension/@contentType (xs:string, 0..1) - This attribute contains the content type of all documents in a section that registers with this extension. If the attribute is not present, the documents in the section MUST be of content type “application/xml”. 
• /hrf:extensions/hrf:extension/@extensionId (xs:string, 1) – This attribute contains a local identifier for the extension. It MUST be unique within the root document. 
• /hrf:sections (hrf:sections, 0..*) - This node contains references to all sections in the hierarchy (hrf:section)
• /hrf:sections/hrf:section (hrf:section, 0..*) - A hrf:section describes an abstract collection of documents and subsections within an hData record. 
• /hrf:sections/hrf:section/@path (xs:string, 1) - This text attribute is a path segment, used to construct the full path to the section from the root of the HDR document. Valid characters are [a-z][A-Z][0-9] and [.]. The full path to a section is obtained by starting with a forward slash (“/”), and concatenating the path segments, separated by forward slashes.  It is RECOMMENDED that organizations creating hData Content Profiles use their domain name in the first path segment (such as e.g. org.hl7.sample) to avoid namespace collisions in the full path name. 
• /hrf:sections/hrf:section/@extensionId (xs:string, 1) - This identifier MUST be equal to the identifier of any of the registered extension elements, as identified by the id attribute of the <extension> element. It describes the default contentType for documents contained in this section. Note that the metadata for each individual document MAY override the default contentType. 
• /hrf:sections/hrf:section/@name (xs:string, 0..1)  - Used for a human-friendly name to this section.
• /hrf:sections/hrf:section/@requirement (xs:string, 1)  – this required attribute indicates if a given section is required or optional. Valid values are “required” or “optional”. NOTE: This attribute MUST be “required” the root document for HDRs. It is only used as “optional” for the hData Content Profile Description Language (see Section 2.3.2). 

The root document schema MAY be extended to support additional features such as a mechanism to record versions of the data contained in the document. 

Extensions define the default type of section documents that appear in a section. Extensions MUST be identified by a globally unique identifier. It is RECOMMENDED that this unique identifier be a URL pointing to a RDDL document. Section documents MAY override the default type in their metadata, but only with Extensions that are registered in the root document.

The  RDDL document will assist in the creation, consumption or validation of section documents. It is RECOMMENDED that Extensions using XML-based section documents include a <rddl:resource> element with the xlink:role attribute set to “http://www.w3.org/2001/XMLSchema”. For Extensions using other content types, it is RECOMMENDED that the RDDL document includes a description of the acceptable content in section documents.

From an HL7 RLUS Service Functional Model perspective, each Extension is a semantic signifier, and the root.xml document defines a default semantic signifier for each section. 

Sections within an hData record form an abstract hierarchy, similar to the file folder structure commonly used in hierarchical file systems. Sections can contain either documents or other sections. Sections are identified by their path. The path to a section is constructed by starting with a forward slash (“/”) and appending all section path names from the root of the HDR to the section. Section documents contained in sections comply with the contentType of an Extension registered in the root document. An Extension MUST be listed in /hrf:extensions for it to be used by a section. Sections MAY use the same semantics for confidentiality, access control, and consent as described in the metadata for section documents in 2.5.1. Sections MAY be empty.

This specification does not specify how patient consent, privacy policy, and access controls are to be implemented. Any underlying transport mechanism MUST be able to provide a system for providing functionality to limit access to the overall record or portions thereof. Requirements for access to the overall record, as well as individual sections MUST be documented in detail in the hData Content Profile (see section 3). The underlying transport MUST guarantee to be able to provide the security requirement specified in the hData Content Profile. 

Similar to RLUS [4], the definition of the payloads contained in an HDR is beyond the scope of the HL7 hData specification. The HCP definition document (see section 3.3) or the metadata for each document contains the RLUS semantic signifiers ([4], section 9.1) for the section document resource in the form of a URI. As such, any HL7 Version 3 compliant HCP will need to be accompanied by a Localized Information Model (LIM) that formally describes the semantic signifiers. As such, an HCP constitutes Semantic Profile in the sense of [5], Section 6.1. 

The HCP documentation package is composed of the following documents: 

1. HCP definition document (see section 3.3) – This document is REQUIRED
2. Semantics of the Record – this document is REQUIRED
   1. Scope and Lifecycle of the record and its sections, and section documents
   2. Semantics of the sectional structure
3. If the HCP contains XML documents, a complete set of all applicable normative XML schemas referenced in the HCP definition document MUST be shipped as part of the package; referencing schemas is not allowed. For XML documents that cannot be described by normative schemas, a specification for describing the syntax of these documents MUST be provided by reference or shipped as part of the HCP documentation package. For non-XML based content, references to an authoritative syntax definition MUST be provided. 
4. Sample instance – A sample instance of an hData record that complies with the HCP is strongly RECOMMENDED. The sample instance SHOULD be provided through serialized section documents that are stored in a hierarchical file system corresponding to the section layout described in the HCP definition document. Sections correspond to file system directories and a XML document containing the Atom feed for the section. To simplify transmission these documents MAY be stored in a file archive supporting hierarchical file storage. 
5. Transforms to XML ITS/CDA – If the HCP uses a simplified wire format, it SHOULD provide XML transforms for converting the simplified wire format into HL7 v3 XML ITS or CDA R2 or future versions, respectively, if the exchanged data can be mapped to HL7 data types. 
6. Master documentation – This REQUIRED text document MUST include the purpose, applicable business requirements, and a basic justification for the HCP need. It is REQUIRED, but its scope depends on the original intent of the HCP. 
7. Behavioral model and business rules – If the domain for the HCP must adhere to a behavioral model or a set of business rules, these MUST be documented. This documentation SHOULD include applicable UML diagrams or similar documentation. This document is REQUIRED if a behavioral model or business rules exist. This section MUST include any security requirement such as privacy policy, patient consent, and access control that apply to the data stored in the overall record, as well as each section. It is RECOMMENDED to enumerate security requirements per (i) record, (ii) section document, (iii) extension, (iv) specific section document, if applicable. 
8. Use cases – The applicable use cases SHOULD be captured in a suitable document. 
9. Testing and conformance documents – If there are any additional testing or conformance requirements, these SHOULD be documented here. This MUST include security conformance requirements, if applicable. 
10. Change log – This REQUIRED document must contain the following information for the current and every prior version of the HCP: 
    1. Date of change
    2. Name of editors and/or organization
    3. Version-aware identification URL (see 11.a)
    4. Major changes
    5. Other comments
11. Other Metadata – This REQUIRED metadata can be documented in a single HTML document.
    1. URL for identification – This URL MUST be version aware, i.e. it MUST be different for differing versions of the HCP. This can be achieved by including the change year and month in the URL. The URL SHOULD resolve to a publicly accessible HTML resource that contains links to all documents needed for the HCP. 
    2. Name, summary, initial creation date 

The hData Content Profile Documentation Package may help to formulate a U.S. National Information Exchange (NIEM) Information Exchange Package Documentation (IEPD), if this data model management methodology is used by hData implementers. 

To describe hData Content Profiles, the following schema is used for the HCP definition file: 

• /hcp:hcp – the root element for a HCP definition file. 
• /hcp:hcp/@name (xs:string, 1) – a simple display name
• /hrf:hcp/@id (xs:anyURI, 1) – a URI identifying the hData Content Profile. It is RECOMMENDED to use a URL that can be resolved into the HCP definition document. 
• /hrf:hcp/hrf:extensions (hrf:extension, 0..*) – this element describes the extensions used in this HCP. It uses the same syntax as in the root document as described in section 2.2. 
• /hrf:hcp/hrf:sections (hrf:extension, 0..*) – this element describes the sections that are to be included in a hData record that claims conformance to the HCP. It uses the same syntax as in the root document as described in Section 2.2. Note that the requirements attribute(described above) is used in the HCP. 

This section contains the schema for the root document (see Section 2.2). All instances of root documents MUST validate against this schema definition. 

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright 2009-11 The MITRE Corporation

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License. -->

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:core="http://www.hl7.org/schemas/hdata/2009/06/core" elementFormDefault="qualified" targetNamespace="http://www.hl7.org/schemas/hdata/2009/06/core">
  <xs:element name="root">
    <xs:complexType>
      <xs:all>
        <xs:element ref="core:id"/>
        <xs:element ref="core:version"/>
        <xs:element ref="core:created"/>
        <xs:element ref="core:lastModified"/>
        <xs:element ref="core:extensions"/>
        <xs:element ref="core:sections"/>
      </xs:all>
    </xs:complexType>
  </xs:element>
  <xs:element name="id" type="xs:string"/>
  <xs:element name="version" type="xs:string"/>
  <xs:element name="created" type="xs:date"/>
  <xs:element name="lastModified" type="xs:date"/>
  <xs:element name="extensions">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="core:extension"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="extension">
    <xs:complexType mixed="true">
      <xs:attributeGroup ref="core:extension"/>
    </xs:complexType>
  </xs:element>
  <xs:element name="sections">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="core:section"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:attributeGroup name="extension">
    <xs:attribute name="contentType" type="xs:string" use="optional"/>
    <xs:attribute name="extensionId" type="xs:string" use="required"/>
  </xs:attributeGroup>
  <xs:element name="section">
    <xs:complexType>
      <xs:sequence>
        <xs:element minOccurs="0" maxOccurs="unbounded" ref="core:section"/>
      </xs:sequence>
      <xs:attribute name="path" use="required"/>
      <xs:attribute name="name" use="optional"/>
      <xs:attribute name="extensionId" use="required"/>
      <xs:attribute name="requirement" use="required">
        <xs:simpleType>
          <xs:restriction base="xs:token">
            <xs:enumeration value="mandatory"/>
            <xs:enumeration value="optional"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:attribute>
    </xs:complexType>
  </xs:element>
</xs:schema>
			

This section contains the schema for the hData Content Profile defintion (see Section 3). All instances of HCP definition documents MUST validate against this schema definition.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright 2010 The MITRE Corporation
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and limitations under the License. -->

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:hcp="http://www.hl7.org/schemas/hdata/2010/04/hcp" xmlns:core="http://www.hl7.org/schemas/hdata/2009/06/core" elementFormDefault="qualified" targetNamespace="http://www.hl7.org/schemas/hdata/2010/04/hcp">
  <xs:import namespace="http://www.hl7.org/schemas/hdata/2009/06/core" />
  <xs:element name="hcp">
    <xs:complexType>
      <xs:all>
        <xs:element ref="core:extensions"/>
        <xs:element ref="core:sections"/>
      </xs:all>
      <xs:attribute name="name" use="required" type="xs:string"/>
      <xs:attribute name="id" use="required" type="xs:anyURI"/>
    </xs:complexType>
  </xs:element>
</xs:schema>
			

This section contains the schema for the section document metadata (see Section 2.3.2 ). All instances of metadata documents MUST validate against this schema definition.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright 2009 The MITRE Corporation
    
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at
    
    http://www.apache.org/licenses/LICENSE-2.0
    
    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License. -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:hd-md="http://www.hl7.org/schemas/hdata/2009/11/metadata"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#" elementFormDefault="qualified"
    targetNamespace="http://www.hl7.org/schemas/hdata/2009/11/metadata">
    <xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
        schemaLocation="http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/xmldsig-core-schema.xsd"/>
    <xs:element name="DocumentMetaData">
        <xs:annotation>
            <xs:documentation>
                DocumentMetaData is the top-level element for the hData meta data specification. It is 
                embedded with every Atom 1.0 Content node.  
            </xs:documentation>
        </xs:annotation>
        <xs:complexType>
            <xs:sequence>
                <xs:element minOccurs="0" name="PedigreeInfo" type="hd-md:PedigreeInfo"
                    maxOccurs="unbounded">
                    <xs:annotation>
                        <xs:documentation>
                            This optional node holds the pedigree information for the Section Document. 
                        </xs:documentation>
                    </xs:annotation>
                </xs:element>
                <xs:element name="Title" type="xs:string">
                    <xs:annotation>
                        <xs:documentation>
                            This required element holds the title of the Section Document.
                        </xs:documentation>
                    </xs:annotation>
                </xs:element>
                <xs:element minOccurs="0" name="LinkedDocuments">
                    <xs:annotation>
                        <xs:documentation>
                            This optional node holds a list of URI links to documents that are related to this
                            Section Document. Use depends on the semantics of the Section Document Type. 
                        </xs:documentation>
                    </xs:annotation>
                    <xs:complexType>
                        <xs:sequence>
                            <xs:element maxOccurs="unbounded" name="Link" type="hd-md:LinkInfo"/>
                        </xs:sequence>
                    </xs:complexType>
                </xs:element>
                <xs:element name="RecordDate">
                    <xs:annotation>
                        <xs:documentation>
                            This required node holds the information about Document creation and modification. 
                        </xs:documentation>
                    </xs:annotation>
                    <xs:complexType>
                        <xs:sequence>
                            <xs:element name="CreatedDateTime" type="xs:dateTime">
                                <xs:annotation>
                                    <xs:documentation>
                                        This required element contains the dateTime of creation of this documment. If this document is not derived (see PedigreeInfo), this is the time of the creation of the original. If this document is derived from another origin, this element contains the date of derivation. 
                                    </xs:documentation>
                                </xs:annotation>
                            </xs:element>
                            <xs:element minOccurs="0" name="Modified">
                                <xs:annotation>
                                    <xs:documentation>
                                        This optional node is first created when the document is changed for the first time. It contains a collection of modification dates with optional pedigree information of the modifier. 
                                    </xs:documentation>
                                </xs:annotation>
                                <xs:complexType>
                                    <xs:sequence minOccurs="1" maxOccurs="1">
                                        <xs:element maxOccurs="unbounded" name="ModifiedInfo"
                                            type="hd-md:ChangeInfo"/>
                                    </xs:sequence>
                                </xs:complexType>
                            </xs:element>
                            <xs:element name="Copied">
                                <xs:complexType>
                                    <xs:sequence>
                                        <xs:element maxOccurs="unbounded" name="CopiedInfo"
                                            type="hd-md:ChangeInfo"/>
                                    </xs:sequence>
                                </xs:complexType>
                            </xs:element>
                        </xs:sequence>
                    </xs:complexType>
                </xs:element>
                <xs:element minOccurs="0" name="Confidentiality" type="xs:string">
                    <xs:annotation>
                        <xs:documentation>
                           This element contains controls for confidentiality and MUST be equivalent to the ClinicalDocument.confidentialityCode in CDA R2
                        </xs:documentation>
                    </xs:annotation>
                </xs:element>
            </xs:sequence>
            <xs:attribute name="MediaType" type="xs:string" use="optional">
                <xs:annotation>
                    <xs:documentation>
                    This attribute contains the media type of the document itself. If it is not present, the 
                    default media type of the content type is assumed. 
                </xs:documentation>
                </xs:annotation>
            </xs:attribute>
            <xs:attribute name="ContentType" type="xs:anyURI" use="optional">
                <xs:annotation>
                    <xs:documentation> This attribute contains the URI for the content type of this document. If it is not present, the content type for the Section is implied. Note that the current hData Content Profiles assume that the content type for all Section Documents within a given Section is uniform.
                    </xs:documentation>
                </xs:annotation>
            </xs:attribute>
        </xs:complexType>
    </xs:element>
    <xs:complexType name="PedigreeInfo">
        <xs:annotation>
            <xs:documentation>
                This node contains the pedigree information. 
            </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element minOccurs="0" name="XmlSignature" maxOccurs="unbounded">
                <xs:annotation>
                    <xs:documentation> This optional node contains the signature information on
                        the document or this meta data. </xs:documentation>
                </xs:annotation>
                <xs:complexType>
                    <xs:sequence>
                        <xs:element ref="ds:Signature">
                            <xs:annotation>
                                <xs:documentation> This Signature MUST contain: 
                                    1. a valid Reference to either the metadata or the Section Document 2. the ds:KeyInfo for the signer (optional with DSig - required here)
                                </xs:documentation>
                            </xs:annotation>
                        </xs:element>
                    </xs:sequence>
                    <xs:attribute name="documentMethod">
                        <xs:annotation>
                            <xs:documentation>This optional attribute indicates what method was used to transform binary Section Document mediatypes into XML files for signature. Currently the only permitted methods are xml and base64. xml is the default XML signature over XML documents. base64 encodes a data stream into an XML document. The root node it root and contains the BASE64 encoded data. </xs:documentation>
                        </xs:annotation>
                        <xs:simpleType>
                            <xs:restriction base="xs:string">
                                <xs:enumeration value="base64"/>
                                <xs:enumeration value="xml"/>
                                <xs:enumeration value="sha256"/>
                            </xs:restriction>
                        </xs:simpleType>
                    </xs:attribute>
                </xs:complexType>
            </xs:element>
            <xs:element minOccurs="0" maxOccurs="1" name="Source">
                <xs:annotation>
                    <xs:documentation>This node indicates the source of this data. </xs:documentation>
                </xs:annotation>
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="PedigreeInfo" type="hd-md:PedigreeInfo" minOccurs="0"
                            maxOccurs="unbounded"/>
                        <xs:element maxOccurs="unbounded" minOccurs="0" name="Document"
                            type="hd-md:LinkInfo"/>
                    </xs:sequence>
                    <xs:attribute name="derived" type="xs:boolean">
                        <xs:annotation>
                            <xs:documentation>If the data is derived (i.e. copied or compiled from other sources) this attribute MUST be set to true. </xs:documentation>
                        </xs:annotation>
                    </xs:attribute>
                </xs:complexType>
            </xs:element>
            <xs:element name="Author">
                <xs:annotation>
                    <xs:documentation>The identifier of the creators of this document. For derived documents, this is the author. Note that this identifier can identify machines as well as humans. </xs:documentation>
                </xs:annotation>
                <xs:complexType>
                    <xs:simpleContent>
                        <xs:extension base="xs:string">
                            <xs:attribute name="typeCode" type="xs:string">
                                <xs:annotation>
                                    <xs:documentation>This OPTIONAL attribute indicates the specific role of the author. It is RECOMMENDED to use the following list of roles, which if used MUST semantically correspond to the participant roles listed in HL7 CDA R2 (section 4.2.2.) header. The CDA R2 specification is the authoritative list. 
o	authenticator 
o	author
o	custodian
o	dataEnterer
o	informant
o	legalAuthenticator
o	participant
o	performer
o	recordTarget
</xs:documentation>
                                </xs:annotation>
                            </xs:attribute>
                            <xs:attribute name="role" type="xs:string">
                                <xs:annotation>
                                    <xs:documentation>This OPTIONAL attribute indicates the role of the author with respect to the patient (ie: admitting physician, nurse assistant). It is RECOMMENDED that the values used in this field correspond to HL7 ParticipationFunction.</xs:documentation>
                                </xs:annotation>
                            </xs:attribute>
                            <xs:attribute name="id" type="xs:string">
                                <xs:annotation>
                                    <xs:documentation>This OPTIONAL attribute indicates the identifier of the author. </xs:documentation>
                                </xs:annotation>
                            </xs:attribute>
                        </xs:extension>
                    </xs:simpleContent>
                </xs:complexType>
            </xs:element>
            <xs:element minOccurs="0" name="Organization">
                <xs:annotation>
                    <xs:documentation>This element identifies the organization. </xs:documentation>
                </xs:annotation>
                <xs:complexType>
                    <xs:simpleContent>
                        <xs:extension base="xs:string">
                            <xs:attribute name="id" type="xs:string">
                                <xs:annotation>
                                    <xs:documentation>This OPTIONAL attribute indicates the identifier of the organization.</xs:documentation>
                                </xs:annotation>
                            </xs:attribute>
                        </xs:extension>
                    </xs:simpleContent>
                </xs:complexType>
            </xs:element>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="LinkInfo">
        <xs:annotation>
            <xs:documentation>This node contains the link information</xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="Target">
                <xs:annotation>
                    <xs:documentation>This required element of type anyURI contains the absolute link to the referenced Section Document.</xs:documentation>
                </xs:annotation>
                <xs:complexType>
                    <xs:simpleContent>
                        <xs:extension base="xs:anyURI">
                            <xs:attribute name="targetExtension" type="xs:anyURI">
                                <xs:annotation>
                                    <xs:documentation>Semantic signifier for content at target </xs:documentation>
                                </xs:annotation>
                            </xs:attribute>
                        </xs:extension>
                    </xs:simpleContent>
                </xs:complexType>
            </xs:element>
            <xs:any maxOccurs="unbounded" minOccurs="0" processContents="lax"/>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="ChangeInfo">
        <xs:annotation>
            <xs:documentation>This node contains the change time and data pedigree information. </xs:documentation>
        </xs:annotation>
        <xs:sequence>
            <xs:element name="ChangeDateTime" type="xs:dateTime">
                <xs:annotation>
                    <xs:documentation>
                            This required element record a dateTime when the document was modified. 
                        </xs:documentation>
                </xs:annotation>
            </xs:element>
            <xs:element minOccurs="0" name="PedigreeInfo" type="hd-md:PedigreeInfo">
                <xs:annotation>
                    <xs:documentation>
                            This optional node contains the pedigree information of the modifier. 
                        </xs:documentation>
                </xs:annotation>
            </xs:element>
        </xs:sequence>
    </xs:complexType>
</xs:schema>
			

The contents of the hData Record are described within the root.xml document (see Section 2.2). For the hData record outlined above, the root.xml document looks like this:

<?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">
  <id>125123124312</id>
  <version>1</version>
  <created>2010-02-09T15:01:35-5:00</created>
  <lastModified>2010-02-09T19:35:44-5:00</lastModified>
  <extensions>
    <extension extensionId="1" 
               contentType="application/hl7-sda+xml">
      http://hl7.org/v3/cda-r2/ccd
    </extension>
    <extension extensionId="2"
               contentType="application/xml">
      http://hl7.org/hdata/2012/01/patientid
    </extension>
    <extension extensionId="3"
               contentType="image/png">
      http://picturealliance.example.com/png/2011/05
    </extension>
    <extension extensionId="4"
               contentType="application/xml"
      http://hl7.org/hdata/2012/01/allergies
    </extension>
    <extension extensionId="5"
               contentType="application/xml"
      http://hl7.org/hdata/2012/01/medications
    </extension>
    <extension extensionId="6"
               contentType="application/xml"
      http://hl7.org/hdata/2012/01/vitalsigns
    </extension>
    <extension extensionId="7">
      urn:empty
    </extension>
  </extensions>
  <sections>      
    <section path="org.hl7.ccd" extensionId="1" requirement="required"  />
    <section path="org.hl7.patientid" extensionId="2" requirement="required"  />
    <section path="com.provider.face" extensionId="3" requirement="required"  />
    <section path="org.hl7.simplified" extensionId="7" requirement="required">
      <section path="allergies" extensionId="4" requirement="required"  />
      <section path="medications" extensionId="5" requirement="required"  />
      <section path="vital signs" extensionId="6" requirement="required"  />
    </section>
  </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 root document also contains a list of extensions. Extensions identify the formats of section documents. As such, they are the HL7 RLUS semantic signifiers for the Section Documents. 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 a RDDL document that provide a machine-resolvable link to the XML Schema for the documents that this extension is describing. For non-XML content, a description of the content type (such as e.g. PNG documentation) should be provided at the URL used for identifying the extension. 

The sections identify their default content by referencing the extensionId attributes of the extension nodes. They also contain the path segment that is used to construct the full path to the section. It should be noted that sections can be nested. In this example, the results folder contains an empty folder (org.hl7.simplified) that cannot contain documents since its extension is “urn:empty”. However, it will still have an Atom feed which will provide links to the nested sections.

The metadata for section document is provided at the section level through an Atom 1.0 feed (see Section 2.6). Below is a sample feed for the /org.hl7.simplified/allergies section. Other sections will have very similar feeds, that describe contained section documents and nested sections. 

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" 
     xmlns:hrf-md="http://projecthdata.org/hdata/schemas/2009/11/metadata">
  <title>/org.hl7.simplified/allergies</title>
  <link href="http://example.org/patient1234/org.hl7.simplified/allergies/" 
        rel="self" />
  <updated>2011-12-13T18:30:02Z</updated>
  <entry>
    <id>allergy1.xml</id>
    <link href="http://example.org/patient1234/org.hl7.simplified/allergies/allergy1.xml" type="application/xml"/>
    <updated>2011-12-13T18:30:02Z</updated>
    
    <hrf-md:DocumentMetaData>
      <hrf-md:RecordDate>
        <hrf-md:CreateDateTime>
          2009-10-10T09:21:55Z
        </hrf-md:CreatedDateTime>
        <hrf-md:Modified>
          <hrf-md:ModifiedDateTime>
            2011-12-13T18:30:02Z
          </hrf-md:ModifiedDateTime>
        </hrf-md:Modified>
      </hrf-md:RecordDate>
      <hrf-md:LinkedDocuments>
        <hrf-md:LinkInfo>
          <hrf-md:Target targetExtension=" http://hl7.org/hdata/2012/01/allergies">
http://example.com/additionalPatientInfo/patient1234/allergyhistory
          </hrf-md:Target>
        </hrf-md:LinkInfo>
      </hrf-md:LinkedDocuments>
    </hrf-md:DocumentMetaData>
  </entry>
  <entry>
    <id>allergy2.xml</id>
    <link href="http://example.org/patient1234/org.hl7.simplified/allergies/allergy2.xml" type="application/xml"/>
    <updated>2010-02-27T12:21:11Z</updated>
    <hrf-md:DocumentMetaData>
      <hrf-md:PedigreeInfo>
        <hrf-md:Author typeCode="author" role="admitting physician">Dr. John Doe</hrf-md:Author>
        <hrf-md:Organization>Sample Provider, Inc.</hrf-md:Organization>
      </hrf-md:PedigreeInfo>
      <hrf-md:RecordDate>
        <hrf-md:CreatedDateTime>
          2010-02-27T12:21:11Z
        </hrf-md:CreatedDateTime>
      </hrf-md:RecordDate>
    </hrf-md:DocumentMetaData>
  </entry>
</feed>
			

The following hData Content Profile description document describes the hData Record in this example. Note that the simplified sections have been marked as optional. 

<?xml version="1.0" encoding="UTF-8"?>
<hcp xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns="http://projecthdata.org/hdata/schemas/2010/04/hcp"
     xmlns:hrf="http://projecthdata.org/hdata/schemas/2009/06/core"
     id="http://example.com/hdata/hcp/2011/05/sample"
     name="Example hData Content Profile" >
  <hrf:extensions>
    <hrf:extension extensionId="1" 
               contentType="application/hl7-sda+xml">
      http://hl7.org/v3/cda-r2/ccd
    </hrf:extension>
    <extension extensionId="2"
               contentType="application/xml">
      http://hl7.org/hdata/2012/01/patientid
    </extension>
    <hrf:extension extensionId="3"
               contentType="image/png">
      http://picturealliance.example.com/png/2011/05
    </hrf:extension>
    <hrf:extension extensionId="4"
               contentType="application/xml"
      http://hl7.org/hdata/2012/01/allergies
    </hrf:extension>
    <hrf:extension extensionId="5"
               contentType="application/xml"
      http://hl7.org/hdata/2012/01/medications
    </hrf:extension>
    <hrf:extension extensionId="6"
               contentType="application/xml"
      http://hl7.org/hdata/2012/01/vitalsigns
    </hrf:extension>
    <hrf:extension extensionId="7">
      urn:empty
    </hrf:extension>
  </hrf:extensions>
  <hrf:sections>      
    <hrf:section path="org.hl7.ccd" extensionId="1" requirement="required" />
    <hrf:section path="org.hl7.patientid" extensionId="2" requirement="required"  />
    <hrf:section path="com.provider.face" extensionId="3" requirement="required"  />
    <hrf:section path="org.hl7.simplified" extensionId="7"   
                 requirement="optional">
      <hrf:section path="allergies" extensionId="4" 
                   requirement="optional" />
      <hrf:section path="medications" extensionId="5" 
                   requirement="optional" />
      <hrf:section path="vital signs" extensionId="6" 
                   requirement="optional" />
    </hrf:section>
  </hrf:sections>
</hcp>