Balisage Paper: hData — A Simple XML Framework for Health Data Exchange

Electronic Health Data Exchange

Electronic documentation of health care data is currently at the heart of the U.S. national discussion on healthcare reform. While there is no universally accepted definition of an Electronic Health Record (EHR), we follow the common approach of referring to the entirety of the electronic data about a single patient as the complete EHR, while the data stored in a single system is referred to as the Electronic Medical Record (EMR) [1] [2]. Electronic Health Record Systems (EHR Systems) have existed since the 1960s with the introduction of MUMPS [3] and have benefited from the information technology advancements of the last 40 years. However, health data exchange interoperability and other usability issues have plagued system-wide adoption [4] and have thus limited the expected benefits. As of 2009, adoption rates in the U.S. have been as low as 11% for hospitals [5] while only 17% of all U.S. physicians have access to an EHR System [6].

For achieving quality outcomes and economic efficiencies, summary of care information plays a special role. Ideally, the entire relevant medical history of a patient is recorded in a set of summary of care documents securely available to patients and their clinicians on demand. This way, the entire care team gets the same exact and complete picture of the patient’s health data, without costly repeated examinations, duplicate lab tests, and partially reported conditions or results (reported to one physician, but absent from another physician’s records).

The Path to HITSP C32

Health Level Seven (HL7) is a health standards organization whose work focused on health data standards by creating the clinical document architecture (CDA) [7]. The CDA was created with complete coverage of edge cases in mind: using the CDA, one can expect to address nearly all documentation needs in any health care system. Consequently, this approach made the schema extremely flexible but overly complex, hard to implement in an interoperable design, and difficult to manage. In the meantime, the Massachusetts Medical Society and others created a simpler continuity of care record (CCR), not based on the CDA. Eventually, another standards organization, ASTM International, adopted the CCR as its proposed continuity of care record standard [8].

HL7 reconciled its standards with ASTM by taking the data elements found in the CCR and encoding them in the CDA, with the resulting standard being called the Continuity of Care Document (CCD). As part of the U.S. national initiative in Health Information Technology (HIT), the American National Standards Institute (ANSI) and its affiliated Health Information Technology Standards Panel (HITSP) recommended that the CCD be used as an input standard for creating a national continuity of care standard. The result was initially published as the HITSP Construct 32 standard (C32) [9]. The module content and supporting vocabularies were recently migrated to HITSP documents C80 [10] and C83 [11]. As a result, the latest HITSP C32 is essentially only a reference to C80 and C83. The entire document suite has been significantly expanded and has grown more complex.

Criticism of the CDA and C32

