1. RESTful Health Exchange (RHEx)OverviewTo NwHIN Power TeamJuly 26, 2012 wiki.siframework.org/RHExDRAFTfor 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 webtechnologies to demonstrate a simple, secure, andstandards-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 cant wait 5 years for transport standards. We cant 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 partys implementation conforms to RHEx standards profiles 4 5. RHEx OverviewPiloting 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 exchange5 6. RHEx Security and Privacy Safeguarding Access to Health Information Secure communications over TLS/SSL (https) Use proven, open standards for identity andauthentication OpenID Connect for distributed identity management and user authentication OAuth2 for service-to-service authentication Provide information needed for authorizationdetermination 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 PilotsTesting that Theory Works in Practice Initial pilot: Phase 1 & Phase 2 Goal: Demonstrate simple, secure RESTful exchange intwo 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 pilot7 8. RHEx Project 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 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 profilesInput to inform a path forward on a world wide web and mobilefriendly way to exchange health data8 9. RHEx Security Approach ProfilesSeeking Community Feedback Draft profiles for OAuth 2 and OpenIDConnect 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 andincorporate comments, as appropriatewiki.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 oftwo RHEx security approach standards OAuth2 OpenID Connect Intended to provide feedback to Power Teamon preliminary recommendations forstandards evaluation criteriaCriteria test case only Not a vetted assessment10 11. Context: Evaluation of Readiness of TechnicalSpecifications to Become National StandardsPreliminary placement for criteria test case; Not all criteria able to be assessed HighNationalMaturity Criteria:Standards Maturity of Specification Maturity of Underlying TechnologyMaturityComponents Moderate Market Adoption PilotsAdoptability Criteria: Ease of Implementation and Deployment Ease of OperationsEmerging Standards Intellectual Property LowLowModerate High AdoptabilitySource: Dixie Baker, Preliminary Recommendations for Standards EvaluationsCriteria, Briefing to HIT Standards Committee, July 19, 2012 11 12. Standards Evaluation Criteria Preliminary TestNotes Not a vetted assessment Cursory pass through evaluation criteria HTTP -- Underlying technology of OAuth2 and OpenIdConnect 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 elements12 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 testframework Powering Secure, Web-Based Health Data Exchange 13 14. BACK-UP CHARTS 14 15. Tentative RHEx WebEx ScheduleDate TopicSpeakerJune 28Overview/Kick-OffMary PulvermacherJuly 12Charter Discussion Rick CagleJuly 26RHEx Security Approach Justin RicherAugust 9 Phase I ProfileRob Dingwell and Andy Discussion GregorowiczAugust 23RHEx Content ApproachAnne KlingAugust 30Phase II Profile Andy Gregorowicz DiscussionSeptember 6RHEx Test FrameworkJason MatthewsSeptember 20 Lessons Learned from Suzette Stoutenburg RHEx PilotsSeptember 27 Wrap-up and Next Steps Mary Pulvermacher15 16. Core Technical Principles Internet Scale Access Management Standards such as OAuth and OpenID have demonstratedstrong, scalable security at low cost Granular and Addressable Data Breaking healthcare information into small piecesaccessible 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 toview 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.0OAuth 1.0/aXRDS OpenID 2.0HybridWS*ID-WSFWRAPXRDABAXPAPESAMLOAuth 2 FacebookSWD Connect JWT/JOSE OpenID Connect 18 19. OAuth An open protocol to allow secure API authorization ina simple and standard method from desktop and webapplications An Internet Engineering Task Force (IETF) standard19 20. OpenID is an open web standard that allowsusers 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 OAuth220 21. Standards Evaluation Criteria Preliminary TestMaturity CriteriaCriteria OAuth2OpenID ConnectMaturity of the SpecificationBreadth of SupportHM-HStabilityM-HLDegree of interoperability among independent non-coordinated? MimplementationsAdoption of Specification H MMaturity of Underlying Technology ComponentsBreadth of SupportH MStability HM-HDegree of interoperability among independent non-coordinatedH MimplementationsAdoption of TechnologyHM-HPlatform SupportHM-HMaturity of the technology within its life cycleH ?Market AdoptionInstalled health care user base ? LInstalled user base outside of health careH LFuture projections and anticipated support M-H M-HInvestments in user training? ? Preliminary assessment for criteria test case; Not all criteria able to be assessed21 22. Standards Evaluation Criteria Preliminary TestAdoptability CriteriaCriteriaOAuth2 OpenID ConnectEase of Implementation and DeploymentAvailability of off-the-shelf infrastructure to support implementationH L-HDeployment Complexity ??Conformance Criteria and TestsLLAvailability of Reference Implementations H?Complexity of Specification ??Quality and Clarity of Specifications H M-HSpecification Modularity??Separation of ConcernsHHEase of use of specificationHHDegree to which specification uses familiar terms to describe real-world concepts HHRuntime CouplingHHDegree of Optionality ??Ease of OperationsComparison of targeted scale of deployment to actual scale deployed ??Number of operational issued identified in deployment ??Degree of peer-coordination neededHHOperational scalability (i.e., operational impact of adding a single node)HHFit to Purpose??Intellectual PropertyOpennessHHAccessibility and FeesHHLicensing PolicyHHCopyrightsHHPatents HHPreliminary assessment for criteria test case; Not all criteria able to be assessed 22