Stream: implementers
Topic: PractitionerRole
Michael Donnelly (May 10 2016 at 14:17):
What's the argument for breaking PractitionerRole out into its own resource?
Lloyd McKenzie (May 10 2016 at 20:24):
@Brian Postlethwaite, this one's for you :)
Michael Donnelly (May 10 2016 at 20:28):
Thanks @Lloyd McKenzie :). @Brian Postlethwaite , I was there for discussion about this in January, but in my notes I only recorded lower level details about what would link where and not the high level reasoning for it, and my memory isn't up to the task.
Ewout Kramer (May 19 2016 at 09:42):
@Brian Postlethwaite is currently enjoying New York City with his wife, we'll have to wait for this cliffhanger to be continued in the next episode...
Alexander Hoermandinger (Apr 18 2017 at 14:21):
Hi all,
we are currently upgrading our application codebase from DSTU2 to STU3.
One model change we stumbled upon was the fact that the PractitionerRole is now a resource on it's own.
What is puzzling me is the fact that the Practitioner does not have a reference to PractitionerRole (while the PractitionerRole does have a reference to Practitioner) Does anybody know the reason for that?
John Moehrke (Apr 18 2017 at 14:36):
Yes. All RESTful references are always from the resource that is more likely to be created later towards the resource that was more likely to have existed first. All references are only one direction, because one can always query for reference values...
Oliver (Nov 07 2018 at 19:20):
(deleted)
Grahame Grieve (Sep 04 2019 at 01:25):
@Cooper Thompson @Brian Postlethwaite I'm not sure that I understand PractitionerRole right. Can I / Should I use PractitionerRole when I'm referring to something being done 'by the admitting officer' when I have no idea who that was/will be?
More generally, the Boundaries/Relationships section should have a very explicit section discussing Practitioner vs PractitionerRole. I feel as though this is underdone
Further, the pattern Reference(Practitioner | PractitionerRole) pattern.... I'm not comfortable describing the rationale for and use of this pattern... have I missed an explanation somewhere in the specification?
Craig Newman (Sep 04 2019 at 17:11):
GF#20635 was approved by PA to make some improvements to the PractitionerRole description. Check that out and see if that helps clarify things.
Grahame Grieve (Sep 04 2019 at 20:44):
well, it moves things (thanks) but I cannot say that it clarifies things.
Many resource types have a choice of a reference to either a Practitioner resource or a PractitionerRole resource. The latter provides organizational context for the practitioners participation when it is required, otherwise a direct reference to the practitioner may be used.
Is providing an organizational context really worth splitting into 2 different resources?
And the task doesn't help me understand whether the intent is that you can refer to a role that does not have a known identified person who did/will do it
Lloyd McKenzie (Sep 05 2019 at 20:36):
My understanding is as follows:
- (some) registries manage practitioners independent of who they're working for or what hat they wear. They just care about demographics. E.g. Dr. John Smith has a medical degree from XYZ university and is licensed in states A and B.
- Those registries may also track more detailed information about where Dr. Smith works and in what capacities. E.g. Surgeon at hospital 1, chief of cardiology at hospital 2 and GP and clinic 3
- the latter information has its own status and sometimes its own source of truth
- the original model was Practitioner = 1 person, one organization, one hat. But that didn't align nicely for the registries that wanted to maintain hat-independent data (and apparently Person didn't work because it didn't deal with qualifications)
- that got split to Practitioner = 1 person and a whole bunch of roles and organizations; but that broke the referencing model and caused us to have to identify which org + which hat every time we pointed to a practitioner because the practitioner was now ambiguous
- the solution was to split the roles out as separate resources so you could point to a particular hat or you could point to a practitioner independent of hat, depending on need
- And yes, you can also have PractitionerRoles that specify organization + hat, but not Practitioner. E.g. Surgeon at XYZ hospital.
Grahame Grieve (Sep 06 2019 at 20:37):
maybe it's just me, but it still feels like Reference(Practitioner | PractitionerRole) is a less than optimal solution to this. I feel like it should be possible to come up with a better approach...
Lloyd McKenzie (Sep 06 2019 at 21:48):
I wasn't expressing my enthusiasm for the status quo, jut my understanding of the path to the current state. Personally, I liked the STU 2 solution where Practitioner was always Organization & Role specific. But that - in part - is because I'm not a heavy user of registries. I'm not totally sure why Person wasn't deemed to be a solution to the shared demographics & expertise bit. @Irma Jongeneel do you have further insights into PA's discussions here?
Jean Duteau (Sep 07 2019 at 00:55):
maybe it's just me, but it still feels like Reference(Practitioner | PractitionerRole) is a less than optimal solution to this. I feel like it should be possible to come up with a better approach...
I agree. I have an open tracker item about this: GF#21166.
We got told in Pharmacy that we needed to have PractitionerRole because we had Practitioner. The rationale was "If it is important enough to make it known that a Practitioner picked up meds, then it must be relevant in what capacity this Practitioner was acting. For that you need access to PractitionerRole."
If I buy that rationale, and I'm not sure that I do, then why on earth do we have a separate resource?
Jean Duteau (Sep 07 2019 at 00:59):
I'll note that your item GF#22112 is also symptomatic of this weird split.
Grahame Grieve (Sep 07 2019 at 02:48):
right. We're not making sense here. We need to cover 3 things
- this person did (usually in some implied role) (or will/should do it)
- this person in this role did it (or will/should do it)
- some one in this role did it (or will/should do it)
If we think the current arrangement doesn't make sense.... can we fix it? Do we need a break out during the connectathon? a WGM quarter? both?
Lloyd McKenzie (Sep 07 2019 at 03:20):
We also need to support the registry use-cases - that's what drove the current arrangement.
Grahame Grieve (Sep 07 2019 at 03:21):
ok. and those are?
Grahame Grieve (Sep 07 2019 at 03:21):
- this person
- this person works here
Lloyd McKenzie (Sep 07 2019 at 03:23):
this person (with these qualifications)
this person works here (in this capacity)
Jean Duteau (Sep 07 2019 at 04:21):
We also need to support the registry use-cases - that's what drove the current arrangement.
Why can't a set of qualifications be optional as well as a set of roles?
Or create a RegistryPractitioner since it seems that the way more common use case for Practitioner is to be used in clinical resources?
Lloyd McKenzie (Sep 07 2019 at 04:28):
We don't want multiple roles on a resource as that breaks referencing. Splitting into RegistryPractitioner is certainly a possible outcome, though our preference is single context-independent resources where possible.
Grahame Grieve (Sep 07 2019 at 04:33):
We don't want multiple roles on a resource as that breaks referencing.
I don't know what that means
Lloyd McKenzie (Sep 07 2019 at 04:38):
If we had a practitioner resource that had multiple roles on it, it would be useless for referencing in a role-specific way
Lloyd McKenzie (Sep 07 2019 at 04:39):
Though I suppose we could do something funky like [base]/practitioner/123#rolea if the roles had ids...
Jean Duteau (Sep 07 2019 at 04:40):
Or put the role on the referencing resource, if it is really that important.
Jean Duteau (Sep 07 2019 at 04:41):
If we think the current arrangement doesn't make sense.... can we fix it? Do we need a break out during the connectathon? a WGM quarter? both?
I would agree to a breakout. I would hope it wouldn't be during the connectathon because I couldn't make it. But if it had to be there, I have trust that Grahame could represent my concerns (since they seem to be the same as his).
Grahame Grieve (Sep 07 2019 at 04:55):
well, breakouts are informal; they can only lead to recommendations for committees
Lloyd McKenzie (Sep 07 2019 at 05:09):
We don't like putting the role (and/or organization) on the referencing resource. We had that in STU3 and everyone hated it.
Michele Mottini (Sep 09 2019 at 14:51):
We do not have something like PractitionerRole in our database, but our Practitioner concept has a type - that in DSTU2 we mapped to practitionerRole.role. In STU3 and R4 there is nothing similar so we had to invent an extension
So maybe re-introduce some of those extra elements in Practitioner - or add extensions for them?
Last updated: Apr 12 2022 at 19:14 UTC
