O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
SMART on FHIR 
Scot Post van der Burg 
FHIR Developer Days 
November 25, 2014 
© 2014 HL7 ® International. Licensed under ...
My Background: 
 Healthcare IT consultant for Intermountain Healthcare 
(US) - Largest healthcare provider in the Intermo...
A Platform for Substitutable Medical Applications and Reusable 
Technology 
SMART ON FHIR 
© 2014 HL7 ® International. Lic...
Tutorial Topics: 
 Background and Motivation 
 The SMART on FHIR Specification 
 Data model and Data Exchange 
 Author...
Background 
 The SMART Project: 
 Predecessor to SMART on FHIR 
 Originally funded through a 4-year, $15M 
cooperative ...
Motivation 
 “To create an ecosystem of substitutable 
apps that can run on any electronic health 
record system” 
6 
© 2...
Motivation 
Let people 
with ideas… 
7 
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Se...
Motivation 
… do better than 
publishing PDFs 
8 
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Healt...
Motivation 
 Facilitate the sharing of clinical knowledge 
through development of cross-platform, 
interactive and substi...
The SMART on FHIR 
Specification 
10 
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seve...
Application Platform 
Challenges 
 Data Model/Data Exchange 
 FHIR: resources + profiles, RESTful services) 
 Security ...
Use Cases 
12 
 User: clinician, patient, none 
 Launch from: EHR, portal, none 
 Access: patient, population 
 Durati...
