RHEx+Pilots

include component="page" wikiName="siframework" page="RHEx Header" flat =TATRC Pilot= This year, the RHEx Team is partnering with the Telemedicine & Advanced Technology Research Center (TATRC) to demonstrate a secure RESTful health data exchange. As described in the Use Case section, a RHEx-enabled system and Direct secure messaging will be used by TATRC to demonstrate how the secure RESTful exchange of data can be leveraged to share information between primary care physicians and consulting providers. The objective of demonstrating improved health information exchange is ultimately enhanced coordination of care. This is a key area of focus throughout the US healthcare system.

In phase one of the TATRC pilot, the focus will be on implementing the secure exchange of health data. This will enable providers to exchange their patient data with each other to improve care coordination while maintaining security and privacy of their patients’ information. Phase one will result in the development of an OpenID Connect Identity Provider and a simple web application that allows users to log in.

Phase two of the pilot will build on the security established in phase one and provide a richer set of services by utilizing emerging standards (such as the hData RESTful Transport Specification) to support referrals. This will allow providers to explore data housed in different systems to find the information they need to make more accurate diagnoses and provide better care. Connections (i.e., links) between pieces of a patient’s health record will allow providers to explore data to find the information they need to make more accurate diagnoses and provide better care. =TATRC Use Case= The TATRC pilot employs the power of RHEx and leverages the Direct Project for secure messaging. The Direct Project develops specifications for secure, scalable addressing and transport for participants to send encrypted health information directly to known, trusted recipients over the Internet.

The use case for the TATRC pilot is designed to address an important challenge in the Military Health System (MHS) and the Department of Veterans Affairs health care system that occurs when patients are referred to consulting physicians by their primary care physician (PCP).

When a PCP orders a referral,, it is typically sent to the consulting provider via non-electronic means (e.g., paper or fax). The patient goes to the referral appointment, and the consulting provider generates a report documenting the results. Access to further detail for either provider (PCP or consulting provider) often requires phone calls or additional faxes. Furthermore, consult notes and results are not consistently sent to the PCP, leaving the PCP without the information provided by the consulting provider.

To expedite the process and provide rapid access to data, the RHEx Team and TATRC developed the following use case, leveraging RHEx and Direct. This use case is designed to ensure that the consulting provider gets the necessary details, and that the PCP gets access to the results of the consult in a timely manner. This approach closes the gap discussed earlier by allowing the PCP and consulting provider to access and retrieve current, relevant portions of patient health care records when they need them. This use case consists of the following sequence of events:
 * 1) Using an established trust relationship, the PCP sends a Direct message to the consulting physician which contains a link to the order for a referral.
 * 2) The consulting physician uses their email system to open the message, then clicks on the link, which opens in a web browser
 * 3) In the web browser, the consulting physician uses their credentials (i.e., authenticates via OpenID Connect) to view the referral housed in the PCP’s system. With authorized access, this may also allow the consulting physician to examine additional patient details linked within the referral.
 * 4) Once the consult is complete, the same approach works in the other direction
 * The consulting physician sends a Direct message back to the PCP with a link to the results of the consult.
 * When the PCP clicks on the link inside the Direct message, they provide their credentials to authenticate and then view consult results exposed on the consulting physician’s system.
 * This also allows the PCP to examine additional details linked within the consult results.

This use case which leverages RHEx and Direct is illustrated in the diagram below.

= TATRC Technical Approach =

Phase I TATRC Secure Transport Approach
The TATRC pilot leveraged the RHEx secure transport approach as described in RHEx Security Approach.

Phase II TATRC Content Approach
To implement the Content Layer of the RHEx Architecture for the TATRC pilot, two decisions needed to be made regarding the approach:
 * 1) The content payload standard, and
 * 2) The content organization and structure.

The content payload choice depends upon the selection of the data content standard. The RHEx team chose the greenCDA TM for C32 (GreenC32) for the content payload. The rationale for this choice is discussed in the Data Content Payload Standard section below.

