Tutorial on #FHIR #Security

Nice recorded tutorial by Pascal Pfiffner on FHIR Security from an application developer perspective. I understand from Rene that this was written based on my outline in the article FHIR Security and Privacy - tutorial outline

Some more details and emphasis...

One question that was asked was about Business-to-Business. 

Pascal answered this fantastically. I want to add emphasis as it is something that people that hear about OAuth will misunderstand. Most tutorials will cover how to use OAuth with a human-user. OAuth is not limited to human users. OAuth can make security tokens about an application. So OAuth can be used. An alternative is to use mutually-authenticated-TLS, where the client system is authenticated using PKI using the client side authentication built into TLS. This is what is commonly used in DICOM, XDS, and older HL7. It is just as useful in FHIR.

Rene has asked for further information is on IUA:

IUA is 99% just pointers at use of OAuth 2.0. The only 'profiling' that IHE did was to provide some well-defined elements for some well-needed user attributes. This is really the only thing that IHE defined. So if a purposeOfUse is going to be declared, a specific element in the JSON would hold purposeOfUse. So that the relying party (service) can extract them out and use them in service-side access control decisions and audit logging. The list of elements is the same list of elements we have in XUA. Which is also an option, that is to have our OAuth token encapsulate your XUA SAML token... (unlikely).

See Internet User Authorization: why and where

FHIR Scopes

What people likely want to learn is how to deal with OAuth 'scope". This is not part of IUA. This is really something that has not yet been seriously discussed. SMART has their view, HEART is struggling. The SMART list is very rudimentary and I see real issues with some of it. Pascal does a good job of explaining he SMART scopes.

IHE is feeling that scopes need to be defined in the profile where the data is defined. That is to say that IUA is agnostic of the grouped data profile (MHD, PDQm, PIXm, mACM, mATNA, etc). It is really up to those other profiles to define reasonable scope values. That is it seems more logical that MHD would define the document-sharing scopes of interest, while PDQm defines the patient lookup scopes of interest. This scope effort has not yet happened, primarly due to lack of implementation experience.

See FHIR Oauth Scope

Reference my other articles on mHealth (FHIR)

• Extending the FHIR standard to handle provenance
• IHE #FHIR profiles - MHD, PDQm, and PIXm
• MHD - Why use of FHIR Contained?
• electronic Privacy Consent -- Patient choice
• Consent given to authorized representative
• FHIR Security and Privacy - tutorial outline
• Consent to grant read access to a specific types of FHIR Resources
• MHD in action -- XDS on FHIR
• Guidance on HTTP Access Denied
• Break-Glass on FHIR solution
• FHIR Oauth Scope
• HEART profiles for review, comment, and approval 
• Building a MHD Client before MHD is DSTU2 aligned 
• IHE updating FHIR Profiles to align with DSTU2 
• Break-Glass on FHIR  
• FHIR Security initiatives
• How to set the ConfidentialityCode
• FHIR does not need a deidentify=true parameter  
• What is MHD beyond XDS-on-FHIR? 
• MHD Connectathon Results
• FHIR Security: Do (Not) Worry
• FHIR Full Steam Ahead
• Define Atom -- Too many definitions in use today 
• Healthcare access control scope constraints on OAuth tokens
• mHealth Identities using trusted intermediary
• getting to mHealth solutions - real People
• getting to mHealth solutions - Users
• Internet User Authorization: why and where
• Security Considerations: Healthcare RESTful Resource specifications
• Privacy and Security in Designing an mHealth Application
• mHealth Solution
• Security Considerations: Healthcare RESTful Resource specifications
• IHE efforts in RESTful security
• IHE mHealth Hackathon
• The Magic of FHIR – The HL7 movement toward REST resources, away from v3 and v2 
• IHE Mobile access to Health Documents - Trial Implementation