1. TATRC and MITRE to NwHIN Power Team 12 June 2013 RESTful Health Exchange (RHEx)

2. | 2 || 2 | Outline  Overview of RHEx  FY12 Pilots  FY12 Pilot Outcomes  Additional Pilots with TATRC  FY13 Focus: Sharing Medical Images  Technical Deep Dive: OAuth and OpenID Connect  Summary RESTful Health Exchange (RHEx)

3. | 3 || 3 | Overview What is RESTful Health Exchange (RHEx)?  Open source, exploratory project to apply Web technologies to demonstrate a simple, secure, standards- based health information exchange –Builds the foundation for patient access to data via the Web and mobile devices, removing barriers to broad electronic health data exchange –Offers a new approach to health data exchange –From moving documents to linking to needed information  Sponsored by the ONC Federal Health Architecture (FHA) program in FY12 –Helps address NwHIN Power Team Sept 2011 recommendation to develop a specification for RESTful exchange of health data –Informs a path forward for a RESTful health data exchange RESTful Health Exchange (RHEx) RHEx technology enables secure, Web-based health data exchange http://wiki.siframework.org/RHEx

4. | 4 || 4 | Two RHEx Pilots in FY12 RESTful Health Exchange (RHEx)

5. | 5 || 5 | FY12 Pilot Outcomes  Pilots successfully demonstrated that: –Physicians can securely share health data over the Web –High volumes of data can be moved over the Web securely in support of HIE patient data integration  New pilots with TATRC are underway in FY13  RHEx is being implemented across Maine to support small, independent providers and FQHCs in medically underserved areas  RHEx for secure mobile access was demonstrated at 2013 HIMSS Interoperability Showcase –Patients can be empowered by gaining access to their comprehensive health history in the Maine Health Information Exchange (HIE) using mobile devices powered by hReaderhReader  Pilot with VHA soon to be underway –RHEx technology will support secure sharing of information between VHA and third party providers in support of Veterans in rural Utah RESTful Health Exchange (RHEx) FQHC = Federally Qualified Health Center

6. | 6 || 6 | Additional Pilots with TATRC Apply RHEx technology for…  Sharing images between AHLTA and third party provider systems  Providing patients access to their medical history in AHLTA using a mobile platform (hReader)  Securely migrating health data from AHLTA to VistA to explore methods to reduce risk for a seamless electronic health record for Service Members and Veterans RESTful Health Exchange (RHEx)

7. | 7 || 7 | FY13 Focus: Sharing Medical Images MHS = Military Health System PCM = Primary Care Manager RESTful Health Exchange (RHEx) MHS and third party providers can access relevant diagnostic images and associated records and metadata when needed securely over the Web URL1 is a link to the radiology order. URL2 is a link to the radiology results.

8. | 8 || 8 | © 2013 The MITRE Corporation. All rights reserved. For internal MITRE use Comparison: Focus Build a working prototype and field it on real systems. Proof of concept by adapting existing technologies (hData, OpenID Connect, OAuth). Define a set of resources to represent health and healthcare administration related information and the protocols to go with them. Translatable to/from hData. Enable patients access to their own data in human-readable and machine-readable formats and share them where they choose. Uses FHIR for data layer.

9. | 9 || 9 | © 2013 The MITRE Corporation. All rights reserved. For internal MITRE use Comparison: Network Style Known providers and endpoints, unknown applications, registration and onboarding is out of band. No discovery or dynamic registration. Undefined / out of scope. Highly dynamic and distributed. Trust networks tied to “Registry” components, providers and clients can be outside of any registry and still may function.

10. | 10 | © 2013 The MITRE Corporation. All rights reserved. For internal MITRE use Comparison: Security Transport: HTTPS Authentication: OpenID Connect Authorization: OAuth 2 Defines profiles for protocol use. Transport: HTTPS Authentication: Undefined (local to provider) Authorization: Suggested OAuth 2 Defines security labels for data. Transport: HTTPS Authentication: Undefined (local to provider) Authorization: OAuth 2 Defines profiles and policies for protocol use.

11. | 11 | © 2013 The MITRE Corporation. All rights reserved. For internal MITRE use Comparison: Technology = + + + … = = +

12. Technical Deep Dive: OAuth Delegated Authorization

13. | 13 | Ever seen these? 13

14. Then you’ve used OAuth!

15. | 15 |  Authorization protocol framework  Built on deployment experience with OAuth 1, SAML, OpenID, and others  IETF Standard (as of 10/2012) –RFC6749, RFC6750  Built for HTTP APIs  Mobile friendly  REST-friendly –Not RESTful itself 15 OAuth 2

16. | 16 | Key components of OAuth2 Resource Owner (Controls stuff) Client (Wants stuff) Protected Resource (Has stuff) User Agent (Web browser) Access Token (Lets client get stuff) Refresh Token (Lets client ask for access tokens without bugging the user again) Authorization Server (Issues tokens) 16

17. How do we connect them? 17

18. | 18 |  Authorization Code –Very secure –Most common –Good for web server and native apps  Implicit –Good for apps inside the browser  Client Credentials –When there’s no user involved  Resource Owner Credentials –Bootstrap username/password systems 18 Primary OAuth2 flows

