1. RESTful Health Exchange (RHEx)
Overview
To NwHIN Power Team
July 26, 2012
wiki.siframework.org/RHEx
DRAFT—for discussion purposes only

2. Outline
• RESTful Health Exchange (RHEx)
– Overview
– Security and Privacy
– Fiscal Year 2012 (FY12) Pilots
– Project Outcomes
– Security Approach Standards Profiles
• HITSC Standards Readiness Test Case
• Next Steps
2

3. RHEx Overview
RESTful Health Exchange (RHEx)
• An open source, exploratory project to apply proven web
technologies to demonstrate a simple, secure, and
standards-based health information exchange
– Sponsored by the Federal Health Architecture (FHA)
program
– A Fiscal Year 2012 project being demonstrated in 2 phases
• Phase 1: Security approach (April – July 2012)
• Phase 2: Content approach (July – September 2012)
• A Federal Partners’ response to an identified need
– Addresses NwHIN Power Team recommendation to
develop a specification for RESTful exchange of health
data (28 Sept 2011)
– Continues the tradition of Federal Partner investment in
driving innovative solutions
– Intended to inform a path forward on a RESTful health
exchange
“ We can’t wait 5 years for transport standards. We can’t afford it.”
Farzad Mostashari, HIT Standards Committee, September 28, 2011 Meeting
3

4. RHEx Overview
RHEx Approach
• Apply existing standards
– Refine existing standards to fit into the Nationwide Health
Information Network (NwHIN) portfolio
– Start with http
– Layer on proven, open standards for identity management
as well as user and service authentication
• Use pilots to test that theory works in practice
– Work to reduce ambiguity or oversights in the standards
being refined by the project
– Extend standards where best serves the health community
• Implement a conformance testing framework
– Provide tools and documentation to test that an
independent party’s implementation conforms to RHEx
standards profiles
4

5. RHEx Overview
Piloting RHEx in Two Phases in FY12
• Phase 1: Security Approach (April - July 2012)
– Focus on securing web interactions
– Use web/mobile friendly methods of exchanging identity
information and authorizing users via HTTPS
– Seek community input on satisfactory and complete
RESTful security
• Phase 2: Content Approach (July - September 2012)
– Expand pilot to show full benefit of a RESTful
interaction and incorporate the content layer
– Seek community input on a structured approach to
granular health data exchange
5

6. RHEx Security and Privacy
Safeguarding Access to Health Information
• Secure communications over TLS/SSL (https)
• Use proven, open standards for identity and
authentication
– OpenID Connect for distributed identity management and
user authentication
– OAuth2 for service-to-service authentication
• Provide information needed for authorization
determination
– Extend standard profile to best serve the health domain
• e.g., add clinical role for use in enforcing access control
– Privacy is enforced at the provider location at the time the
information is requested
– Authorization process is out of scope for RHEx FY12 pilots
6

7. RHEx FY12 Pilots
Testing that Theory Works in Practice
• Initial pilot: Phase 1 & Phase 2
– Goal: Demonstrate simple, secure RESTful exchange in
two phases
– Use Case: Consults/Referral
• Selected via discussions with Federal Partners
– FHA Partner: Steve Steffensen and Ollie Gray, TATRC
• Telemedicine & Advanced Technology Research Group (TATRC),
U.S. Army Medical Research & Materiel Command (MRMC)
– Status: Phase 1 scheduled for completion 31 July
• Second pilot: Phase 2
– Goal: Investigate use of RESTful approach to populate
Maine HIE (HealthInfoNet) Clinical Data Repository
– Use Case: Integrate electronic health records for medically
underserved areas
– FHA Partner: Todd Rogow, HealthInfoNet
– Status: Development on track for 31 August demonstration
• Investigating possible Blue Button related third pilot
7

8. RHEx Project Outcomes
Anticipated FY12 Outcomes
• Community dialog around RESTful approaches
– How to apply the architectural style widely used on the
web today
– Which proven open standards for identity management
and authentication best serve the Health IT Community
• A set of products to inform a path forward
– RESTful health data exchange implementation(s)
• Focusing on refining existing standards
• Using pilots to reduce ambiguity and oversights in these
standards
– Testable, draft profiles for relevant, existing standards
– Independent conformance testing tool to validate
against profiles
Input to inform a path forward on a world wide web and mobile
friendly way to exchange health data
8

9. RHEx Security Approach Profiles
Seeking Community Feedback
• Draft profiles for OAuth 2 and OpenID
Connect will be posted to RHEx wiki in July
• RHEx project seeks community feedback
– Attend the RHEx WebExs
• Thursdays, 11 am – 12 pm EDT (until Sept. 20)
• Security Profile Review is scheduled for Aug. 9
• Previous WebExs can be accessed here
• For details, see S&I calendar or RHEx Wiki
– Join the RHEx Google Group conversation
• Also accessible through the RHEx wiki
• RHEx project will document feedback and
incorporate comments, as appropriate
wiki.siframework.org/RHEx
9

10. HITSC Standards Readiness Test Case
Preliminary Standards Assessment
• Exercised HIT Standards Committee (HITSC)
preliminary standards evaluation criteria
– Version presented to HITSC by NwHIN
Power Team on 19 July 2012
• Performed very preliminary assessment of
two RHEx security approach standards
– OAuth2
– OpenID Connect
• Intended to provide feedback to Power Team
on preliminary recommendations for
standards evaluation criteria
Criteria test case only – Not a vetted assessment
10