Data Model/Data 
Exchange 
FHIR: 
 Draft Standard within HL7 
 Open Standard 
 Resources, Datatypes, Value Sets (“80/20...
FHIR: What’s the 
problem? 
Healthcare Workflows: 
 Point-of-care 
 Long-term follow-up 
 Patient communications 
 Cli...
What is FHIR? 
15 
 50+ atomic resources 
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level...
What is FHIR? 
Extensibility 
 80/20 Principle for resources 
 Everything is extensible including primitives 
 Extensio...
What is FHIR? 
Datatypes (common structures for core 
meaning) 
17 
© 2014 HL7 ® International. Licensed under Creative Co...
What is FHIR? 
REST API (e.g. GET) 
All patients named “Amy”: 
/Patient?name=Amy 
All combined systolic+diastolic measurem...
What is FHIR? 
REST API (e.g. Search) 
 Chaining: 
“All blood pressures from females” 
/Observation?name=55284-4&subject:...
Data and Profiling 
 Shareable, portable applications require well 
defined platform contracts. 
 Consider an applicatio...
Data and Profiling 
 Another Example: FHIR Patient Resource 
 Patient.identifier 0..* 
 Patient.name 0..* 
 Patient.ge...
Security: Authorization 
 OAuth: “provides client applications ‘a 
secured delegated access’ to server 
resources on beha...
Security: Authorization 
 OAuth2: 
 Next Evolution of OAuth Protocol 
 Focus on “developer simplicity” 
 Defines speci...
OAuth2: “access 
delegation” 
EHR, Hospital, Clinic, 
Lab, Insurer, etc. 
24 
User 
Authorize 
(user approval) 
Data Holde...
OAuth2: Abstract 
Process 
25 
SMART 
APP 
EHR 
© 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health ...
OAuth2: Public vs. 
Confidential Clients 
 Designed around 2 different “client types” 
 Public clients: Clients incapabl...
OAuth2: Authorization 
Flows 
 Specialized flows for different use 
cases/client types 
 Authorization Code (three-legge...
OAuth2: Authorization 
Code Flow 
 Client Types: 
Confidential AND 
Public 
 Two steps: 
 Obtain “authorization 
code” ...
OAuth2: Authorization 
Code Flow 
 Features: 
 Ensures user is authenticated 
 Access tokens associated directly with c...
OAuth2: “two-legged 
auth” 
EHR, Hospital, Clinic, 
Lab, Insurer, etc. 
30 
Authorize 
(client secret) 
Data Holder 
App 
...
OAuth2: SMART on FHIR 
 Public clients (user-facing apps: web, 
mobile, etc.) and confidential clients must: 
 Register ...
OAuth2: Implicit Code 
Flow 
 Public clients 
 Client requests an access token (the token that 
grants access to protect...
OAuth2: Implicit Code 
Flow 
 Security Considerations 
 The access token is returned in a fragment of the 
registered re...
OAuth2: Implicit Code 
Flow 
 Some reasons why 3-legged auth is better 
for public clients 
 Even though 3-legged auth r...
Security: Authentication 
 OpenID Connect (OIDC) 
 Simple identity layer on top of OAuth2 
 Primary extension is the ID...
OIDC: Obtaining User 
Info 
 Clients can request end-user info (and the ability 
to authenticate the end-user) by request...
OAuth2: Access Scopes 
 Client requests “scopes” of access 
 patient/*.read 
 user/*.* 
 Scopes are independent, not c...
OAuth2 Access Scopes 
 Can and often will be treated contextually 
e.g. apply to resources owned by an authenticated 
use...
Entering the Authorization 
Flow 
 SMART on FHIR supports “launching” into 
the authorization flow for two types of apps:...
Entering the Authorization 
Flow: EHR Embedded Apps 
 Requirements: 
 The EHR has established a “launch context” to 
be ...
Entering the Authorization 
Flow: EHR Embedded Apps 
 Launch Steps: 
1. The EHR “notifies” the app of the launch by calli...
Entering the Authorization 
Flow: EHR Embedded Apps 
2. The app uses the “iss” parameter to call the EHR’s 
“metadata” end...
Sidebar: User Interface 
Integration 
1. SMART on FHIR defines the access scope: 
“launch:<launch_context_id>”, (ex. “laun...
Entering the Authorization 
Flow: Standalone Apps 
 Apps launched from outside the EHR won’t 
have access to a launch con...
Resources 
 SMART on FHIR Documentation 
 Specification 
 Tutorials 
 Building a JavaScript Application 
 Building a ...
Próximos SlideShares
Carregando em…5
×

de

SMART on FHIR by Scot Post van der Burg Slide 1 SMART on FHIR by Scot Post van der Burg Slide 2 SMART on FHIR by Scot Post van der Burg Slide 3 SMART on FHIR by Scot Post van der Burg Slide 4 SMART on FHIR by Scot Post van der Burg Slide 5 SMART on FHIR by Scot Post van der Burg Slide 6 SMART on FHIR by Scot Post van der Burg Slide 7 SMART on FHIR by Scot Post van der Burg Slide 8 SMART on FHIR by Scot Post van der Burg Slide 9 SMART on FHIR by Scot Post van der Burg Slide 10 SMART on FHIR by Scot Post van der Burg Slide 11 SMART on FHIR by Scot Post van der Burg Slide 12 SMART on FHIR by Scot Post van der Burg Slide 13 SMART on FHIR by Scot Post van der Burg Slide 14 SMART on FHIR by Scot Post van der Burg Slide 15 SMART on FHIR by Scot Post van der Burg Slide 16 SMART on FHIR by Scot Post van der Burg Slide 17 SMART on FHIR by Scot Post van der Burg Slide 18 SMART on FHIR by Scot Post van der Burg Slide 19 SMART on FHIR by Scot Post van der Burg Slide 20 SMART on FHIR by Scot Post van der Burg Slide 21 SMART on FHIR by Scot Post van der Burg Slide 22 SMART on FHIR by Scot Post van der Burg Slide 23 SMART on FHIR by Scot Post van der Burg Slide 24 SMART on FHIR by Scot Post van der Burg Slide 25 SMART on FHIR by Scot Post van der Burg Slide 26 SMART on FHIR by Scot Post van der Burg Slide 27 SMART on FHIR by Scot Post van der Burg Slide 28 SMART on FHIR by Scot Post van der Burg Slide 29 SMART on FHIR by Scot Post van der Burg Slide 30 SMART on FHIR by Scot Post van der Burg Slide 31 SMART on FHIR by Scot Post van der Burg Slide 32 SMART on FHIR by Scot Post van der Burg Slide 33 SMART on FHIR by Scot Post van der Burg Slide 34 SMART on FHIR by Scot Post van der Burg Slide 35 SMART on FHIR by Scot Post van der Burg Slide 36 SMART on FHIR by Scot Post van der Burg Slide 37 SMART on FHIR by Scot Post van der Burg Slide 38 SMART on FHIR by Scot Post van der Burg Slide 39 SMART on FHIR by Scot Post van der Burg Slide 40 SMART on FHIR by Scot Post van der Burg Slide 41 SMART on FHIR by Scot Post van der Burg Slide 42 SMART on FHIR by Scot Post van der Burg Slide 43 SMART on FHIR by Scot Post van der Burg Slide 44 SMART on FHIR by Scot Post van der Burg Slide 45
Próximos SlideShares
HL7 Fhir for Developers
Avançar
Transfira para ler offline e ver em ecrã inteiro.

9 gostaram

Compartilhar

Baixar para ler offline

SMART on FHIR by Scot Post van der Burg

Baixar para ler offline

SMART on FHIR by Scot Post van der Burg

SMART on FHIR by Scot Post van der Burg

  1. 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. 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. 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. 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 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.
  5. 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 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.
  6. 6. 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.
  7. 7. 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.
  8. 8. 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.
  9. 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 9 © 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. 10. 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.
  11. 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) 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.
  12. 12. 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.
  13. 13. 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.
  14. 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! 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.
  15. 15. 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.
  16. 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.” 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.
  17. 17. 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.
  18. 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=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.
  19. 19. 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.
  20. 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. 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.
  21. 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..* 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.
  22. 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.” 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.
  23. 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… 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.
  24. 24. 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 © 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. 25. OAuth2: Abstract Process 25 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. 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. 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.
  27. 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 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.
  28. 28. 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.
  29. 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) 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.
  30. 30. 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 © 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. 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) 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.
  32. 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) 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.
  33. 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. 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.
  34. 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) 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.
  35. 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 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.
  36. 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” 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.
  37. 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. 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 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.
  39. 39. 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.
  40. 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. 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.
  41. 41. 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.
  42. 42. 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.
  43. 43. 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.
  44. 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. 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.
  45. 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 45 © 2014 HL7 ® International. Licensed under Creative Commons. HL7 & Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.
  • LucasWeyne

    May. 6, 2021
  • PaulTurnerMBAPMP

    Mar. 30, 2021
  • ArindamDuttaChoudhury

    May. 16, 2020
  • ycarpegna

    Feb. 22, 2020
  • oyvindhollupolsen

    Dec. 27, 2018
  • NimeshPatelMBAPMP

    Apr. 20, 2017
  • GustavVella

    Nov. 23, 2016
  • job633141

    May. 24, 2016
  • mruau

    Aug. 4, 2015

SMART on FHIR by Scot Post van der Burg

Vistos

Vistos totais

6.156

No Slideshare

0

De incorporações

0

Número de incorporações

438

Ações

Baixados

386

Compartilhados

0

Comentários

0

Curtir

9

×