RHEx+FAQ

include component="page" wikiName="siframework" page="RHEx HeaderHome" flat = = To view the FAQ in document form, click the icon: =Learning About the RHEx Project= For more information on the RHEx project please visit our Wiki page and sign up to join our [|Google Group]. For a quick reference to content on our Wiki, select from the following topic areas: =General RHEx Project Questions=
 * Home
 * Charter
 * RHEx Approach
 * Community Feedback
 * Materials
 * Pilots
 * NwHIN Harmonization

What is RHEx trying to achieve?
RHEx is seeking to develop an implementation of a RESTful health data exchange that can inform ONC, Federal Partners and the broader health IT community’s ability to answer: The answers to these questions will be informed by an actual implementation, and strong community participation. RHEx will be transparent in sharing project details, and will continually seek community feedback and input. By the end of FY12, the RHEx project will deliver:
 * Does the theory work in practice?
 * What parts of the exchange have strong community consensus?
 * Where is there controversy or lack of strong industry direction?
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">Draft standards profiles for relevant standards
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">OpenID Connect Profile
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">Constraints to limit choices/optionality
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">Extensions to convey healthcare specific identity information
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">OAuth 2 Profile
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">Constraints to limit choices/optionality
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">Extensions to enhance security
 * Content Profile
 * Granular format for health data
 * Reference Implementation
 * Open source code that can be used to implement a system that adheres to the RHEx standards profile
 * Test client: Open source software package for an independent tool that can validate conformance of a service to RHEx profile of existing specifications

<span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">For more information on key components of the RHEx project (i.e. scope, value statement, timeline, etc.) please see the project’s charter.

Is RHEx an S&I Initiative?
<span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">RHEx is not an S&I Initiative. It is an affiliated project hosted on the S&I Framework wiki. The FY12 RHEx project is sponsored by the Federal Health Architecture (FHA) program and is an exploratory, open source project. RHEx is examining how a RESTful approach might be applied to meet identified health information technology (IT) needs, and will share results with the health IT community.

If this is not an S&I Initiative, how should the S&I community engage the project?
<span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">In order to deliver a well informed and validated approach, it is crucial that RHEx receives feedback and input from the S&I community. Our project is designed to inform a path forward – identifying where strong community agreement exists, and where concerns or a lack of strong industry direction exist for a RESTful approach. We need the expertise and dedication of the S&I community to help us forge this path forward. <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">S&I community members can contribute to the RHEx project by: =Related Efforts Questions=
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">Providing feedback to discussions on protocols, profiles, and RHEx’s general approach on [|Google Groups].
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">Participating in our bi-weekly WebEx meetings
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">Viewing or contributing to RHEx source code on[|GitHub].

How is RHEx interacting with other projects in the NwHIN portfolio?
<span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">RHEx has put considerable thought into how our approach harmonizes with other NwHIN portfolio projects. <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">A RHEx approach can be used with Direct: <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">A RHEx adapter could be developed to interface with an Exchange Gateway:
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">Direct messages may be used to securely send RHEx web links among trusted partners.
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">RHEx is like a RESTful sidecar on a Direct message motorcycle. Once delivered, the RESTful links may be used to securely access web content.
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">RHEx employs the same user identity as Direct.
 * <span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">The adapter would translate RHEx requests/responses into Exchange requests/responses. The detailed definition of this adapter is out of scope for the RHEx project.

What is the relationship between RHEx and UMA?
<span style="font-family: Arial,Helvetica,sans-serif; font-size: 110%;">RHEx project team members are active member of the User Managed Access (UMA) Working Group, and has explicitly designed the RHEx architecture to accommodate UMA-style Authorization Manager decisions to be added at a future date. As RHEx design and reference implementation work progresses, we aim to leave as much flexibility and choice for decisions such as consent management implementation as possible. This should leave ample option for UMA to supply that capability at a future point. =RHEx Security Approach Questions=

Will RHEx attempt to implement consent in its pilots, profiles, and reference implementations?
No: RHEx is anexploratory effortfor Fiscal Year 2012, with a Phase 1 (Security) and Phase 2 (Content) scope. As such, consent or permissions management is out of scope for the FY12 RHEx project. Since the beginning, our architecture plan has included a separable connection to an Authorization Service. This is currently realized as a statically-configured connection, which was the simplest approach to serve as a placeholder for subsequent provisioning. Because of the considerable thought put into these architectural choices, UMA, or similar Asset Management (AM )capabilities will be easy to incorporate at a later time, but are decoupled from what we plan to do for our current scope.

Is RHEx using other protocols like LDAP and DNS?
No: RHEx is focusing on leveraging OpenID and OAuth2 on providing a safe and secure exchange of health information. Lightweight Direct Access Protocol (LDAP) and Domain Name System (DNS) certificates are not as web friendly as JSON Web Key (JWK) to advertise certificates that are HTTP accessible. DNS is used in its traditional role – translating hostnames into IP addresses.

How would provider-to-provider exchange occur when the patient is not directly involved?
The concept of ‘ownership’ does not translate to ‘information’. No one can ‘own’ data; ownership is a concept unique to physical things. The concept of copyright is a closer analogy for health-information. Dual ‘copyright’ is possible, and a well understood concept in legal terms.

OAuth is a delegation mechanism, meaning that it Authorizes Service-A to impersonate the user when accessing Service-B. So it is not the same concept as a Privacy Consent or Privacy Authorization. Thus, the privacy of the data is an independent control that is managed, often implemented as a consent-service.

What security protocols can be employed internally with a RHEx approach?
If you consider the RHEx architecture, the security layer employs the OpenID Connect protocol. This "suite" of lightweight specifications provides a framework for identity interactions via RESTful APIs. Wherever a RESTful approach is employed, the same protocols over the same APIs should be implemented for internal requestors of patient information (e.g., Quality Control or other departments within a hospital) as for external parties (such as insurers, consulting physicians, emergency rooms, rehab, etc.) OAuth is a relatively lightweight protocol that allows us to pass around tokens instead of policy documents between endpoints. These tokens can be resolved locally by the protected resource to decide on permissions (what we're doing right now with our RHEx approach), or they may be used as an artifact to resolve a larger policy set (in a system like UMA). Note that this is not dissimilar to a SAML artifact binding or XACML protocols in some respects, but the burden of complexity is moved off of the clients and protected resources and into the authorization service, where it arguably belongs. Most importantly, the way that we have architected RHEx, the system can easily be augmented with advanced authorization functionality in the future so long as it is OAuth compatible. This is precisely why we have kept UMA very squarely in our radar for this aspect at a later date.