19. | 19 |  Refresh token –Get more access tokens without bothering the user  Assertion –Extension –Uses structured tokens: JWT, SAML  Chain/redelegation –Extension –Trade one access token for another 19 Additional flows

20. The Authorization Code Flow The most common OAuth2 Pattern

21. | 21 | 21 The players Resource Owner & User Agent Authorization Server Protected Resource Client

22. | 22 | 22 The goal: UA AS PR C

23. | 23 | 23 End-user initiates Client action UA AS PR C

24. | 24 | 24 Client redirects User to AS UA AS PR C

25. | 25 | 25 User authenticates to AS UA AS PR C

26. | 26 | 26 User authorizes Client UA AS PR C

27. | 27 | 27 AS issues Authorization Code UA AS PR C

28. | 28 | 28 AS redirects User to Client UA AS PR C

29. | 29 | 29 Client sends code to AS UA AS PR C

30. | 30 | 30 AS issues token(s) UA AS PR C

31. | 31 | 31 AS issues token(s) UA AS PR C

32. | 32 | 32 Client accesses PR UA AS PR C

33. | 33 |  Avoiding password proliferation –User’s credentials never go to the client  API protection –Hundreds of thousands of sites, projects, and systems … and growing  Mobile access to server systems  Authentication (sign-on) protocols –Facebook Connect, Log In With Twitter, etc. 33 What is OAuth used for?

34. So, OAuth is a sign-on protocol?

35. No, it isn’t.

36. So, OAuth is a sign-on protocol? REALLY No, it REALLY isn’t.

37. | 37 | 37 A delicious metaphor Metaphor from: http://blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx ChocolateFudge

38. | 38 |  Delicious on its own  Versatile ingredient –Useful in many circumstances  Can be used to make fudge 38 OAuth is Chocolate

39. | 39 |  A confection with several ingredients  Can be made with chocolate –But needs more than just chocolate –Could be made without chocolate 39 Sign-on is Fudge

40. | 40 |  Create an identity API, protect it with OAuth –Authorization Server becomes Identity Provider –Client becomes Relying Party  Standardized user profiles –Name, email, picture, etc.  Session management –Is the user still logged in? –Log out  Step up to high levels of authentication  Keep compatibility with basic OAuth2 40 A recipe for sign-on with OAuth2

41. Great idea!

42. Why hasn’t anyone done that?

43. They are! Distributed identity at internet scale

44. | 44 |  OpenID Connect (OIDC) is built on experience with OpenID 2, OAuth, SAML, Facebook Connect, etc.  Developed by the OpenID Foundation –http://openid.net/connect 44 New generation identity protocol

45. | 45 |  OAuth 2 authorization –Authorization Server becomes Identity Provider –Client becomes Relying Party  JSON Web Tokens –Structured token format  Can work in fully-distributed mode –Dynamic discovery and registration –Self-issued identities  “Make the simple things simple, make the difficult things possible.” 45 Start with a solid base

46. | 46 |  Use OAuth2 to get a regular access token, as well as an ID token  Use access token to call User Info Endpoint –Standardized user profile –Standardized scopes  Parse and use ID token to manage current session and user information 46 How it works

47. | 47 |  Higher levels of assurance –Signed and encrypted requests –Signed and encrypted responses  Fine-grained claims management  Distributed and aggregated claims  Self-issued identities  IdP-initiated login –Kicks off the standard flow “remotely”  Can get very complex if you want it to –“SAML with curly braces” 47 What else it can do

48. | 48 |  OAuth 2 in the wild  Real-life interoperability testing  Real deployments, large and small  Generalization of protocols –OIDC Discovery -> Webfinger –OIDC Registration -> OAuth 2 Dynamic Client Registration –JWT Claims  Subject, audience, authorized presenter 48 A protocol proving ground

49. | 49 | Summary  RHEx project has explored secure, Web-based health data exchange, building the foundation for future advances in health care –Allows providers and patients to exchange health data securely over the World Wide Web –Builds foundation for secure access via mobile devices  Pilots with TATRC and HealthInfoNet suggest that RHEx technology is a feasible solution for lightweight, secure exchange of health data over the Web  Work continues to pilot RHEx technology in new ways RESTful Health Exchange (RHEx) RHEx is informing a path forward for the future of health data exchange http://www.mitre.org/work/health/himss/rhex.pdf

50. | 50 | BACKUP CHARTS RESTful Health Exchange (RHEx)

51. | 51 | What is REST?  Stands for “Representational State Transfer” –Coined by Roy Fielding, a principal author of HTTP  Lightweight architectural style for Web development that offers simplicity  Web resources represented by universal resource locator (URL) and accessible by HTTP methods Source: http://martinfowler.com/articles/richardsonMaturityModel.htmlhttp://martinfowler.com/articles/richardsonMaturityModel.html RESTful Health Exchange (RHEx)

