Introduction to SMART on FHIR
0 likes118 views
The document provides an introduction to SMART on FHIR, detailing its evolution and association with HL7 standards which enable global health data interoperability. It outlines authentication methods including OAuth 2.0 and its various grant types, emphasizing its importance for securing healthcare applications. Additionally, the document discusses how SMART on FHIR facilitates app authorization while maintaining narrow scopes for access tokens to enhance security in clinical systems.
Introduction to SMART on FHIR
- 1. Introduction to SMART on FHIR By Nishit Charania https://www.linkedin.com/in/nishit-charania Tuhin Das Gupta https://www.linkedin.com/in/tuhin-das-gupta-14a11b32/
- 2. Genesis
- 4. About- HL7, FHIR fundamentals HL7- Health Level Seven 7. Application layer 6. Presentation layer 5. Session layer 4. Transport layer 3. Network layer 2. Data link layer 1. Physical layer • Found in 1987 • ANSI-accredited Standards Development Organization • HL7’s mission is to develop standards and framework for global health data interoperability • Focus on the application layer, which is "layer 7" in the OSI model.
- 5. About- HL7, FHIR fundamentals What is ? https://api.sit.com /Patient/00012345 https://api.sit.com/fhir/QuestionnaireResponse?identifier=uuid:g1|&questionnaire=Questionnaire/2
- 6. HTTP Basic Authentication PROS • Easy to implement • Small systems CONS • Only username / password • Hard to integrate • No distinction between users and machines A little history of authentication
- 7. About- OAuth What Is OAuth ? An open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.
- 8. • Resource Owner: the person or the application that holds the data to be shared. • Resource Server: the application that holds the protected resources. • Authorization Server: the application that verifies the identity of the users. • Client: the application that makes requests to the RS on behalf of the RO. OAuth 2.0 : Terminology
- 9. Resource Owner Resource Server Authorization Server Client OAuth 2.0 : protocol flow
- 10. Resource Owner Resource Server Authorization Server Client I want to see a list of Photos OAuth 2.0 : protocol flow
- 11. Resource Owner Resource Server Authorization Server Client Hey, backend, could you please give me a list of Photos? OAuth 2.0 : protocol flow
- 12. Resource Owner Resource Server Authorization Server Client Sorry, this is a protected resource. You will need to present me an access token OAuth 2.0 : protocol flow
- 13. Resource Owner Resource Server Authorization Server Client OAuth 2.0 : protocol flow
- 14. Resource Owner Resource Server Authorization Server Client OAuth 2.0 : protocol flow
- 15. Resource Owner Resource Server Authorization Server Client Hi, could you please provide me your credentials? I need to verify your identity OAuth 2.0 : protocol flow
- 16. Resource Owner Resource Server Authorization Server Client No problem at all. I am user@karkinos.com and my password is *****. OAuth 2.0 : protocol flow
- 17. Resource Owner Resource Server Authorization Server Client OAuth 2.0 : protocol flow
- 18. Resource Owner Resource Server Authorization Server Client Hi Backend, this is my token: ser345ggs2sf34t.2343ysfaaerwetr78wgr.seer34 OAuth 2.0 : protocol flow
- 19. Resource Owner Resource Server Authorization Server Client Hi, can you please validate access token ser345ggs2sf34t.2343ysfaaerwetr78wgr.seer34? OAuth 2.0 : protocol flow
- 20. Resource Owner Resource Server Authorization Server Client Of course. It is valid token OAuth 2.0 : protocol flow
- 21. Resource Owner Resource Server Authorization Server Client Everything is alight. This is the list of photos. OAuth 2.0 : protocol flow
- 22. Resource Owner Resource Server Authorization Server Client Here you have the list of photos OAuth 2.0 : protocol flow
- 23. Resource Owner Resource Server Authorization Server Client OAuth 2.0 is a delegation protocol, as Client has no idea about the credentials of User OAuth 2.0 : protocol flow
- 24. • authorization-code: The Authorization Code grant type is used by confidential and public clients to exchange an authorization code for an access token. (For more Ref: https://oauth.net/2/grant-types/authorization- code/) • PKCE: PKCE (RFC 7636) is an extension to the Authorization Code flow to prevent CSRF and authorization code injection attacks. (For more Ref : https://oauth.net/2/pkce/ ) • client-credentials: The Client Credentials grant type is used by clients to obtain an access token outside of the context of a user. (For more Ref : https://oauth.net/2/grant-types/client-credentials/ ) • device-code: The Device Code grant type is used by browserless or input- constrained devices in the device flow to exchange a previously obtained device code for an access token.(For more Ref : https://oauth.net/2/grant- types/device-code/ ) OAuth 2.0 : grant types
- 25. Substitutable Medical Apps and Reusable Technologies (SMART) • To allow apps that run across heterogeneous security environments, SMART on FHIR specifies how apps obtain authorization tokens, but allows servers to apply any necessary policies to determine a user's permissions. • Every representational state transfer (REST) API call includes an authorization token obtained and transmitted via OAuth 2. • The scope of access tokens is kept narrow so that, for instance, an app working with a single patient record requests a limited-scope access token that is only valid for querying that patient's data
- 26. Healthcare Apps Clinical Systems (e.g., EHR, Patient Portal, Data Warehouse) SMART UX Integration Authorization Single Sign-On FHIR APIs SMART Apps- Core focus
- 27. App EHR 1. Authorization request (scopes) 3. FHIR API request (with access token) 3. FHIR Resources 3. Display Data 1. Response (yes/no; scopes) 2. Token request 2. Response (access token, id token, context) OAuth based Standalone App Launch
- 28. App EHR OAuth Based EHR App Launch 1. Authorization request (scopes) 3. FHIR API request (with access token) 3. FHIR Resources 3. Display Data 1. Response (yes/no; scopes) 2. Token request 2. Response (access token, id token, context) 0. Launch request (server URL, launch id)
- 29. • Scopes convey what access an app needs Access Type FHIR Resource Permission Patient / Immunization . read SMART Authorization scopes, v1 examples • patient/Patient.read, patient/Observation.read • patient/*.read • patient/MedicationOrder.write • user/*.read
- 30. Goal Scope Notes Read and search for all observations about a patient patient/Observation.rs Read demographics about a patient patient/Patient.r Note the difference in capitalization between “patient” the permission type and “Patient” the resource. Add new blood pressure readings for a patient patient/Observation.c Note that the permission is broader than the goal: with this scope, an app can add not only blood pressures, but other observations as well. Note also that write access does not imply read access. Read all available data about a patient patient/*.cruds See notes on wildcard scopes below. SMART Authorization scopes, v2
- 31. • SMART App Gallery offer a single place to find and learn about SMART and FHIR apps • Vendor and license neutral • Not restricted to a single EHR platform • Hosts commercial and open source apps • No cost to list or browse apps Public App gallery
- 33. Thank You