As FHIR matures, the security topic becomes more and more important. I participate in HEART, an effort hosted by the OpenID community including an impressive set of experts from the OpenID, OAuth, and UMA world. They do need more participation from healthcare, it is hard to give everyone that needs attention the full attention they need. HEART has some foundational profiles ready to be used
HEART profiles for review, comment, and approval .
So the next thing up for discussion is a set of OAuth 'scope' values. A 'scope' is a way for an App to ask for less rights than the user holds, and is a good way to limit the damage that an App can do. So the question really is in what ways would it be appropriate to cut away rights that a user might hold.
The is something that has not yet been discussed in any useful detail inside of HEART. In fact the specification they have "FHIR OAuth 2 " is not open for review, yet. This specification is mostly derived from what SMART supports today. It is made up of a set of strings that represent a few FHIR resources. It is not a complete list of FHIR resource types. This list was simply an initial attempt at coming up with a set of scope values. The list is a logical thing that someone would create given simply that FHIR is based on REST. Meaning this is a typical list for any ‘normal’ RESTful api.
Sensitivity
This focus on FHIR resource types has the problem that in healthcare it is not the type of resource that differentiates between access allowed vs access denied. There are some FHIR resources that typically just carry data, Such as Organization, HealthServices, Location, Device, ValueSet, Conformance, etc. These resources don't carry varying sensitive information.
However Resources like CarePlan, Medication, Observation, DiagnosticReport, and others carry data that can vary widely on how sensitive it is.
Normal is normal for Healthcare data
These Resources might be carrying what most people consider "Normal" healthcare information. Note that the word "Normal" is relative to all healthcare information, not a label relative to all information. Healthcare information, even Normal, is considered "High Risk:" overall.
Beyond Normal
There are sensitive health topics: HIV status, drug abuse,
Finding Normal
sensitivity evaluation along a vector
What I am looking for is a way of saying "I want to be using data that is Normal or less". The _confidentiality codes are defined specifically to be a scale of not sensitive, to less sensitive, to normal, to high sensitive, to too hot to handle. This was an explicit exercise and was done in concert with ISO 13606 so that we would have a linear assessment of risk.Purpose Of Use
We often focus too much on treatment workflows. Where there are many other reasons why people, applications, or services might want access to the healthcare data. This is represented by the Purpose Of Use, using the PurposeOfUse vocabulary as a starting point. This allows for the normal "Treatment", or "Billing" but also includes in the vector marketing, legal, public health reporting, eligibility, etc.
the REST
I don't mind including the classic REST viewpoint. I just don't think it is sufficient. So I would include the ability to limit the scope based on the REST operators and the FHIR Resource types.
Proposal (for discussion)
purposeOfUse “:” _confidentiality “:” resource “:” action “:” Patient
Where:
Where:
- purposeOfUse -- value from the PurposeOfUse vocabulary
- _confidentiality -- highest value from the _confidential vocabulary
- resource -- FHIR resource type from the resource-types value-set
- action -- RESTful verb (CRUDE) from the restful-interactions value-set
- Patient -- URI to the Patient resource identifying a specific patient
- where any can be “*” to indicate not requesting a constraint.
Further note that multiple scopes can be indicated with a "," separator.
Further note that the authorization server can downgrade even more the scopes that were asked to the scopes that were granted. The OAuth specification doesn't explain how this is done, just that it is allowed. One example would be where the authorization server knows the app by identity, and thus restricts scopes.
Break-Glass use-case
This proposal sets up one model to support ‘break-glass’ by first asking for "Normal" data, but when a break-glass justification exists then asking for “Restricted”. I know I need to explain this more, but this is not the topic of this blog post.
Privacy Consent Directive
I expect that a Privacy Consent Directive
might also be a useful vector through the Scope. That an app could say
they only want the access rights granted to the user through a specific Privacy Consent Directive. This might be especially useful when the patient can actively grant one-by-one authorizations.
I didn't include this in the proposal because there is active work on FHIR Privacy Consent Directives, and equally interesting HEART efforts to leverage UMA.
Conclusion
This is in no-way a conclusion, but a proposal for discussion.
No comments:
Post a Comment