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.

Slides:



Advertisements
Similar presentations
OAuth 2.0 By “PJ” (JP on meetup.com) iOS and PHP developer, and occasional lawyer Contact me via:
Advertisements

Secure RESTful Interface Profile Phase 1 Briefing
1Proprietary and Confidential AirVantage API – Getting started David SCIAMMA – June 13th 2014.
SHARP Area 3: SMART (Substitutable Medical Apps) Josh C. Mandel, MD Lead Architect, SMART (
FEBRUARY 5, 2015 STANLEY M. HUFF, MD CHIEF MEDICAL INFORMATICS OFFICER INTERMOUNTAIN HEALTHCARE HSPC Meeting Introduction.
A Primer on Healthcare Information Exchange John D. Halamka MD CIO, Harvard Medical School and Beth Israel Deaconess Medical Center.
GRDevDay March 21, 2015 Cloud-based Identity for Applications.
Healthcare Services Platform Sandbox. The HSPC Sandbox HSPC Sandbox Architecture : Scot Post van der Burg Asthma Ally.
Note: This is a preliminary discussion
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg.
Cross Domain Patient Identity Management Eric Heflin Dir of Standards and Interoperability/Medicity.
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg.
TATRC and MITRE to NwHIN Power Team 12 June 2013 RESTful Health Exchange (RHEx)
Health IT RESTful Application Programming Interface (API) Security Considerations Transport & Security Standards Workgroup March 18, 2015.
AUGUST 21, 2014 STANLEY M. HUFF, MD CHIEF MEDICAL INFORMATICS OFFICER INTERMOUNTAIN HEALTHCARE HSPC Meeting Introduction.
A Robust Health Data Infrastructure P. Jon White, MD Director, Health IT Agency for Healthcare Research and Quality
Cross Domain Patient Identity Management Eric Heflin Dir of Standards and Interoperability/Medicity.
Overview for IHE The MITRE Corporation. Overview hData was originally developed by The MITRE Corporation – Internal R&D – Focus on simplifying Continuity.
Survey of Identity Repository Security Models JSR 351, Sep 2012.
Workgroup Discussion on RESTful Application Programming Interface (API) Security Transport & Security Standards Workgroup January 12, 2014.
OpenPASS Open Privacy, Access and Security Services “Quis custodiet ipsos custodes?”
By Rick Freeman THE HEALTHCARE INNOVATION ECOSYSTEM HiMSS 2015 & Development Sandboxes Update President & Founder iSalus Consulting June 19, 2015.
20 Oct 2014.
Health eDecisions Use Case 2: CDS Guidance Service Strawman of Core Concepts Use Case 2 1.
Meeting Etiquette Please announce your name each time prior to making comments or suggestions during the call Remember: If you are not speaking keep your.
Draft Provider Directory Recommendations Begin Deliberations re Query for Patient Record NwHIN Power Team July 10, 2014.
Justin Richer The MITRE Corporation October 8, 2014 Overview of OAuth 2.0 and Blue Button + REST.
Securing Angular Apps Brian Noyes
The CareWeb Framework An Update
Secure Mobile Development with NetIQ Access Manager
#SummitNow Consuming OAuth Services in Alfresco Share Alfresco Summit 2013 Will Abson
The CareWeb Framework An Update Doug Martin MD. Regenstrief Institute
Developers Introduction to the Power BI Platform.
ArcGIS for Server Security: Advanced
4/18/2018 1:15 PM © Microsoft Corporation. All rights reserved. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN.
Consuming OAuth Services in Alfresco Share
Azure Identity Premier Fast Start
5/13/2018 © 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks.
API (Application Program Interface)
Federation made simple
Phil Hunt, Hannes Tschofenig
Open Platforms for Innovation
Sabri Kızanlık Ural Emekçi
SMART Architecture and Application Development Overview
Migrating SharePoint Add-ins from Azure ACS to Azure AD
Data Virtualization Tutorial… OAuth Example using Google Sheets
Chapter 18 MobileApp Design
OAuth2, OpenID Connect, and Science Gateways
Science Gateway Security Considerations
FHIR BULK DATA API April 2018
WEB API.
CDS Hooks HL7 WGM Jan 2018 CDS Working Group Tuesday, January 30, 2018
OpenID Connect Working Group
RAIN Live Oak Data Provenance API
The main cause for that are the famous phishing attacks, in which the attacker directs users to a fake web page identical to another one and steals the.
Agenda OAuth Concepts Programming OAuth.
Care Connect API Overview & Roadmap presented by Richard Kavanagh.
Introduction to the HSPC Sandbox
Get Real Health and FHIR®
HL7 FHIR Connectathon Care Planning & Management Track
SharePoint Online Authentication Patterns
Harvard Medical School
Office 365 Development.
ARCHITECTURE OVERVIEW
SMART on FHIR for managed authorised access to medical records
Microsoft Ignite NZ October 2016 SKYCITY, Auckland.
敦群數位科技有限公司(vanGene Digital Inc.) 游家德(Jade Yu.)
Western Mass Microsoft Technology Users Group
Computer Network Information Center, Chinese Academy of Sciences
Da Vinci Community Forum
Presentation transcript:

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 © 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: Inclusion paths: “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 © 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. © 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..* © 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.” © 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… © 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” 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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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: https://app/launch?iss=https%3A%2F%2Fehr%2Ffhir&launch=xyz12 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.

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.

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.

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.

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.