52. | 52 | FY12 Pilots  Pilot with TATRC –Goal: Demonstrate simple, secure RESTful health data exchange over Web –Use Case: Consults/Referral sharing –Pilot demonstrated that physicians can securely share health data over the Web  Pilot with Maine HIE (HealthInfoNet) –Goal: Investigate use of RESTful approach to populate Maine HIE Clinical Data Repository –Use Case: Population of single electronic health record for patients in medically underserved areas –Pilot demonstrated that high volumes of data can be moved over the Web securely in support of HIE integration RESTful Health Exchange (RHEx)

53. | 53 | FY12 RHEx Pilot with TATRC: Improving the Consultation/Referral Process PCP = Primary Care Physician PCP and Consulting Physician can access and retrieve current, relevant portions of each other’s records when they need them URL-1 = Consult Requests Details URL URL-2 = Consult Results Details URL RESTful Health Exchange (RHEx)

54. | 54 | RHEx Pilot with TATRC Technical Approach RESTful Health Exchange (RHEx) NwHIN Direct

55. | 55 | RHEx Pilot with HealthInfoNet  Demonstrate secure, RESTful health data exchange from a Federally Qualified Health Center (FQHC) to Maine HIE using RHEx 55 Islands Community Medical Services RESTful Health Exchange (RHEx)

56. | 56 | RHEx Pilot with HealthInfoNet Technical Approach © 2013 The MITRE Corporation. All rights reserved. For internal MITRE use RESTful Health Exchange (RHEx)

57. | 57 | HIE = Health Information Exchange. HIMSS is the Healthcare Information and Management Systems Society. Demonstration at HIMSS: RESTful Health Exchange with HIEs for Patient Engagement By securely accessing their health history, patients actively engage and participate directly in their own care RESTful Health Exchange (RHEx)

58. These diagrams illustrate the use of OpenID Connect and OAuth2 working in tandem to allow a client to access a protected resource. In this scenario, the Identity Provider (IdP), Authorization Server (AS), and Client are all in separate security domains. The Resource Server (RS) is in the same security domain as the AS to the extent that the RS can validate and trust a token generated by the AS. The user must log in to the AS using credentials from their IdP, then authorize the client to access the RS for them. The AS is therefore a client of the IdP in addition to being an AS in its own right (for the RS). These diagrams do not show discovery or registration. OpenID Connect and OAuth2: a distributed trust scenario a distributed trust scenario ©2012 The MITRE Corporation Justin Richer, The MITRE Corporation

59. | 59 | Identity ProviderAuthorization Server Resource Server Client User Front Channel Back Channel Out of Band The user connects using a user agent at the client application which needs to access data at the resource server. Assumed: The client is registered and trusted at the AS and the AS is registered and trusted at the IdP.

60. | 60 | IdPAS RS Client User Front Channel Back Channel Out of Band Service URL Client gets the service URL (out of band – configuration, through user)

61. | 61 | IdPAS RS Client User Front Channel Back Channel Out of Band GET Client fetches the service URL directly to access the data

62. | 62 | IdPAS RS Client User Front Channel Back Channel Out of Band 401 Server sends back not authorized response, client must get authorization from user via OAuth

63. | 63 | IdPAS RS Client User Front Channel Back Channel Out of Band Authorization Request Client directs user to auth server 302

64. | 64 | IdPAS RS Client User Front Channel Back Channel Out of Band Authorization Request Auth server redirects user to their IdP 302

65. | 65 | IdPAS RS Client User Front Channel Back Channel Out of Band Authentication & Authorization User authenticates to IdP and authorizes auth server for login

66. | 66 | IdPAS RS Client User Front Channel Back Channel Out of Band Authorization Code Response IdP directs user back to auth server with auth code 302

67. | 67 | IdPAS RS Client User Front Channel Back Channel Out of Band Authorization Code Auth server trades auth code for tokens

68. | 68 | IdPAS RS Client User Front Channel Back Channel Out of Band Access Token ID Token Auth server trades auth code for tokens

69. | 69 | IdPAS RS Client User Front Channel Back Channel Out of Band Access Token Auth server trades access token for claims about the user

70. | 70 | IdPAS RS Client User Front Channel Back Channel Out of Band UserInfo (Claims about user) Auth server trades access token for claims about the user

71. | 71 | IdPAS RS Client User Front Channel Back Channel Out of Band User Authorizes Client at AS User is now authenticated at auth server, authorizes client to access resource server

72. | 72 | IdPAS RS Client User Front Channel Back Channel Out of Band Authorization Code Auth server redirects user back to client with auth code 302

73. | 73 | IdPAS RS Client User Front Channel Back Channel Out of Band Authorization Code Client trades auth code for access token

74. | 74 | IdPAS RS Client User Front Channel Back Channel Out of Band Access Token Client trades auth code for access token

75. | 75 | IdPAS RS Client User Front Channel Back Channel Out of Band Access Token Client presents access token to resource server

76. | 76 | IdPAS RS Client User Front Channel Back Channel Out of Band Resource server validates token with the authorization server (out of band: could be UMA, token introspection, or structured tokens)

77. | 77 | IdPAS RS Client User Front Channel Back Channel Out of Band Data Resource server returns requested data to client, which can now process it, display it, etc.