RHEx+Data+Content+Standards

include component="page" wikiName="siframework" page="RHEx Header" flat =RHEx Data Content Standards Alignment= The RHEx approach to data is very flexible and is intended to be applicable to any level of granularity, standard or data specification. At a more coarse level, complete documents in any format (XML, pdf, doc, etc), can be published as a content item accessible via a web link. More granular data can be published as well, where each specific entry, such as an allergy, medication, procedure, result, etc, can be the content item. The Abstract Content Model Diagram below depicts this concept.

Abstract Content Model Diagram
These standards and levels of granularity can be combined within a given implementation. The implementations may use various content published in different standards using the same general approach. The following sections discuss how the RHEx approach applies to the following standards = Clinical Document Architecture (CDA) = HL7’s**[1]** Clinical Document Architecture (CDA)**[2]** is well suited for the RHEx Data Content approach. Each section and entry can be published and accessed via a URL. These sections and entries can be represented as an Atom feed or another publishing protocol.
 * Clinical Document Architecture (CDA)
 * HITSP C32
 * Green CDA/C32
 * Consolidated CDA
 * HL7 2.x Messages
 * DICOM Images
 * Blue Button Documents

Clinical content sections for RHEx can be based on the content modules specified in the CDA. The hierarchical nature of the CDA lends itself to allow for granular entries to be published within a content module section with a URI.

For example, the resource for the parent section containing the CDA Sections, shown as the Granular Parent Feed in the Abstract Content Model Diagram, could be as follows: http://example.org/patient1234/CDA/

This can be further granulized to the CDA sections, for example for Allergies: http://example.org/patient1234/CDA/Allergies/

Continuing to granulize, a specific Allergy could be represented as follows: http://example.org/patient1234/CDA/Allergies/Allergy1.html = HITSP C32 = The Healthcare Information Standards Panel (HITSP) defined a Summary of Care document and named it the HITSP C32. The C32 is a harmonization of the HL7 Continuity of Care Document and the ASTM Continuity of Care Record (CCR). The specification is officially called the __HITSP Summary Documents Using HL7 Continuity of Care Document (CCD) Component__.

These documents are arranged in a hierarchical manner based on the CDA. The primary difference between C32 and CDA is the constraints applied. A C32 will have sections that are derived from the CDA, however, not all CDA sections are used. Furthermore, additional constraints and extensions exist to harmonize with the CCR.

A RHEx implementation can publish these documents at the coarse level and/or the granular level. This is the same approach described in the CDA section above.

An example of how the URI may appear for a document level representation is depicted below: http://example.org/patient1234/C32/C32_1.html

Alternatively, the information can be represented at a more the more granular C32 section level: http://example.org/patient1234/C32/Allergy/allergy1.html = Green CDA/C32 = The [|HL7 Green CDA project]created a guide to simplify the implementation of CDA documents. As part of that effort, the project team developed an Implementation Guide for Green C32. The greenCDA TM describes the process for simplifying the XML format for a CDA document. Included as part of this is a translation (XSLT) to move between a full CDA and a greenCDA TM and vice versa. The guide shows an example of the greenCDA TM applied to the HITSP C32. This content can be handled in a same way as the C32, described above.

These documents can be included in a RHEx implementation as a complete, coarse document: http://example.org/patient1234/GreenC32/GC32_1.html

Alternatively, the information can be represented similar to the generic CDA, yet with each section constrained according to the specification: http://example.org/patient1234/GreenC32/Allergy/allergy1.html = Consolidated CDA (CCDA) = Due to the complexity experienced by developers in understanding and implementing the CDA documents and C32 documents, the S&I Framework Transitions of Care Initiative**[3]** developed the Consolidated CDA. This provides a single source for harmonized document specifications as well as guidelines on what to use for given use cases. The Consolidated CDA has been incorporated into ONC’s Meaningful Use Stage 2, and HL7 has published an implementation guide for Consolidated CDA templates.

The content from a CCDA can be published as a full, coarse document or as granular content items in same way as the C32 and the greenCDA TM /C32.

These documents can be included in a RHEx implementation as a complete, coarse document: http://example.org/patient1234/CCDA/CCDA_1.html

Alternatively, the information can be represented similar to the generic CDA, yet with each section constrained according to the specification: http://example.org/patient1234/CCDA/Allergy/allergy1.html = HL7 V2.x = HL7 V2.x is a clinical messaging standard that precedes the XML based HL7 V3. The messages are American Standard Code for Information Interchange (ASCII), pipe-delimited messages, with each line representing a set of data relevant to message purpose.

At the coarse level, each message could be stored as a resource: http://example.org/patient1234/HL7v2/ADT/MSH10_12345.html = Digital Imaging and Communications in Medicine (DICOM) = DICOM is the primary standard for radiological images.

DICOM images can each be published as resources for a given patient. This collection of images can be published as an Atom or other feed.

The associated URI for a specific DICOM image could be represented as follows: http://example.org/patient1234/images/dicom1.xml = Blue Button = Blue Button is a text or pdf file designed by the Veterans Administration to allow veterans a simple, human readable summary of portions of their clinical record. Since its inception in 2011, the Blue Button concept has broadened with many private insurers and vendors developing Blue Button capabilities.

Blue Button files can be published as individual resources for a given patient. This collection of files can also be published as an Atom or other feed. The associated URI could be represented as follows: http://example.org/patient1234/BlueButton/BBfile1.xml

The use of Blue Button files through a RESTful interface is now being explored by the S&I Automating Blue Button Initiative (ABBI). This effort will be drawing upon some of the materials within RHEx to achieve the ABBI goals

[1] [|Health Level Seven (HL7)] is a not-for-profit, ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of [|health services]. [2] Health Level Seven (April 2005).HL7 Clinical Document Architecture, Release 2. Retrieved from http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 [3] The [|S&I Framework] is a collaborative community of volunteers from the public and private sectors who are focused on providing the tools, services and guidance to facilitate the functional exchange of health information. The S&I Framework uses a set of integrated functions, processes, and tools that enable execution of specific value-creating initiatives. Each S&I Initiative tackles a critical interoperability challenge through a rigorous process. The Transitions of Care initiative’s purpose is to improve the exchange of core clinical information among providers, patients and other authorized entities electronically in support of meaningful use and IOM-identified needs for improvement in the quality of care.