Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

RHEx NwHIN Power Team 2012-07-26


Published on

Published in: Technology
  • Be the first to comment

RHEx NwHIN Power Team 2012-07-26

  1. 1. RESTful Health Exchange (RHEx)OverviewTo NwHIN Power TeamJuly 26, 2012 DRAFT—for discussion purposes only
  2. 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. 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. 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. 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. 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. 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. 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 profilesInput to inform a path forward on a world wide web and mobile friendly way to exchange health data 8
  9. 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 9
  10. 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 criteriaCriteria test case only – Not a vetted assessment 10
  11. 11. Context: Evaluation of Readiness of TechnicalSpecifications to Become National StandardsPreliminary placement for criteria test case; Not all criteria able to be assessed High NationalMaturity Criteria: Standards• Maturity of Specification• Maturity of Underlying Technology Maturity Components Moderate• Market Adoption PilotsAdoptability 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. 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. 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. 14. BACK-UP CHARTS 14
  15. 15. Tentative RHEx WebEx ScheduleDate Topic SpeakerJune 28 Overview/Kick-Off Mary PulvermacherJuly 12 Charter Discussion Rick CagleJuly 26 RHEx Security Approach Justin RicherAugust 9 Phase I Profile Rob Dingwell and Andy Discussion GregorowiczAugust 23 RHEx Content Approach Anne KlingAugust 30 Phase II Profile Andy Gregorowicz DiscussionSeptember 6 RHEx Test Framework Jason MatthewsSeptember 20 Lessons Learned from Suzette Stoutenburg RHEx PilotsSeptember 27 Wrap-up and Next Steps Mary Pulvermacher 15
  16. 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. 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. 18. OpenID Connect Family Tree OpenID Connect Family Tree OpenID 1.0 OAuth 1.0/aXRDS OpenID 2.0 Hybrid WS* ID-WSF WRAPXRD AB AX PAPE SAML OAuth 2 FacebookSWD Connect JWT/JOSE OpenID Connect 18
  19. 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. 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. 21. Standards Evaluation Criteria Preliminary Test Maturity Criteria Criteria OAuth2 OpenID ConnectMaturity of the SpecificationBreadth of Support H M-HStability M-H LDegree of interoperability among independent non-coordinated ? MimplementationsAdoption of Specification H MMaturity of Underlying Technology ComponentsBreadth of Support H MStability H M-HDegree of interoperability among independent non-coordinated H MimplementationsAdoption of Technology H M-HPlatform Support H M-HMaturity of the technology within its life cycle H ?Market AdoptionInstalled health care user base ? LInstalled user base outside of health care H LFuture projections and anticipated support M-H M-HInvestments in user training ? ? Preliminary assessment for criteria test case; Not all criteria able to be assessed 21
  22. 22. Standards Evaluation Criteria Preliminary Test Adoptability Criteria Criteria OAuth2 OpenID ConnectEase of Implementation and DeploymentAvailability of off-the-shelf infrastructure to support implementation H L-HDeployment Complexity ? ?Conformance Criteria and Tests L LAvailability of Reference Implementations H ?Complexity of Specification ? ?Quality and Clarity of Specifications H M-HSpecification Modularity ? ?Separation of Concerns H HEase of use of specification H HDegree to which specification uses familiar terms to describe “real-world” concepts H HRuntime Coupling H HDegree 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 needed H HOperational scalability (i.e., operational impact of adding a single node) H HFit to Purpose ? ?Intellectual PropertyOpenness H HAccessibility and Fees H HLicensing Policy H HCopyrights H HPatents H H Preliminary assessment for criteria test case; Not all criteria able to be assessed 22