RESTful Health Exchange (RHEx) Overview T o NwHIN Power Team July 26, 2012

1. RESTful Health Exchange (RHEx)OverviewTo NwHIN Power TeamJuly 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

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.” FarzadMostashari, HIT Standards Committee, September 28, 2011 Meeting

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

5. RHExOverviewPiloting 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 RESTfulsecurity • 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

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

7. RHExFY12PilotsTesting 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

8. RHExProject OutcomesAnticipated 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 • RESTfulhealth 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

9. RHExSecurity Approach ProfilesSeeking 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 RHExWebExs • 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 calendaror RHEx Wiki • Join the RHEx Google Groupconversation • Also accessible through the RHEx wiki • RHEx project will document feedback and incorporate comments, as appropriate wiki.siframework.org/RHEx

10. HITSC Standards Readiness Test CasePreliminary 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

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 National Standards • Maturity Criteria: • Maturity of Specification • Maturity of Underlying Technology Components • Market Adoption Low Moderate High Maturity Pilots • Adoptability Criteria: • Ease of Implementation and Deployment • Ease of Operations • Intellectual Property Emerging Standards Low Moderate High Adoptability Source: Dixie Baker, Preliminary Recommendations for Standards Evaluations Criteria”, Briefing to HIT Standards Committee, July 19, 2012

12. Standards Evaluation Criteria Preliminary TestNotes • 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

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

14. Back-up Charts

15. Tentative RHEx WebEx Schedule

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

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

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

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

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

21. Standards Evaluation Criteria Preliminary TestMaturity Criteria Preliminary assessment for criteria test case; Not all criteria able to be assessed

22. Standards Evaluation Criteria Preliminary TestAdoptability Criteria Preliminary assessment for criteria test case; Not all criteria able to be assessed