SMART on FHIR - CDS Hooks workstream

Hi,

This Friday's Smart on FHIR workstream call will focus on SMART on FHIR deployment models with a presentation from Infoway. It will be a great opportunity to see the work to date and provide valuable feedback.

Thanks,

Gavin

Hi all,

Please see below for the minutes/highlights from the March 2nd SMART on FHIR / CDS Hooks workstream call:

Attendees:

Joel Francis
Alex Platkin
Piers Hollott
Kevin Dougan
Harsh Sharma
Tib Onu
John Wills
Jorge Pichardo
Gavin Tong
Igor Sirkovich
Attila Farkas
Shamil Nizamov
Tue Hoang
Rita Pyle
Anil Patel

Intro - EMRs – Conceptual Level

• How can we leverage the marketplace of apps/ third-party solutions/etc in the EMR/EHR/HIS space?

Intro - Collaboration Paradigm

• Providing an interface to share data; great in theory but will run into scalability issues
• Lack of a standardized approach to this in the health care space; one of the most significant standards needed is a standard approach to securing these collaborations

Intro - SMART on FHIR

• A combination of standards for security and data models (i.e. FHIR) to create sets of interface standards
• SoF adopted FHIR as the data model, and OAuth2 as the security model (used for authorization, not authentication)
• This combined set of standard protocols/models can establish connections between clinical/source systems (i.e. an HIS) and SMART apps

Demo Architecture

• Joel Francis provided a demo showing a growth chart app opening within the clinical information system; growth chart was able to use the CIS’ data
• Source code for the demo is shared and available on GitHub

Key Takeaways

• Trust is implemented via OAuth2
• Clinical source system needs to be able to render app/web content
• SMART on FHIR requires a standard data model; the Argonaut project in the US has produced standard profiles for using the FHIR data model; Canadian adoption will require a Canadian FHIR baseline; the external app can’t just ‘guess’ what the source system’s data model is

Whiteboard Exercise

• Attila provided a whiteboard exercise on what some of the business and architectural considerations are

Questions

• What is the extent of the SMART on FHIR Spec? Beyond on the OAuth2 standard behavior?
• Can we go beyond what SMART on FHIR balloted with HL7?
• How do different versions of FHIR support the varied instances of SMART on FHIR? Having an understanding of this will help us determine if SMART on FHIR will work with particular FHIR-based systems
• Is there anything in the SMART on FHIR Spec which dictates whether or not different uses/exchanges of data is ‘meaningful’ or legitimate?
• Business level – what if the source system interacts with the app store which houses the info from the app providers themselves? This way, anything on the app store platform could reliably be accessible in a standardized way

Comments

• Sites/hospitals could build apps in-house, rather than rely on existing third-party apps (i.e. from a formal app store)
• Can look at the difference between provider- and patient-facing SMART on FHIR use cases
• Certain information system vendors promote ‘app stores’, however they are not app stores in the regular sense; the apps can’t be downloaded and used; they’re more of a promotion for the info system’s functionalities; this demonstrates how much of a focus the ‘trust’ protocol is
• Could eventually have a SMART app development initiative; an example being an app which can query provincial registries for patient & provider data

Next Steps

• Create a micro site to share information and examples
• OAuth2 Specification
• Architectural and Business Models to support SMART on FHIR
• Next call will be a planning meeting; drafting the initial deliverables

Hi all!

Please find below a mix of minutes/highlights from the fantastic presentation provided by Tib Onu on Friday January 19th, for the SMART on FHIR / CDS Hooks workstream bi-weekly call. The full, recorded experience is available as well (see 'Video' tab from the main page).

Attendees:

Attila Farkas
John Wills
Michael Savage
Sisira de Silva
Smita Kachroo
Tib Onu
Debbie Onos
Finnie Flores
Joel Francis
Piers Hollott
Shamil Nizamov
Alan Leung
Cindy Jiang

Introduction:

• This was the third SMART on FHIR Workstream meeting
• Attila introduced Tib Onu, Senior Technical Architect, Clinical Systems Integration at Canada Health Infoway

Presentation – SAML2, OAuth2, OpenID Connect – Overview

• Tib Onu presented on the SAML2, OAuth2, and OpenID Connect standards, and on some of the key concepts on which these protocols are based. Some highlights below:

• Tokens
o Compact credentials for getting limited access to resources in a system
o Passing around tokens is the basis for identity management

• 2 types of Tokens: Access Tokens vs. Refresh Tokens
o Access: short-term, gained through authentication, used in ‘sessions’
o Refresh: can be used to get a new access token, w/o having to enter new credentials or re-enter existing ones (like a password)

• Tokens can be passed around by Value or Reference
o Value: JSON/XML structure
o Reference: no human-readable meaning; would need to decode the data to understand it

• Token Profiles: Bearer Tokens vs. Holder-of-Key Tokens
o Bearer: whoever has one can use it directly
o Holder-of-Key: must prove identity before using it

• Token Data Formats (structures for encapsulating user data)
o WS – Security: encapsulates user data
o SAML: has its own format
o JWT: JSON Web Token
o Proprietary: i.e. Oracle’s Access Manager

• Identity Federation with SAML2 – how do SAML2 tokens relate to OAuth2?
o SAML2: the use of SAML Request and SAML Token
o User can use the same credentials both inside and outside of the organization
o SAML2 largely allows for federated identity
o OAuth2 supports the usage of the SAML Token

• OAuth2
o Allows 3rd party apps to invoke APIs on a resource server for a user
o A ‘protocol of protocols’, it is designed to be loose; there is nothing mandating the content of the tokens being passed through the OAuth2 flows

• OAuth2 Roles
o User: the resource owner
o Client: the 3rd party app
o Resource server: the API server
o Authorization server: the server with OAuth2 potential

• SMART on FHIR – 3rd party apps need authorization from resource owner, before rendering requested information/functions in the app, which itself sits in the EMR/EHR/HIS/etc.

• Refer to recording of presentation (posted on FHIR Implementations Group, see ‘Video’ tab) for sample OAuth2 and OpenID Connect flows

• OpenID Connect
o An authentication layer that sits on top of OAUth2
o It allows the client to verify the identity of the user
o OIDC reuses the OAuth2 flows but adds an ID Token – a JWT-formatted token (field names are fixed)