Stream: implementers
Topic: linking users to practititioners and practitioner roles
santiago gil (Nov 14 2018 at 19:15):
hello there, I have a couple of questions for you guys. I am fairly new to fhir and wanted to see if you could help me with some questions:
Does the practitionerRole fhir object dictate the rights and roles a particular user have? if so, how how does it? does a practitioner have multiple practitioner role records in the same organization? or does he have multiple practitioner roles scattered throughout multiple organizations.
I am very confused as to what to tie a policy to. Policy as in a set of actions a user can do on a system. because i see practitioner roles in the fhir spec and it seems like policies should be tied to that.
and more importantly, what dictates where the practitioner works? the practitioner role right?
Lloyd McKenzie (Nov 14 2018 at 19:35):
PractitionerRole is not the same as "user". A user might be a PractitionerRole, Patient or RelatedPerson. FHIR doesn't currently have any resources to support user management (e.g. user, privilege, privilege group, etc.)
santiago gil (Nov 14 2018 at 19:38):
so if i wanted to link a practitioner to a user management system, it would be best to store the connection in the user management system?
Lloyd McKenzie (Nov 14 2018 at 19:39):
Yes. Though you could use an extension on the relevant resources if you needed to do it the other way.
Lloyd McKenzie (Nov 14 2018 at 19:39):
There's a RESTful user management standard we usually recommend but its name escapes me at the moment. @Grahame Grieve ?
santiago gil (Nov 14 2018 at 19:44):
oh man that would be awesome.
John Moehrke (Nov 14 2018 at 20:35):
Practitioner.identifier can hold the user id... why is that not the solution?
Lloyd McKenzie (Nov 14 2018 at 20:42):
It's harder to manage that from an access control perspective Easier to control it if it's a separate extension.
John Moehrke (Nov 14 2018 at 20:44):
I don't agree. The .identifier element is very logical to hold the userID. I could certainly understand the logic that says that the IDM is the more authorative source of mapping from user to other identifiers. But that is a policy answer. not an ease of implementation.
John Moehrke (Nov 14 2018 at 20:51):
The RESTful standard for User Management is System for Cross-domain Identity Management (SCIM) -- https://tools.ietf.org/html/rfc7642
John Moehrke (Nov 14 2018 at 20:51):
right?
Lloyd McKenzie (Nov 14 2018 at 20:55):
Yes, that's what I was thinking of. Thanks @John Moehrke
John Moehrke (Nov 14 2018 at 20:56):
so, we likely should add some mention of this on the security pages...
Grahame Grieve (Nov 15 2018 at 02:28):
in my implementation of SCIM. I store the reference to the practitioner as an extension in the SCIM user object, because my analysis is that there might be multiple user accounts for a single practitioner, but I cannot see why there would be multiple practitioners for a single user account
Veliyan Georgiev (Nov 15 2018 at 08:08):
I second Lloyd. It also fits nicely with the way you do SSO with both Epic and Cerner in example. Their own recommendation when using external identity management system is to provision them and then store their username into your identity store. Epic doesn’t have SCIM but Cerner does
John Moehrke (Nov 15 2018 at 16:05):
Can one of you submit a CR to add a FAQ to the security-privacy module page? Help me craft the language that you would be looking for, and minimal text that would send you in the right direction.. I think the text should discuss this directionality point of identifier cross-referencing. As well as recommend SCIM as an potential solution for user account management. The identifier topic is useful regardless of if you use SCIM or use a stack specific IDM.
Last updated: Apr 12 2022 at 19:14 UTC
