RHEx+Approach

include component="page" wikiName="siframework" page="RHEx Header" flat =A RESTful Prototype: RHEx=

RHEx Execution
In order to demonstrate easier, secure health information exchange via RESTful design, FHA initiated the RHEx project. The RHEx project is:
 * Piloting the application of proven standards and protocols to explore a RESTful approach to exchanging health information; and
 * Requesting community involvement through this wiki and other vehicles to refine and evolve the RHEx reference implementation and profile.

Phased Approach to RHEx Development
RHEx is being developed in two phases. In the first phase, the focus is about securing RESTful interactions. This will ensure necessary standards are in place to demonstrate the secure exchange of information via the web using hypertext transfer protocol (HTTP). The second phase will focus on the content approach; providing a framework for linking to necessary health information.

The two phases of RHEx's development and delivery are: =RHEx Architecture= REST is an architectural style that can be applied to the design of IT system interfaces. Creating system interfaces that conform to the principles of REST will often result in scalable services that are easy to access. However, there are multiple ways to implement a service and still conform to the principles of REST. RHEx aims to provide a single, implementable approach to the design of RESTful Health IT interfaces to foster interoperability and enable mobile applications of HIT.
 * **Phase I:** Security approach for a RESTful health information exchange (April-July 2012); and
 * **Phase II:** Content approach for a RESTful health information exchange (July-September 2012)

To address the variation in RESTful service design, RHEx is piloting a design and presenting it to the community for feedback. The goal is to inform a path forward that will lead to an agreed-upon set of rules about designing RESTful interfaces. This is intended to eventually allow the Health IT industry to incorporate stable, secure and interoperable RESTful services. The design process of RHEx has evolved over several years with input from standards bodies, such as HL7 and OMG, to ensure that the expertise and requirements of the healthcare industry are taken into account.

The RHEx technical architecture is composed of transport, content, and security layers as depicted in the RHEx Full Stack Architecture diagram below. To enable the secure exchange of health data, the transport layer consists of Hypertext Transfer Protocol Secure (HTTPS) connection and Transport Layer Security/Secure Sockets Layer (TLS/SSL), which are used to encrypt data in transit.

RHEx Full Stack Architecture Diagram
The content layer offers a simple, lightweight method of organizing and exchanging health information based on REST principles and scalable open technologies. Patient data is arranged as a hierarchical set of resources, allowing for granular access of data via Uniform Resource Locator (URL) links. Multiple standard data formats can be accommodated in the RHEx architecture as shown in the RHEx Full Stack Architecture Diagram above. The security layer consists of [|OpenID Connect], which is used for user authentication, and [|OAuth 2.0], which is used to grant third-party access to web resources without sharing passwords.

Phase 1 of RHEx establishes a single approach to authenticating and sharing identity information between people and software services. Phase 2 of RHEx focuses on content, the payload that will be exchanged between services, and providing structure to the services that will be conducted in this security context. =Phase I: RHEx Security Approach=

OAuth 2.0
OAuth 2.0 is a security protocol that enables users to grant third-party access to their web resources without sharing their passwords. It is a widely-used standard by companies such as Google, Facebook and E*TRADE. The current Internet Engineering Task Force (IETF) draft standard is The OAuth 2.0 Authorization Protocol, draft-ietf-oauth-v2-25, 08 March 2012. [1] This version of the specification replaces and obsoletes the OAuth 1.0 protocol documented in RFC 5849. Lessons learned in developing RHEx profiles will be sent to the working group as feedback.

Click to view the RHEx OAuth 2.0 Draft Profile. Additional information on how to provide feedback to the Profile can be found on the Community Feedback tab.

OpenID Connect
OpenID Connect is a suite of lightweight specifications that provide a framework for identity interactions via RESTful application programming interfaces (APIs). The simplest deployment of OpenID Connect allows for clients of all types to request and receive information about identities and currently authenticated sessions. OpenID Connect is built on top of OAuth 2.0. RHEx will be profiling OpenID Connect to carry identity information relevant to the healthcare domain. An example of this would be passing the clinical role of a person attempting to access a piece of information.

Click to view the RHEx OpenID Connect Draft Profile. Additional information on how to provide feedback to the Profile can be found on the Community Feedback tab.

Source Code
The RHEx source code has been open source from the start and is hosted on GitHub. Access may be granted to contributors based on the merit of previous contributions. Code submissions can be made via pull requests.

The tools provided here will allow for exchange of information using the interfaces specified in the RHEx profile. We encourage users to test these tools with other implementations to ensure that software developed by the RHEx project can truly support interoperability.

To access RHEx source code on GitHub, click [|here]. =Phase II: Content Approach = The RHEx Content Approach uses RESTful principles to create a framework for linking to necessary health information. In this manner, the data can stay resident at its source rather than creating copies for transport. This approach leverages existing data standards and provides a structured means by which the information can be discovered and accessed at various levels of granularity. It also provides a means for on-going discoverability of changed content.

The Content Layer includes not only the payload structure, but also a means for discovering, organizing and traversing the content.

The organization of the content is accomplished via an XML document that describes the content available, and the URIs associated with the resources. The abstract model in the figure below represents this as the “profile organizer.”

The flexibility of the RHEx approach enables administrative and clinical, structured and unstructured information to be accessible in an organized fashion. The content follows a structure similar to a file directory. For example, each grouping of information, such as DICOM images, could be in a single “folder”. Likewise, data that conforms to the Clinical Document Architecture(CDA) could be in a separate “folder” with “sub-folders” containing each section.

Abstract Content Model Diagram
Each resource, or individual unit of data, is accessible by a unique Uniform Resource Identifier (URI). This URI can link to data as a complete, coarse document, such as a DICOM Image, a PDF file, an Extended Markup Language (XML) document, etc. Alternatively, it can link to more granular content item such as a specific allergy or medication entry.

Granular Philosophy
RHEx’s implementation of RESTful architecture enables any published link to a content item to be available via a web-client. Resources can be expressed at any level of granularity that is appropriate for a given implementation, based on its standards alignment, privacy rules or other constraints. For instance, a resource pointing to a document that contains a single item, such as a Continuity of Care Document (CCD) or Blue Button document, PDF, or DICOM image, would be exposed by a link similar to the Coarse Grained Link Example below.

Coarse Grained Link Example
More granular pieces of information such as a procedure list or even a specific procedure can also be the content item referenced by the resource link, as depicted in the Granular Content Item Link Example, shown below. This diagram shows an example of how a link may allow access to information on a specific allergy for a patient. The section document XML represents the content item. Moving up the path represents the section feeds, patient record and root location.

Additional Information
For more information on the RHEx Content Approach, please click on the following links:
 * RESTful Design and Organization of Content
 * RHEx Data Content Standards Alignment

1] [|OAuth 2.0 Authorization Protocol], draft-ietf-oauth-v2-25, 08 March 2012.

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