Saturday, October 15, 2016

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)

    No comments:

    Post a Comment