Stream: cds hooks
Topic: Adding PractitionerRole to userid options
Lloyd McKenzie (Mar 06 2019 at 19:45):
Also, I'd like to update the hooks that currently expose userid as a parameter to indicate that PractitionerRole is a permitted option for userid. (In practice I expect PractitionerRole to be more common that Practitioner for STU3 and R4 where it's available because userids will typically be associated with a specific role, not just with a practitioner in general independent of hat and organization.)
Lloyd McKenzie (Mar 06 2019 at 19:46):
Is that an appropriate thing to just submit a pull request for as well?
Isaac Vetter (Mar 06 2019 at 19:55):
Yes, I think so. Should we also get SMART's fhirUser updated?
Lloyd McKenzie (Mar 06 2019 at 20:08):
I don't know what the process would be for doing that...
Brian Postlethwaite (Mar 06 2019 at 20:38):
Umm. Not sure I agree. Roles are like user groups, not user ids. Unless it's for defaulting data in, and not used in the result of authentication.
Is the smart app expected to also ask which org/location they are in context of for the session when they can have multiple? (eg which role they are performing)
Lloyd McKenzie (Mar 06 2019 at 20:45):
I understand the challenge of using PractitionerRole, Practitioner, Patient and RelatedPerson as "userids". My point is that PractitionerRole is more likely to be tied to a userid than Practitioner. PractitionerRole is specific to a particular Practitioner, but adds in the context of what organization they're working for and what hat they're wearing.
John Moehrke (Mar 06 2019 at 21:55):
userid would be a business identifier that very likely will appear in the .identifier of those FHIR Resources. I don't think looking at this the other way around is proper. These are the kinds of reasons I have struggled to keep these independent. This said, I am not against including the PractitionerRole as informative reference in the request/token; I just urge that the formal identifier is userid, and formal roles are specified.
Lloyd McKenzie (Mar 06 2019 at 22:35):
Right now, the 'userid' property is expressed as a string of the form "[resource type]/[id]". I.e. the same syntax we used for a local resource reference. The 'expected' resource types are enumerated and vary by type or request. We can debate whether that's a good/not good thing to do. However that's a different question from whether if we retain the approach whether PractitionerRole should be an option in addition to Practitioner
Brian Postlethwaite (Mar 06 2019 at 22:50):
Or include both as options... Just like encounter adds more context than patient.
Brian Postlethwaite (Mar 06 2019 at 22:50):
That I would feel better about.
Lloyd McKenzie (Mar 06 2019 at 23:00):
If you've got a PractitionerRole id, the Practitioner id would be known from the PractitionerRole.
Lloyd McKenzie (Mar 06 2019 at 23:00):
It wouldn't be appropriate to use PractitionerRole as a user id if it wasn't bound to a specific Practitioner.
John Moehrke (Mar 07 2019 at 13:26):
Or include both as options... Just like encounter adds more context than patient.
yes, that is my recommendation
John Moehrke (Mar 07 2019 at 13:27):
It wouldn't be appropriate to use PractitionerRole as a user id if it wasn't bound to a specific Practitioner.
yes, and there are many user/roles that would never be put into a PractitionerRole
Last updated: Apr 12 2022 at 19:14 UTC
