Presentation is loading. Please wait.

Presentation is loading. Please wait.

SMART on FHIR Scot Post van der Burg FHIR Developer Days November 25, 2014 https://www.slideshare.net/mobile/DevDays2014/fhir-and-dicom-marten-smits?qid=1061d4c5-2ba5-4d56-bf77-e6ec87b56c05&v=&b=&from_search=1.

Similar presentations


Presentation on theme: "SMART on FHIR Scot Post van der Burg FHIR Developer Days November 25, 2014 https://www.slideshare.net/mobile/DevDays2014/fhir-and-dicom-marten-smits?qid=1061d4c5-2ba5-4d56-bf77-e6ec87b56c05&v=&b=&from_search=1."— Presentation transcript:

1 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.

2 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.

3 A Platform for Substitutable Medical Applications and Reusable
Technology SMART ON FHIR © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

4 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 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

5 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 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

6 Motivation “To create an ecosystem of substitutable apps that can run on any electronic health record system” © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

7 Motivation Let people with ideas…
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

8 Motivation … do better than publishing PDFs
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

9 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 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

10 The SMART on FHIR Specification
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

11 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) © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

12 Use Cases 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.

13 Data Model/Data Exchange
FHIR: Draft Standard within HL7 Open Standard Resources, Datatypes, Value Sets (“80/20”) Extensible REST API © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

14 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! © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

15 What is FHIR? 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.

16 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.” © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

17 What is FHIR? Datatypes (common structures for core meaning)
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

18 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= © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

19 What is FHIR? REST API (e.g. Search) Chaining: Inclusion paths:
“All blood pressures from females” /Observation?name= &subject:Patient.gender=F Inclusion paths: “BP Measurements with their component parts” /Observation?name= &_include=Observation.related.target © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

20 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. © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

21 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..* © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

22 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.” © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

23 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… © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

24 OAuth2: “access delegation”
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.

25 OAuth2: Abstract Process
SMART APP EHR © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

26 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. © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

27 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 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

28 OAuth2: Authorization Code Flow
Client Types: Confidential AND Public Two steps: Obtain “authorization code” Exchange authorization code for “access token” © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

29 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) © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

30 OAuth2: “two-legged auth”
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.

31 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) © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

32 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) © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

33 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. © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

34 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) © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

35 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 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

36 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” © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

37 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 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

38 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 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

39 Entering the Authorization Flow
SMART on FHIR supports “launching” into the authorization flow for two types of apps: EHR Embedded Apps Standalone Apps © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

40 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. © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

41 Entering the Authorization Flow: EHR Embedded Apps
Launch Steps: The EHR “notifies” the app of the launch by calling it’s launch URL with 2 parameters: iss : FHIR base URL of the EHR that “issued” the launch notification. launch : The opaque ID of the current launch context. EX: 3 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

42 Entering the Authorization Flow: EHR Embedded Apps
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. The app executes the OAuth “Authorization Code” flow using the EHR’s authorization and token endpoints. © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

43 Sidebar: User Interface Integration
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. The app request the “launch” scope in it’s OAuth requests, and the launch data are returned in the token response. © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

44 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. © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

45 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 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.


Download ppt "SMART on FHIR Scot Post van der Burg FHIR Developer Days November 25, 2014 https://www.slideshare.net/mobile/DevDays2014/fhir-and-dicom-marten-smits?qid=1061d4c5-2ba5-4d56-bf77-e6ec87b56c05&v=&b=&from_search=1."

Similar presentations


Ads by Google