SMART on FHIR by Scot Post van der Burg

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

A Platform for Substitutable Medical Applications and Reusable
Technology
SMART ON FHIR

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

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

Motivation
 “To create an ecosystem of substitutable
apps that can run on any electronic health
record system”
6

Motivation
Let people
with ideas…
7

Motivation
… do better than
publishing PDFs
8

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 report
9

The SMART on FHIR
Specification
10

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

Use Cases
12
 User: clinician, patient, none
 Launch from: EHR, portal, none
 Access: patient, population
 Duration: brief, long-term
 Architecture: confidential, public

Data Model/Data
Exchange
FHIR:
 Draft Standard within HL7
 Open Standard
 Resources, Datatypes, Value Sets (“80/20”)
 Extensible
 REST API
13

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

What is FHIR?
15
 50+ atomic resources

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

What is FHIR?
Datatypes (common structures for core
meaning)
17

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

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

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

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

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

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

OAuth2: “access
delegation”
EHR, Hospital, Clinic,
Lab, Insurer, etc.
24
User
Authorize
(user approval)
Data Holder
App
Decision Support,
Visualization, eRx, etc.
Get /ehr/data

OAuth2: Abstract
Process
25
SMART
APP
EHR

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

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

Code Flow
 Client Types:
Confidential AND
Public
 Two steps:
 Obtain “authorization
code”
 Exchange authorization
code for “access token”
28

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

OAuth2: “two-legged
auth”
EHR, Hospital, Clinic,
Lab, Insurer, etc.
30
Authorize
(client secret)
Data Holder
App
Decision Support,
Visualization, eRx, etc.
Get /ehr/data

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

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

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

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

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

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

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/*.read
37

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

Entering the Authorization
Flow
 SMART on FHIR supports “launching” into
the authorization flow for two types of apps:
 EHR Embedded Apps
 Standalone Apps
39

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

 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

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

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

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

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 repository
45

SMART on FHIR by Scot Post van der Burg

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to SMART on FHIR by Scot Post van der Burg

Similar to SMART on FHIR by Scot Post van der Burg (20)

More from Furore_com

More from Furore_com (14)

Recently uploaded

Recently uploaded (20)

SMART on FHIR by Scot Post van der Burg

Editor's Notes