Healthcare is rushing toward using RESTful specifications of healthcare objects. The prime defining is being done by HL7 FHIR. Something I am very actively involved in. Protecting these resources, Security and Privacy, is looking to use OAuth given some of it's advantages over other systems. The IHE IUA profile defines how an OAuth token would carry additional attributes to enable server side access control decisions. What the profile does not include is how the scope is set inside the OAuth token.
A scope constraint is a common concept in OAuth and SAML, that is that the token is issued only for a specific subset of information. This subset of information is the 'scope'.
For example how does one request a token for just patient "John Moehrke". This is likely to be more implementation dependent than IHE can profile. Meaning that there might be a different way to do this for FHIR, DICOM, Continua, and others. Because the resources are slightly different. For example the link "John Moehrke" is a URL that could be considered a scope restriction to information about the identity pointed to. But this URL is specific to Google+, and may not be the same URL as "John Moehrke" in the context of Twitter.
Note this example is not pointing toward any specific rule, just pointing toward the identity of the patient for which the requester wants to have access to. The OAuth service makes the decision on if this is a legitimate and authorized scope. If the user has access rights to that scope, then that scope would be included in the OAuth token. If the user does not have the access rights to that scope, then the token is not issued. So this discussion is not about making the decision, it is about how does one describe the scope that you are willing to be constrained to, in a consistent and interoperable way.
Interesting scope concept that Josh Mandel speaks about in his pilot implementation at the FHIR connectathon. Specific comment from Josh at 5:53 in the overall connectathon report-out-video. -- Put the FHIR URL that identifies the specific Patient you are asking about, thus any queries using that token will be constrained by the Resource service to that specific Patient records. For example the OAuth token scope on that patient would be seen as an implied patient query parameter (regardless of the query parameters provided).
This would be too specific for IHE IUA profile, but would be a very useful FHIR profile of the IHE IUA profile. Note this could certainly be done just as well with SAML (aka the IHE-XUA profile).
Access Control (Consent enforcement)
- Advanced Access Controls to support sensitive health topics
- Policy Enforcing XDS Registry
- Healthcare Metadata
- Texas HIE Consent Management System Design
- IHE - Privacy and Security Profiles - Access Control
- Data Classification - a key vector enabling rich Security and Privacy controls
- Healthcare Access Controls standards landscape
- Handling the obligation to prohibit Re-disclosure
- Access Controls: Policies --> Attributes --> Implementation
- IHE - Privacy and Security Profiles - Document Encryption
No comments:
Post a Comment