SMART on FHIR by Scot Post van der Burg

© 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


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


SMART ON FHIR

A Platform for Substitutable Medical Applications and Reusable

Technology


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

https://apps.fhir.me/apps/cardiac-risk/launch.html?fhirServiceUrl=https://fhir-open-api.smartplatforms.org&patientId=1288992


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


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

http://hl7.org/implement/standards/fhir/

http://hl7.org/implement/standards/fhir/


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

http://hl7.org/implement/standards/fhir/datatypes.html

http://hl7.org/implement/standards/fhir/datatypes.html


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

https://fhir-open-api.smartplatforms.org/Patient?name=amy&_format=json

https://fhir-open-api.smartplatforms.org/Observation?name:text=Blood pressure systolic and diastolic&_format=json

https://fhir-open-api.smartplatforms.org/Observation?name=55284-4&_format=json


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”

24

User

Authorize

(user approval)

Data Holder

EHR, Hospital, Clinic,

Lab, Insurer, etc.

App

Decision Support,

Visualization, eRx, etc.Get /ehr/data


OAuth2: Abstract Process

25

SMART

APPEHR


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


OAuth2: Authorization Code Flow

Client Types:

Confidential AND

Public

Two steps:

Obtain “authorization

code”

Exchange authorization

code for “access token”

28


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


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


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



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



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/*.read37


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


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



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


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


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

http://docs.smartplatforms.org/

SMART on FHIR by Scot Post van der Burg

Healthcare

Transcript of SMART on FHIR by Scot Post van der Burg