The content organization is determined by the choice of the RESTful protocol standard. After assessing the possibilities, the RHEx team chose the hData Record Format. The options the RHEx team considered along with accompanying rationale may be found in the in the RESTful Protocol Standard section below.

Data Content Payload Standard
The Data Content Standard choice serves as the common data model necessary for effective semantic and syntactic interoperability.

The data content is intended to summarize a patient’s medical status for the purpose of clinical consultation or referral information exchange. The clinical sections represented are constrained to those that were appropriate to the narrow use case for the pilot—a specialist consultation regarding a knee-replacement.

Data for a patient record is organized into one or more sections containing one or more entries. Source data remains in its originating location; it is not transported to multiple end points. Rather, unique Uniform Resource Identifier (URI) links are used for authorized patient record access.

Here is an example URI for a medical procedure: If this procedure generated laboratory results, those results would be stored in their own documents and would have the ability to link back to the medical procedure using a URI.

The Data Content Standards for the TATRC pilot are based on the Health Information Technology Standards Profile (HITSP)/C32. The HITSP/C32 standard is based on the HL7 Continuity of Care Document (CCD). The XML structures in these standards are refined using the green Clinical Document Architecture ( greenCDA TM ) methodology process to simplify data representation and use within a RESTful interface.

Where available, clinical content sections are based on the green Clinical Document Architecture Release 2.0 ( greenCDA TM ) implementation of C32 for both content and logical data formats. greenCDATM is described in the text below:

“The Clinical Document Architecture Release 2.0 (CDA R2) addresses universal requirements for exchange and management of structured clinical documents. The approach described in this document, greenCDA TM ,maintains the full utility of the CDA R2 while defining a method of working with an implementation-specific XML (Extensible Markup Language) that is easier to implement. The approach we describe here simplifies instance creation while it asserts as a primary principle that any simplification must also define a method to deliver valid, normative CDA.”[1] The clinical content sections chosen for the TATRC Pilot are based on the content modules specified in the HITSP/C32.[2] The final sections selected – Allergies, Medications, Labs, Procedures, and Vital Signs – were aligned with the constrained use case and supportability of the AHLTA system. Additional content, such as the Referral Request and Referral Response sections are added to provide context for the Consult / Referral Use Case. The Referral Request section is based on the HL7 2.x Referral Information (RFI) segment and includes the CDA entry for Reason for Referral. Referral Response is based on HITSP/C48[3]. Social History and Chief Complaint are based on specifications in the HITSP/C83.[4] While the HITSP/C83 is the foundational standard for the HITSP/C32, the RHEx project team felt it necessary to call out the Social History and Chief Complaint sections because they are not referenced by the HITSP/C32. The greenCDA TM Process shown below was applied to the content used to develop the XML schemas being used as the common data model. This figure shows that the greenCDA TM process is an iterative method for simplifying the detailed structures present in a CDA-based standard.

greenCDA TM Process HITSP/C32 was chosen for the TATRC pilot to leverage the existing Meaningful Use requirement that HITSP/C32’s be produced from EHRs. This allows for existing code to be used to extract the baseline information.

Data Content Organization and Structure
There are 3 main goals for the Content Organization and Structure portion of the RHEx Content Approach:
 * 1) Use RESTful principles for exposing data
 * 2) Include a traversable content discovery document
 * 3) Ability to subscribe to granular data via data feeds

The TATRC pilot readily addresses the first two goals. A referral request is generated on the Primary Care Physician (PCP) system, AHLTA, which is sent as a link using a Direct message. Accessing this link provides not just meta-information about the referral request, but also contains additional links to supporting clinical information from the AHLTA system and makes it available at a granular level.

Likewise, the simulated Consulting Physician (CP) system responds in the role of the Consulting Physician (CP) by sending a Direct message with a link to the Referral Summary that is housed on the CP system. This Referral Summary includes links to additional pieces of data to establish appropriate clinical context.

There are multiple RESTful protocol standards that meet the third goal of providing access to granular data to include data feeds [|AtomPub], [|OData], and [|hData]all represent data as feeds using XML.

