Stream: Security and Privacy
Topic: Claims
Ivan May (Aug 11 2020 at 12:27):
Hi All
Just to add a little bit of background. I have a requirement to load multiple organizations data onto a single FHIR instance. Loading the organizations and their unique identifiers is relatively simple based on the provided documentation. The only caveat is that not all organizations can access all other organizations' data. I have an external authentication and authorization service that I use to manage access to the fhir integration.
So the process that we will follow is that a client will get a client id and secret that will be exchanged for a short lived access token (oauth2). The access token will be of type JWT with scope claims including allowed organizations, etc. When a resource is then requested, the claims will filter out results the user is not allowed to see.
From what I understand the security labels in the FHIR specification is to be used to filter out data that is not allowed to be seen by the requesting user.
That all being said. The way I wanted to implement this, was to add an "organization" claim to the jwt token, which is the primary organization the user belongs to. When that user then submits a resource, that organization claim is then stored under the security label on the resource. So when another resource then requests access to the resource, that user will need to have the relevant organization as part of his scope claim to access the details.
I also have a question around the Provenance and audit requirements. Is this a hard requirement that this information is stored in the FHIR server?
Would this be a correct approach to solve the authorization problem? I hope this is enough information. I used the information provided here: https://smilecdr.com/docs/security/smart_on_fhir_introduction.html and here: https://www.hl7.org/fhir/security.html
Joel Schneider (Aug 11 2020 at 14:10):
For reference, a similar use case involving security labels was discussed here:
https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy/topic/clinical.20outcomes.20registry.20data.20access.20control.20use.20case
John Moehrke (Aug 12 2020 at 12:29):
@Ivan May What you are describing is one of the use-case solutions that I speak to in my HL7 Tutorial on Security and Privacy. The slide deck is available, and was updated a few months ago when I gave the tutorial virtually. https://healthcaresecprivacy.blogspot.com/2019/12/sydney-hl7-fhir-privacy-and-security.html
John Moehrke (Aug 12 2020 at 12:31):
What you are describing is using the .meta.security to hold a compartment value(s) of the organizations that have Create/Update/Delete rights. See the slides starting at 53 and 57. Two alternatives. The one you chose enables multi-ownership.
John Moehrke (Aug 12 2020 at 12:34):
To your audit question... audit logs will be essential, as accidents will happen and someone will need to figure out how that accident happened. Does it need to be in FHIR AuditEvent? No, it only needs to meet your organizational needs. The AuditEvent is modeled in FHIR to enable more rich audit logging. You might be able to use the raw database logs. They are harder to analyze, but they are easier to implement.
Ivan May (Aug 12 2020 at 17:54):
Thank you for the advice! I will be online again tomorrow morning to go through the info! Will post if I have any more questions.
Ivan May (Aug 13 2020 at 08:29):
@John Moehrke if I understand that correctly, I would put a scope claim into the metadata of the resource? So this would contain a organization ids and the allowed scopes. For example: read, update, delete.
Ivan May (Aug 13 2020 at 09:04):
Also @John Moehrke you dont have a video of the talk you gave somewhere? That would also be super helpful
John Moehrke (Aug 13 2020 at 12:37):
HL7 does have the recording of the tutorial https://www.pathlms.com/hl7/courses/22130
John Moehrke (Aug 13 2020 at 12:40):
There are two different models described in my tutorial. The first one relies on relationships to enable WRITE access, else everyone has READ. The second uses a tag in .meta.security to indicate the compartment that would have WRITE access, else everyone has READ.
Last updated: Apr 12 2022 at 19:14 UTC
