Upload
fhir-developer-days-2014
View
978
Download
0
Tags:
Embed Size (px)
Citation preview
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
SMART on FHIR
Scot Post van der Burg
FHIR Developer Days
November 25, 2014
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
My Background:
Healthcare IT consultant for Intermountain Healthcare
(US) - Largest healthcare provider in the Intermountain
West. Intermountain Healthcare is a benefactor member
of the Health Services Platform Consortium (HSPC).
Currently creating a reference implementation of the
HSPC’s open, standards based application platform
specification. The specification includes FHIR,
Intermountain Healthcare’s Clinical Element Models
(FHIR Profiles), and the SMART on FHIR specifications
for authorization/authentication and communication of
runtime clinical context.
2
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
SMART ON FHIR
A Platform for Substitutable Medical Applications and Reusable
Technology
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Tutorial Topics:
Background and Motivation
The SMART on FHIR Specification
Data model and Data Exchange
Authorization
UI Integration
Implementation
Creating a SMART on FHIR Application
4
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Background
The SMART Project:
Predecessor to SMART on FHIR
Originally funded through a 4-year, $15M
cooperative agreement with the Office of the
National Coordinator for Health
Part of the ONC’s SHARP Program (Strategic
Health-IT Advanced Research Projects).
Lead Architect: Josh Mandel, MD - Boston
Children’s Hospital
5
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Motivation
“To create an ecosystem of substitutable
apps that can run on any electronic health
record system”
6
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Motivation
Let people
with ideas…
7
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Motivation
… do better than
publishing PDFs
8
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Motivation
Facilitate the sharing of clinical knowledge
through development of cross-platform,
interactive and substitutable clinical
applications.
SMART Cardiac Risk application
Allows the patient to visualize their current risk of
heart-attack and the impact of behavioral changes
Gives medical recommendations based on current
status
Much more effective than a report9
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
The SMART on FHIR Specification
10
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Application Platform Challenges
Data Model/Data Exchange
FHIR: resources + profiles, RESTful services)
Security Protocols
Authorization: OAuth2
Identity: OIDC
User Interface Integration
(plus documentation, reference
implementation, sandbox, demo apps)
11
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Use Cases
12
User: clinician, patient, none
Launch from: EHR, portal, none
Access: patient, population
Duration: brief, long-term
Architecture: confidential, public
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Data Model/Data Exchange
FHIR:
Draft Standard within HL7
Open Standard
Resources, Datatypes, Value Sets (“80/20”)
Extensible
REST API
13
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
FHIR: What’s the problem?
Healthcare Workflows:
Point-of-care
Long-term follow-up
Patient communications
Clinical Research
Device Integration
…all with International agreement and
flexibility!14
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
What is FHIR?
15
50+ atomic resources
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
What is FHIR?
Extensibility
80/20 Principle for resources
Everything is extensible including primitives
Extension vs. modifierExtension
“Note that, unlike many other specifications, there can be no stigma
associated with the use of extensions by any application, project, or
standard – regardless of the institution or jurisdiction that uses or defines
the extensions. The use of extensions is what allows the FHIR
specification to retain a core simplicity for everyone.”
16
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
What is FHIR?
Datatypes (common structures for core
meaning)
17
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
What is FHIR?
REST API (e.g. GET)
All patients named “Amy”:
/Patient?name=Amy
All combined systolic+diastolic measurements:
/Observation?name:text=systolic+and+diastolic
/Observation?name=55284-4
18
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
What is FHIR?
REST API (e.g. Search)
Chaining:“All blood pressures from females”
/Observation?name=55284-4&subject:Patient.gender=F
Inclusion paths:“BP Measurements with their component parts”
/Observation?name=55284-4&_include=Observation.related.target
19
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Data and Profiling
Shareable, portable applications require well
defined platform contracts.
Consider an application that wants to query
“all Conditions that began in 2014”
FHIR Condition Resource: “onsetDate”,
“dateAsserted” (either, neither or both may be
populated)
SMART on FHIR defines a profile requiring a date
in “dateAsserted”, eliminating guesswork for apps.
20
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Data and Profiling
Another Example: FHIR Patient Resource
Patient.identifier 0..*
Patient.name 0..*
Patient.gender 0..1
SMART on FHIR Patient Profile
Patient.identifier 1..*
Patient.name 1..*
Patient.gender 1..*21
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Security: Authorization
OAuth: “provides client applications ‘a
secured delegated access’ to server
resources on behalf of a resource owner. It
specifies a process for resource owners to
authorize third-party access without sharing
their credentials.”
22
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Security: Authorization
OAuth2:
Next Evolution of OAuth Protocol
Focus on “developer simplicity”
Defines specific authorization flows for:
Web Applications
Desktop Applications
Mobile Applications and more…
23
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2: “access delegation”
24
User
Authorize
(user approval)
Data Holder
EHR, Hospital, Clinic,
Lab, Insurer, etc.
App
Decision Support,
Visualization, eRx, etc.Get /ehr/data
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2: Abstract Process
25
SMART
APPEHR
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2: Public vs. Confidential Clients
Designed around 2 different “client types”
Public clients: Clients incapable of maintaining the
confidentiality of their credentials…
HTML5 + Javascript applications
IOS Apps etc.
Confidential clients: Clients capable of maintaining
the confidentiality of their credentials…
Web applications
Server side applications etc.
26
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2: Authorization Flows
Specialized flows for different use
cases/client types
Authorization Code (three-legged auth)
Client Credentials (two-legged auth)
Implicit
Resource Owner Credentials
27
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2: Authorization Code Flow
Client Types:
Confidential AND
Public
Two steps:
Obtain “authorization
code”
Exchange authorization
code for “access token”
28
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2: Authorization Code Flow
Features:
Ensures user is authenticated
Access tokens associated directly with clients/users
Client can be authenticated when access token is
requested (confidential clients)
Access token can be delivered over TLS secured
connection (https)
29
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2: “two-legged auth”
30
Authorize
(client secret)
Data Holder
EHR, Hospital, Clinic,
Lab, Insurer, etc.
App
Decision Support,
Visualization, eRx, etc.Get /ehr/data
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2: SMART on FHIR
Public clients (user-facing apps: web,
mobile, etc.) and confidential clients must:
Register a TLS protected redirect UR
Use 3-legged OAuth + strict redirect checking
Not use 2-legged authorization (like OAuth2’s
Implicit Flow for public clients)
31
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2: Implicit Code Flow
Public clients
Client requests an access token (the token that
grants access to protected resources) directly from
the authorization server without a client secret.
Resource owner must still grant access.
Considered an optimization of the 3-legged flow
because it eliminates a step (the one that would or
could authenticate the client if it could keep a
secret)
32
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2: Implicit Code Flow
Security Considerations
The access token is returned in a fragment of the
registered redirect URI, potentially exposing it to
unauthorized parties allowing an attacker to
impersonate the resource owner.
33
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2: Implicit Code Flow
Some reasons why 3-legged auth is better
for public clients Even though 3-legged auth returns the authorization
code on the redirect URI, it’s hijacking could be
mitigated by:
Short expiry for authorization codes
Limit access request attempts
Authentication of users at authorization code request
Longer lived access tokens are transmitted over TLS
(HTTP response)
34
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Security: Authentication
OpenID Connect (OIDC)
Simple identity layer on top of OAuth2
Primary extension is the ID Token data structure
JSON Web Token (JWT) containing “claims” about
the authentication of an end-user
Provides a mechanism for clients to authenticate
end-users through validation of an “ID Token”
End user info can be retrieved using the OIDC’s
UserInfo endpoint
35
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OIDC: Obtaining User Info
Clients can request end-user info (and the ability
to authenticate the end-user) by requesting a pair
of OIDC scopes:
openid (request for ID Token)
profile (request for “claim” name-value pairs from the
user profile: name, gender, birthdate)
Claims can be extended, allowing contextually
relevant information to be communicated, e.g. a
FHIR Resource “Practitioner” ref for the user.
“fhir_resource”: “/Practitioner/456”36
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2: Access Scopes
Client requests “scopes” of access
patient/*.read
user/*.*
Scopes are independent, not composable
“read write documents” – 3 scopes, not 1
Authorization server can grant more limited
scopes of access than were requested
patient/Observation.read
user/*.read37
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
OAuth2 Access Scopes
Can and often will be treated contextually
e.g. apply to resources owned by an authenticated
user etc.
Scopes should be designed to support a
spectrum of access.
Cardiac Risk application
patient/Patient.read, patient/Observation.read
Diabetes Monograph application
patient/*.read
38
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Entering the Authorization Flow
SMART on FHIR supports “launching” into
the authorization flow for two types of apps:
EHR Embedded Apps
Standalone Apps
39
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Entering the Authorization Flow: EHR Embedded Apps
Requirements:
The EHR has established a “launch context” to
be made available to the launching application.
The launch context contains information about
the currently selected patient, encounter,
physical location of the user etc.
The client has registered a TLS protected launch
URL with the EHR.
40
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Entering the Authorization Flow: EHR Embedded Apps
Launch Steps:1. The EHR “notifies” the app of the launch by calling it’s
launch URL with 2 parameters:
1. iss : FHIR base URL of the EHR that “issued” the
launch notification.
2. launch : The opaque ID of the current launch context.
EX:
https://app/launch?iss=https%3A%2F%2Fehr%2Ffhir&launch=xyz12
3
41
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Entering the Authorization Flow: EHR Embedded Apps
2. The app uses the “iss” parameter to call the EHR’s
“metadata” endpoint, returning a FHIR conformance
statement with 3 security extensions containing the
EHR’s authorization and token endpoints.
3. The app executes the OAuth “Authorization Code” flow
using the EHR’s authorization and token endpoints.
42
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Sidebar: User Interface Integration
1. SMART on FHIR defines the access scope:
“launch:<launch_context_id>”, (ex. “launch.xyz123”) that
allows an app to request information about current
patient in context, current encounter etc.
2. The app request the “launch” scope in it’s OAuth
requests, and the launch data are returned in the token
response.
43
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Entering the Authorization Flow: Standalone Apps
Apps launched from outside the EHR won’t
have access to a launch context. SMART on FHIR defines specific launch scopes that can be
requested, e.g. “launch/patient” that requests a patient to be
selected at launch time. The EHR can “gather” launch
context as necessary to support the requested scopes.
44
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
Resources
SMART on FHIR Documentation
Specification
Tutorials
Building a JavaScript Application
Building a SMART on FHIR Server
Client libraries
Public testing sandbox
Google Group
GitHub repository45