The RHEx pilot team is exploring two levels of [|hData] compliance to meet the third goal. The simulated CP system is fully hData compliant. It will expose granular data entries, such as allergy entries, as [|Atom] feeds. On the other hand, the simulated PCP system will be exposing at least one section of the Consult Request as an hData Atom feed.

This exploratory approach aims to provide feedback on structured services and on hData as a solution for structured services.

[|AtomPub]
The Atom protocol defines XML to represent data as lists, called feeds. The feed contains entries, each of which has metadata associated with it. AtomPub extends this to include HTTP protocol specifications for publishing and editing these feeds, including PUT, POST, and DELETE methods. AtomPub is the basis for both OData and hData.

[|OData]
OData builds upon AtomPub to include:
 * A convention for representing structured data
 * A resource addressing scheme and URL syntax
 * A set of common query options (filter, sort, etc.)
 * Schema describing resource structure, links and metadata
 * Payload formats and semantics for batch and “unit of work” requests
 * Alternate representations of resource content (JSON)

An OData feed represents its data based on its [|Entity Data Model], which is similar to an entity relationship model. The structure of this model is represented through its metadata. It maintains a high-level of specificity including fields and data types.

[|hData]
hData also builds upon AtomPub in similar ways as OData. There are three differentiating characteristics of hData that make hData a more suitable choice than OData for exploration during the TATRC Pilot:
 * Alignment with Healthcare Domain
 * Selectable level of specificity
 * Separation of technical and content concerns

Further details on these differentiating characteristics follow.

Alignment with Healthcare Domain
Although hData is flexible and could be applied to any domain, it was developed with healthcare in mind. Its hierarchical structure resembles an abstraction of a typical electronic health record (EHR) organization and a Clinical Document Architecture (CDA) structure. The hData Record Format specification states: “The basic approach of the hData Record Format is to represent medical data through linked documents, which are organized through an abstract hierarchy (see Abstract Diagram of hData Record below). The hData RESTful API specification maps this abstract hierarchy to a concrete implementation, such as a web resource hierarchy.”[5] If an implementation wishes to use OData, it could be implemented as a section feed in an hData Record. OData then exposes its feed structure via its metadata.

Selectable Level of Specificity
The use case for the TATRC pilot is the round trip referral from a Primary Care Provider (PCP) to a Consulting Physician with the Consultation Summary being returned. This use case involves presenting relevant clinical data as documents. OData specifies information at the field and data type level. hData, on the other hand, supports data at the document level. The hData approach moves data description into the hData Content Profiles, where users of the protocol can provide any level of detail on how consumers can interact with the data. This allows for varying levels of structure specificity, allowing us to pilot with both large coarse grained documents and very fine grained data elements. =HealthInfoNet Pilot= MITRE is partnering with HealthInfoNet, the Maine Health Information Exchange (HIE), to explore using RHEx technology to securely transport high volumes of Continuity of Care Documents (CCD) over the Web from providers to the Maine HIE Clinical Data Repository. HealthInfoNet needs a simple, lightweight, secure method of transferring health data to allow Maine’s small, independent providers to participate with the HIE. The high level approach to the pilot is shown in the diagram below. This approach includes installation of a RHEx client with a small footprint within the provider’s system to move data RESTfully and securely over the Web to a RHEx adaptor at the Maine HIE. Once the health data arrives at the RHEx adaptor, it is transformed and moved to the Clinical Data Repository at the Maine HIE. This approach is explained in more detail in the Technical Approach section below.

RHEx Pilot with HealthInfoNet
=HealthInfoNet Use Case= Today, patient health data from 26 hospitals and close to 200 ambulatory practices in Maine is moved to the Clinical Data Repository at HealthInfoNet in near real time. The data is transported from providers to a single hospital, and then moved to HealthInfoNet via a single Virtual Private Network (VPN) connection. The data is sent in near real time using HL7 messages. This current process is shown in the diagram below.