There are several shortfalls in the CDA, C32, and related standards. Most of these were experienced firsthand when we implemented “Laika,” an open source C32 compliance testing tool set (http://projectlaika.org). Four of the key issues are described below.

While we are not aware of any widespread operational deployment of CDA or C32 for health information exchanges, work on these standards has created useful medical domain expertise in the health industry. HITSP has recognized the complexity of the existing CDA-based standards and has completed an effort to “streamline” the standards and the documentation on how to use them [12]. At the heart of this effort lies the definition of HITSP Capabilities and Service Collaborations. The Capabilities are essentially profiles of existing HITSP Constructs which then map to requirements of the American Recovery and Reinvestment Act (ARRA) [13] (see http://hitsp.org/default.aspx?show=library for an overview of the HITSP Constructs and [14] for the EHR Centric Interoperability Specification). The HITSP architecture approach after the Spring 2009 Tiger Team review is described in [15]. While this document reordering may provide some help, exchanging continuity of care information will still take place in the same overly complex format.

Additionally, the entire existing HITSP framework does not always deliver a comprehensive, interoperable set of specifications, thus exacerbating interoperability problems. For example, the latest revision of the HITSP C19 Construct [16] references Integrating the Health Enterprise (IHE) IT Infrastructure Technical Framework (ITI-TF) Volume 2 [17]and relies on ITI-TF 2, section 3.40, “Provide X-User Assertion” for exchanging user attributes. Section 3.40 is a very loose profile of using restricted SAML 2.0 assertions [18] with WS-Security [19] and WS-Trust 1.3 [20]. It is unclear why WS-Trust was chosen over the SAML 2.0 protocol, especially since WS-Trust does not define use case profiles, processing rules, or static conformance rules. IHE failed to provide complete use case profiles and processing rules in its specification. Omissions like these invite vendor-specific interpretations of the underlying standards and—in the absence of coordinated, point-to-point interoperability certification testing—will lead invariably to non-interoperable solutions.

hData Overview

The hData Record Format (HRF) follows the approach taken by the Open Document Format (ODF) [24] and other modern XML file formats: at the core of the document is a “root” document containing metadata describing the actual medical data documents, which are located within a hierarchy of sections. These individual XML documents are referred to as “section documents” and are located within a section. Any given section can only contain section-documents of one type or other sections. These sections can easily be represented as a file folder hierarchy on disk or within a ZIP file, or as web resources.

The hData Record Format was created with extensibility in mind. Since we do not expect to be able to address all potential use cases with a single HCP, hData can be extended by defining new sections for additional XML documents to deliver additional functionality with almost no limitations to the format of the extensions. While highly desirable, we do not expect that all consumers of hData will be required or, indeed, will be capable of parsing all documents, so extensions must be marked as mandatory or optional.

Finally, the NQF-35 hData Content Profile aims to enhance EHR data quality by enforcing strict rules on the non-narrative parts of the record to allow automated machine processing. C32 and related formats often use narrative fragments within fields that are intended for machine consumption, thus breaking interoperability. For example, dates can be specified through descriptive terms such as “a week ago”. While there is a requirement to capture the fact that a date is ambiguous, resorting to unstructured text creates significant interoperability issues and makes machine parsing of EHRs unnecessarily complex. By restricting common data types to well-established type definitions, hData lowers the interoperability barrier and simplifies the creation of health care software.

Record Organization

Data in the hData Record Format is stored in a set of linked standalone XML documents. Each data point in a patient’s record is captured in an independent standalone XML document. The collection of these documents, along with some organizational metadata, constitutes an hData Record that conforms to the HRF specification. There is no constraint on the XML schema used in each of these individual documents: existing data (e.g., legacy data, machine generated lab results, etc.) can be integrated into an HDR without loss of fidelity by adding a section for the legacy data XML documents. Non-XML data can be wrapped either through simple transforms where possible, or by encoding the data in a form suitable for XML storage (e.g., by using BASE64 encoding for binary data).

1: HRF Structure

These independent documents are linked and organized in a hierarchy: a “root” document contains metadata about the structure and content of the collection. In particular, the following metadata resides in the root document:

There is no restriction on the content of the section, with the exception that the “section documents” must be expressed in XML and have a type registered as an extension in the root document. Figure 2 contains a very simple example of a root document.

<root xmlns="http://projecthdata.org/hdata/schemas/2009/06/core">
    <documentId>c64e620d-f648-4531-9703-14b37afefc2c</documentId>
    <version>0.1</version>
    <created>2009-07-12-04:00</created>
    <lastModified>2009-07-12-04:00</lastModified>
    <extensions>
        <extension requirement="mandatory">
            http://projecthdata.org/hdata/schemas/2009/09/patientinformation
        </extension>
        <extension requirement="mandatory">urn:empty</extension>
        <extension requirement="mandatory">
            http://projecthdata.org/hdata/schemas/2009/06/allergies
        </extension>
    </extensions>
    <sections>
        <section 
                typeId="http://projecthdata.org/hdata/schemas/2009/09/patientinformation" 
                name="Patient Information" 
                path="patientinformation"/>
        <section 
                typeId="urn:empty" 
                name="Adverse Reactions" 
                path="adversereactions">
            <section 
                    typeId="http://projecthdata.org/hdata/schemas/2009/06/allergies" 
                    name="Allergies" 
                    path="allergies"/>
        </section>
    </sections>
</root>
                

Network Access to hData Records

The data represented by an hData Record should be simple to exchange from one EHR System to another. The hData Record Format lends itself ideally for RESTful applications: the same hierarchy that can be represented in a file folder structure can transfer directly to a URL hierarchy. With this representation in mind, we define a RESTful Application Programming Interface (API) to edit the patient hData Record through HTTP at the section and section document level. This approach is much more efficient than the complex IHE XDS protocol [26] currently proposed for sharing CDA-based health data.

By using the HTTP GET verb, any part of an HRF document can be read: the root document is directly accessible through the base URL of the HRF. The root document contains all necessary metadata to access the medical information contained in the HRF document, including a list of all mandatory and optional document types a parser must implement. Each section is accessible as a sub-resource, identified by its path-segment, which in turn is used to compute the absolute URL to the section resource. A GET operation on the URL of a section (or sub-section) resource returns an Atom 1.0 feed of all documents or a feed of its sub-sections. The returned results can be filtered by using HTTP headers, such as TE (Transfer Extension) headers [27], or other appropriate query parameters. For example, a GET on /immunizations with If-Modified-Since set to a specific date, would only return immunizations that have been administered since a given date.

Modifications of the HDR are implemented analogously. New section documents can be added or modified through PUT or POST operations; DELETE works in the same fashion, although we recommend well-defined auditing processes when deleting data from an HDR. Again, HTTP headers can be used: ETags are highly useful for PUTs. For example, a new allergy can be added to the document by PUTting an allergy document into the /adversereactions/allergies section in the document hierarchy.

Existing EHR systems (such as the U.S. Veterans Administration’s VistA) can be retroactively equipped with hData capabilities without having to re-architect the underlying EHR system.

C32 Interoperability and the L32

In order to maintain interoperability with existing EHR implementations that use the C32, we also introduce a mechanism to map between hData and a tightly profiled version of the HITSP C32 standard, called the “Lightweight C32.” The “Lightweight C32,” or L32 for short, is a specification that bridges between CDA-based architectures and hData. There are two “modes” for L32: native and compatibility. Both remove some of the ambiguity found in the HITSP standard. A native mode L32 document can be easily validated against the new L32 XML Schema, which is not compliant with the C32 and CDA standards. This is due to the use of xsi:type attributes in the L32 that facilitate the creation of a more concrete schema. For L32 documents in compatibility mode, these xsi:type attributes can be added via XSLT to provide compatibility with the C32 standard. Conversion between native and compatibility mode is performed through a simple XLST transform.

L32 provides a simpler path to generate a document that will be C32 conformant, and satisfies the requirements of current and proposed EHR legislation in the U.S. L32 is currently under development; more information is available on the Project hData home page at http://projecthdata.org/.

Mapping between hData and L32 is achieved through a simple XSLT/XProc process. This transformation is necessary since C32 or its descendants are required in regulated U.S. EHR Systems. Using this approach, new systems can fully focus on leveraging the simplicity and precision of hData, thus eliminating the need to maintain the complex organizational knowledge and skills required for consuming or producing C32 or other CDA-based constructs. Existing systems can leverage the constrained C32 profile and the hData conversion tools to ensure that their continuity of care documents are interoperable. Since hData is capable of providing all functionality for a CDA-based document system through extensibility, the hData format allows for a natural evolution away from the CDA-based document formats.

The L32 alignment approach should not be mistaken for a solution in and of itself. The L32 maintains the cumbersome CDA legacy, and cannot address any of the problems deriving from its monolithic form. L32 is intended to ease the transition from HITSP C32, not to address all of the requirements for a comprehensive EHR health data standard. As such, L32 is limited to the continuity of care sections of the NQF-35 hData Content Profile.

HITSP Harmonization Framework

While hData introduces a new approach to the data format and replaces significant portions of the existing CDA architecture, it still fits conceptually into the HITSP architectural framework [15]. The extensive existing work on defining code systems, data standards, data dictionaries, data exchange content, and use case scenarios can be leveraged with hData through its simple extension mechanism. hData Content Profiles, if hData is eventually adopted, will rely heavily on the medical domain knowledge that HITSP and its members have been working on successfully for many years.

In fact, individual HITSP constructs (including CDA-based documents such as the C32) and other legacy EHR formats, could be included in their own section within an HDR. While this is not the intent of hData, this approach offers an easy migration path away from CDA-based health data exchange.

Access Control and Identity and Privacy Management

The hData specification does not include any access management components. We have consciously decided to focus on data modeling first, and to create hData Content Profiles for additional functionality later. At the same time, the overall architecture is well-suited for fine-grained access control that allows for privacy and addresses confidentiality needs:

There are a variety of potential ways to define identity, privacy, and access management profiles for hData, including Access Control Lists (ACLs), policy agents, or even Simple Object Access Protocol- (SOAP-) based identity web services. At this time we are focusing on demonstrating a RESTful protection scheme, which works with the hData RESTful API. It builds on the “ProtectServe” protocol that has been presented by Eve Maler et al. [30]. ProtectServe has been submitted to the User-Managed Access Working Group of the Kantara Initiative [31] for public review and standardization.

Enabling Patient-Centric Electronic Health Records

As indicated in Section “Background”, a complete EHR is the collection of all individual EHRs and EMRs across all health service providers that hold health data about a patient. Within the health community, there are many EHR Systems operated by different actors, such as health providers, government entities, insurance companies, and others. Currently, patients have very limited electronic access to their digital health data stored by other actors, and even less active control over who can access their health data. Since hData implements RESTful patterns, access to hData Records for patients can easily be implemented by giving patients access to their data over the internet. Simple stylesheets can be used to display the contained data in a human-readable form.

In addition, hData web resources can be made discoverable through web-centric protocols such as the proposed XRD 1.0 protocol [32]. By using discovery mechanisms, patients can effectively link their HDRs in different EHR Systems and create a more complete picture of their health data. By using a ProtectServe-like authorization scheme, the patient is empowered to authorize access to their records based on the identity of the requestor.

3: Notional hData use case

A combination of XRD discovery and ProtectServe authorization management is illustrated in a simple use case in Figure 3 that illustrates the following steps:

Since all protocols for this exchange are completely open and no additional knowledge beyond the location of the HDR endpoints is necessary, a patient can choose to implement their own DAS, making the system truly patient-centric. At the same time, we expect that either existing actors in the medical community such as health providers, government entities, insurance companies, or emerging service providers similar to Google Health or Microsoft HealthVault will offer DAS to patients.