Stream: implementers
Topic: Access control HIE
Tobias Blomberg (Feb 26 2020 at 09:43):
Hi all,
I’m rather new to FHIR but I’m working on a Swedish project regarding access control for health information exchange and I’m trying to crack a difficult problem.
As of today, the access control is set up as a task-role based access control model where every actor is assigned one or more role, each role with a number of tasks attached to it which defines the activity (read, sign, etc), information type (diagnosis, etc), scope and purpose. The information types map one-to-one to service contracts that specify how data is to be structured for exchange. As seems to be the common practice, the access control list is stored in a separate catalog that is called whenever an actor requests to take part of information regarding a patient.
The patient data protection law in Sweden (as in many other countries) states that an actor may only take part of the amount of data regarding a given patient that is necessary to provide needed care. The issue I see here is that the required amount of data should only be able to be determined retrospectively. Does anyone know of a solution for access control compatible with FHIR, that is more flexible? Perhaps one that determines if an actor has access to a resource from case to case? Maybe the policy information point is local?
Also, if it is so that access level has to be assigned before any action in a system; if care providers create their own FHIR profiles, how can these be called for when other providers have different profiles? Attribute-based access control?
I would be very grateful if anybody has any insights on this!
Tobias Blomberg
Jens Villadsen (Feb 26 2020 at 09:45):
This is what we are doing in Denmark in our upcoming national FHIR setup. Clinicians have different roles in each careteam they work in and can only access data where their careteam is listed as a participant. In that sense we use both RBAC and ABAC. See for yourself at https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/7045392/Security
Tobias Blomberg (Feb 26 2020 at 10:01):
@Jens Villadsen
Thank you for your response!
I looked through the documentation briefly and it seems rather similar to the solution in Sweden. Is it only the care team/organization that is selected in "real-time"? The roles are assigned ahead of time, for example when an actor is hired, if I understand it correctly? And this data is stored separately from the client HIS and the resource HIS?
Jens Villadsen (Feb 26 2020 at 10:02):
Totally correctly understood
Jens Villadsen (Feb 26 2020 at 10:03):
the available careteams are switched realtime, yes
Jens Villadsen (Feb 26 2020 at 10:03):
and as such, your roles and your access to data
Jens Villadsen (Feb 26 2020 at 10:04):
This allows the regional and municipal IdP's to control what careteams and roles you are allowed to switch to
Jens Villadsen (Feb 26 2020 at 10:05):
this setup is pretty new stuff in DK - we are heading into production the next couple of months nationwide
Tobias Blomberg (Feb 26 2020 at 10:10):
Exciting! Thank you for this. I will look through the documentation you sent!
We are in need of an upgraded solution here since the solution we have today is based on service contracts that are not granular enough to be supported by law. This means there are large parts of data that can not be shared between providers since there is no way to ensure that too much data is not sent. And as we are on it, it makes sense to make it compatible with FHIR. Thanks again for sharing!
John Moehrke (Feb 26 2020 at 13:37):
excellent, I would like to see some of this get captured. I would support putting a short explanation on the security pages. I would far prefer that this be worked up into an Implementation Guide that others can learn from and choose to adopt.
John Moehrke (Feb 26 2020 at 13:41):
Note that it is common for clinicians and treatment purpose to be more focused on policy and less on technical controls. That is to say that there is clear policy as indicated, you can't take more than you need, but in these cases no technology is put in place to forbid the taking by clinicians under treatment. This works WHEN there is a strong audit system in place, where by retrospective analysis of actual use of data can be measured against the policy, and abuse is handled administratively. This model leverages that these clinicians are professional people who are given a very high level of trust by the community and organizations, and an understanding that treatment purpose has a high likelihood of having mistakes result in pain or death. Thus favoring professional code of conduct and safety.
John Moehrke (Feb 26 2020 at 13:46):
I am not saying this is the only solution, just responding with how this is handled today.... This liberal policy is not a good policy beyond treatment (where safety is a concern) and outside of clinicians (broad definition). Thus when the dietitian wants to be sure the meal they are sending up to the room is proper, they only have access to that which dietitian is allowed (still not an easy boundary to define, but some bright lines exist). etc...
Tobias Blomberg (Feb 26 2020 at 13:49):
This is the reasoning I have done, too. I am currently having a discussion with our Swedish agency in charge of enforcing the patient data protection laws.
As of today, the developers of the national IT architecture have interpreted the law so that there needs to be a technical boundary for accessing data, however, I'm not sure this is entirely true. Either way, until specifically informed that an audit system would be sufficient, I'm working under the assumption that it is not.
Do you happen to have any resources for what components a strong audit system would need?
John Moehrke (Feb 26 2020 at 14:19):
a strong audit system is what the standards define that the FHIR AuditEvent is based upon. http://build.fhir.org/auditevent.html#scope
John Moehrke (Feb 26 2020 at 14:20):
and outlined on the security pages http://build.fhir.org/secpriv-module.html#audit
Tobias Blomberg (Feb 26 2020 at 14:21):
Thank you!! I really appreciate it!
John Moehrke (Feb 26 2020 at 14:24):
I very much encourage better than this... One vector to define well is a legitimate relationship, does this user who is a clinician have a legitimate relationship with that patient... Maintaining this is not easy, but CareTeam is a good resource to focus on for that (there are others) Often these legitimate relationship need to have a way to override (break-glass, in this case a self-assignment to the team with audit logs and alerts to privacy/safety office)
Jose Costa Teixeira (Feb 26 2020 at 14:28):
in Belgium we are eliciting our requirements. would be good to align somehow the several ongoing discussions and solutions
Jose Costa Teixeira (Feb 26 2020 at 14:28):
we are also considering using careTam for access control btw
Jens Villadsen (Feb 26 2020 at 18:08):
We run a full async auditevent setup behind the scenes - which also get forwarded to the national audit service
Jens Villadsen (Feb 27 2020 at 08:31):
@John Moehrke - we deliberately chose to put the security information on the wiki site whereas the interfaces are documented on https://docs.ehealth.sundhed.dk/latest/ig/index.html - so some information is on the IG, some is on the wiki
John Moehrke (Feb 27 2020 at 13:46):
so I would like to have a library of various security/privacy solutions (Ill call them Implementation Guides), that would help a new person/organization learn from others experience. If this library was viewed as a simply a listing, without endorsement or rating of the solutions in the library, then I think it could be easy to manage... right? I know I don't have time to spend evaluating everyones solutions. I do expect that out of this library will be some re-usable solutions, it would be good if the community itself helped to distill out these gems. Is that possible?
John Moehrke (Feb 27 2020 at 13:47):
Looking at your security page https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/7045392/Security
It is very readable and mostly self contained. It does sit within an important context setting (the other three documents).
Last updated: Apr 12 2022 at 19:14 UTC