Health Data Flow for Connected Providers in Maine
As stated earlier, HealthInfoNet is seeking a simple, lightweight, secure method of transferring health data that will scale to connect the smaller, independent providers in the state. To meet this goal, the pilot project will test the use of RHEx technology for secure transport of CCD documents from one provider: Islands Community Medical Services, a Federally Qualified Health Center located on Vinalhaven, an island of the coast of Rockland. The data flow at Islands Community Medical Services is shown in the figure below. Once a patient visit is complete, the physician updates the patient record. The EHR system at Islands Community Medical Services, NextGen, will send a CCD document (in C32 format) in near real time to the Maine HIE system using RHEx secure transport over the Web. This data flow is shown in the figure below.

Health Data Flow for Islands Community Medical Services in Maine
Note that patients can opt out of the Maine HIE system. They can do this using a printed form available at their provider’s office or through HealthInfoNet’s secure website. If a patient chooses to opt out, then patient clinical data is not included in the Clinical Data Repository. This process will not change in the pilot, but is included below for completeness.

Patients in Maine Can Opt Out of the Maine HIE System
=HealthInfoNet Technical Approach= The technical approach to the pilot with HealthInfoNet involves the following key components. First, we utilize an automated trigger in the Islands Community Medical Services EHR system, NextGen. The trigger is used to move Continuity of Care Documents (C32 format) to a shared file system at the Islands Community Medical Services. So, after a patient visit is complete, the physician will update the patient’s record in the EHR system and a C32 will be triggered and placed into the shared file system. We built a tailored RHEx client that detects when C32s are placed in the shared file system. When a new C32 is detected, the RHEx client invokes the OAuth2 workflow to authenticate in order to establish a secure transport session with the RHEx server at HealthInfoNet. The C32 is encrypted and sent to the RHEx server using Transport Layer Security.

The RHEx server, installed in HealthInfoNet’s Demilitarized Zone (DMZ), receives the C32, unencrypts it and sends the document to a processing queue within HealthInfoNet’s firewall. The processing queue manages the incoming documents and sends the C32s to be transformed to greenC32 messages. The greenC32s are then sent to HealthInfoNet’s integration engine, Orion Rhapsody, where they are processed and sent to the Clinical Data Repository as HL7 v2 messages. This solution is shown in the figure below.

Architecture of RHEx Pilot with HealthInfoNet
A key feature of this solution is that we built a very small RHEx footprint at the provider site, which is clearly delineated from the EHR system. A small footprint was important because most small, independent providers do not have large budgets for sustainment of IT systems. The software needs to be lightweight and it must be possible to sustain the software from a remote location. Clear delineation from the EHR system was important because the RHEx software cannot impact the functioning of the EHR system. Clear delineation was achieved by using the shared file system.

A second key feature is the use of the greenCDA TM for C32 (greenC32) to represent Continuity of Care documents. The RHEx team chose to use greenC32s for content representation because it simplifies data representation and supports use within a RESTful solution. While HL7 data types are very flexible, they're not easily machine readable so instead, we use the standard XML data types where possible. We found that this made it very easy to map the schemas into HL7 v2 messages in this pilot. The RHEx content approach is discussed in greater detail in the section “Phase 2 Content Approach” under the Technical Approach for RHEx Pilot with TATRC section.

[1] Healthcare Information Technology Standards Panel (HITSP)Summary Documents Using HL7 Continuity of Care Document (CCD) Component (HITSP/C32), v. 2.5, July 8, 2009. [2] Ibid [3] HITSP Encounter Document Using IHE Medical Summary (XDS-MS) (HITSP/C48), v. 2.5, July 8, 2009. [4] Healthcare Information Technology Standards Panel (HITSP) CDA Content Modules Component (HITSP/C83), v. 2.0, January 25, 2010. [5] HL7® Version 3 Standard, © 2012 Health Level Seven® International. (February 2012). hData Record Format, release 1. Retrieved from http://www.hl7.org/documentcenter/public_temp_08FB00F3-1C23-BA17-0C2F0504CBEDE93E/standards/dstu/HL7_V3_ITS_HDATA_RF_DSTU_R1.pdf

= =

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"