Embed Size (px)
Citation preview
TAT R C a n d M I T R E
t o N w H I N P o w e r Te a m
1 2 J u n e 2 0 1 3
RESTful Health Exchange(RHEx)
| 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 |
OverviewWhat 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 |
Two RHEx Pilots in FY12
RESTful Health Exchange (RHEx)
| 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 hReader
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 |
Additional Pilots with TATRCApply 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 |
FY13 Focus: Sharing Medical Images
MHS = Military Health SystemPCM = 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 WebURL1 is a link to the radiology order.URL2 is a link to the radiology results.
| 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 |
© 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 |
© 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 |
© 2013 The MITRE Corporation. All rights reserved. For internal MITRE use
Comparison: Technology
=+
+
+ …=
= +
Technical Deep Dive:OAuthD e l e g a t e d A u t h o r i z a t i o n
| 13 |
Ever seen these?
13
Then you’ve used OAuth!
| 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 |
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
How do we connect them?
17
| 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 |
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
The Authorization Code FlowT h e m o s t c o m m o n O A u t h 2 P a t t e r n
| 21 |
21
The players
Resource Owner &User Agent Authorization Server
Protected ResourceClient
| 22 |
22
The goal:
UAAS
PRC
Connect the Client to the PR
| 23 |
23
End-user initiates Client action
UAAS
PRC
| 24 |
24
Client redirects User to AS
UAAS
PRC
| 25 |
25
User authenticates to AS
UAAS
PRC
| 26 |
26
User authorizes Client
UAAS
PRC
| 27 |
27
AS issues Authorization Code
UAAS
PRC
| 28 |
28
AS redirects User to Client
UAAS
PRC
| 29 |
29
Client sends code to AS
UAAS
PRC
| 30 |
30
AS issues token(s)
UAAS
PRC
| 31 |
31
AS issues token(s)
UAAS
PRC
| 32 |
32
Client accesses PR
UAAS
PRC
| 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?
So, OAuth is a sign-on protocol?
So, OAuth is a sign-on protocol?N o , i t i s n ’ t .
So, OAuth is a sign-on protocol?
N o , i t REALLY i s n ’ t .
| 37 |
37
A delicious metaphor
Metaphor from: http://blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx
Chocolate Fudge
VS
| 38 |
Delicious on its own Versatile ingredient
– Useful in many circumstances Can be used to make fudge
38
OAuth is Chocolate
| 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 |
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
Great idea!
Great idea!W h y h a s n ’ t a n y o n e d o n e t h a t ?
They are!D i s t r i b u t e d i d e n t i t y a t i n t e r n e t s c a l e
| 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 |
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 |
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 |
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 |
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 |
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 |
BACKUP CHARTSRESTful Health Exchange (RHEx)
RESTful Health Exchange (RHEx)
| 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.html
RESTful Health Exchange (RHEx)
| 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 |
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 URLURL-2 = Consult Results Details URL
RESTful Health Exchange (RHEx)
| 54 |
RHEx Pilot with TATRCTechnical Approach
RESTful Health Exchange (RHEx)
NwHIN DirectNwHIN Direct
| 55 |
RHEx Pilot with HealthInfoNet
Demonstrate secure, RESTful health data exchange from a Federally Qualified Health Center (FQHC) to Maine HIE using RHEx
55
IslandsCommunity
Medical Services
RESTful Health Exchange (RHEx)
| 56 |
RHEx Pilot with HealthInfoNetTechnical Approach
© 2013 The MITRE Corporation. All rights reserved. For internal MITRE use
RESTful Health Exchange (RHEx)
| 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)
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
©2012 The MITRE CorporationJustin Richer, The MITRE Corporation
| 59 |
Identity Provider Authorization 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 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
Service URL
Client gets the service URL (out of band – configuration, through user)
| 61 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
GET
Client fetches the service URL directly to access the data
| 62 |
IdP AS
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 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
AuthorizationRequest
Client directs user to auth server
302
| 64 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
AuthorizationRequest
Auth server redirects user to their IdP
302
| 65 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
Authentication& Authorization
User authenticates to IdP and authorizes auth server for login
| 66 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
Authorization CodeResponse
IdP directs user back to auth server with auth code
302
| 67 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
Authorization Code
Auth server trades auth code for tokens
| 68 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
Access TokenID Token
Auth server trades auth code for tokens
| 69 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
Access Token
Auth server trades access token for claims about the user
| 70 |
IdP AS
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 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
User AuthorizesClient at AS
User is now authenticated at auth server, authorizes client to access resource server
| 72 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
AuthorizationCode
Auth server redirects user back to client with auth code
302
| 73 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
AuthorizationCode
Client trades auth code for access token
| 74 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
AccessToken
Client trades auth code for access token
| 75 |
IdP AS
RS
Client
User
Front Channel
Back Channel
Out of Band
AccessToken
Client presents access token to resource server
| 76 |
IdP AS
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 |
IdP AS
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.