11. Context: Evaluation of Readiness of Technical
Specifications to Become National Standards
Preliminary placement for criteria test case; Not all criteria able to be assessed
High
National
Maturity Criteria: Standards
• Maturity of Specification
• Maturity of Underlying Technology
Maturity
Components
Moderate
• Market Adoption
Pilots
Adoptability Criteria:
• Ease of Implementation and Deployment
• Ease of Operations
Emerging Standards
• Intellectual Property
Low
Low Moderate High
Adoptability
Source: Dixie Baker, Preliminary Recommendations for Standards Evaluations
Criteria”, Briefing to HIT Standards Committee, July 19, 2012
11

12. Standards Evaluation Criteria Preliminary Test
Notes
• Not a vetted assessment
– Cursory pass through evaluation criteria
• HTTP -- Underlying technology of OAuth2 and OpenId
Connect
– Highly mature, adoptable and scalable
• OAuth2 – IETF Draft
– High to Moderate maturity and adoptability
• OpenID Connect – Implementers Draft
– Moderate maturity and adoptability
• Preliminary Standards Evaluation Criteria Feedback
– Quite comprehensive
– Additional clarification on some criteria would be beneficial
• Questions around context and meaning of some criteria elements
– Can provide feedback on specific criteria elements
12

13. Next Steps
• Continue to engage the community
– Community feedback on OpenID Connect
and OAuth 2 profiles
– Google Group discussions
– Bi-weekly WebEx meetings
• Continue pilot implementations
• Continue work on conformance test
framework
Powering Secure, Web-Based Health Data Exchange
13

14. BACK-UP CHARTS
14

15. Tentative RHEx WebEx Schedule
Date Topic Speaker
June 28 Overview/Kick-Off Mary Pulvermacher
July 12 Charter Discussion Rick Cagle
July 26 RHEx Security Approach Justin Richer
August 9 Phase I Profile Rob Dingwell and Andy
Discussion Gregorowicz
August 23 RHEx Content Approach Anne Kling
August 30 Phase II Profile Andy Gregorowicz
Discussion
September 6 RHEx Test Framework Jason Matthews
September 20 Lessons Learned from Suzette Stoutenburg
RHEx Pilots
September 27 Wrap-up and Next Steps Mary Pulvermacher
15

16. Core Technical Principles
• Internet Scale Access Management
– Standards such as OAuth and OpenID have demonstrated
strong, scalable security at low cost
• Granular and Addressable Data
– Breaking healthcare information into small pieces
accessible by a URL enables secure, efficient access
• Linking
– When data is addressable, it can be linked on the web,
allowing humans and software to browse the web of links to
view clinical contexts
• Leverage HTTP
– The protocol that drives the web offers a more robust,
flexible and scalable solution
16

17. Why use OpenID Connect and OAuth 2?
• OpenID Connect
– Strong industry participation
– Flexible trust model
– Alternatives
• Browser ID, Shibboleth, CAS
• Low adoption, some are more SSO oriented
• OAuth 2
– Wide industry adoption
– Works well with browser clients
– Alternatives
• Two way TLS/SSL
– Low adoption
– Key distribution and protection problems
• WS-Security
– Does not work well with browsers
17

18. OpenID Connect Family Tree OpenID Connect Family Tree
OpenID 1.0 OAuth 1.0/a
XRDS OpenID 2.0 Hybrid WS*
ID-WSF
WRAP
XRD
AB AX PAPE SAML
OAuth 2
Facebook
SWD Connect
JWT/JOSE
OpenID Connect
18

19. OAuth
• An open protocol to allow secure API authorization in
a simple and standard method from desktop and web
applications
• An Internet Engineering Task Force (IETF) standard
19

20. • OpenID is an open web standard that allows
users to be authenticated in a distributed manner
– For example, this could allow a VA Provider to log
into a DoD system using their VA username and
password
• Provides authentication and identity
– Extensible to include profiles and claims (e.g., the
user clinical role)
• OpenID Connect
– Identity service built on top of OAuth2
20

21. Standards Evaluation Criteria Preliminary Test
Maturity Criteria
Criteria OAuth2 OpenID Connect
Maturity of the Specification
Breadth of Support H M-H
Stability M-H L
Degree of interoperability among independent non-coordinated
? M
implementations
Adoption of Specification H M
Maturity of Underlying Technology Components
Breadth of Support H M
Stability H M-H
Degree of interoperability among independent non-coordinated
H M
implementations
Adoption of Technology H M-H
Platform Support H M-H
Maturity of the technology within its life cycle H ?
Market Adoption
Installed health care user base ? L
Installed user base outside of health care H L
Future projections and anticipated support M-H M-H
Investments in user training ? ?
Preliminary assessment for criteria test case; Not all criteria able to be assessed 21

22. Standards Evaluation Criteria Preliminary Test
Adoptability Criteria
Criteria OAuth2 OpenID Connect
Ease of Implementation and Deployment
Availability of off-the-shelf infrastructure to support implementation H L-H
Deployment Complexity ? ?
Conformance Criteria and Tests L L
Availability of Reference Implementations H ?
Complexity of Specification ? ?
Quality and Clarity of Specifications H M-H
Specification Modularity ? ?
Separation of Concerns H H
Ease of use of specification H H
Degree to which specification uses familiar terms to describe “real-world” concepts H H
Runtime Coupling H H
Degree of Optionality ? ?
Ease of Operations
Comparison of targeted scale of deployment to actual scale deployed ? ?
Number of operational issued identified in deployment ? ?
Degree of peer-coordination needed H H
Operational scalability (i.e., operational impact of adding a single node) H H
Fit to Purpose ? ?
Intellectual Property
Openness H H
Accessibility and Fees H H
Licensing Policy H H
Copyrights H H
Patents H H
Preliminary assessment for criteria test case; Not all criteria able to be assessed 22