Stream: argonaut
Topic: PractitionerRole.specialty
Nick George (Aug 09 2019 at 00:26):
Hello - why does Us Core PractitionerRole limit specialty to cardinality 1..1? it's 0..* in base resource
Nick George (Aug 09 2019 at 00:27):
the description also says it must have "A list of specialities"
Lloyd McKenzie (Aug 09 2019 at 00:54):
Difference between the "PractitionerRole as a generic registry function" vs. "PractitionerRole as a means of identifying exactly what hat someone was wearing when they did a specific thing". Typically, most systems require you to identify exactly one 'hat' that determines what privileges/authorities you have when performing an action - even though a registry might have knowledge that you have multiple hats available. It would be good though if the US-core PractitionerRole profile made clear that its scope excluded registry uses.
Lloyd McKenzie (Aug 09 2019 at 00:54):
@Brett Marquard @Eric Haas ?
Eric Haas (Aug 09 2019 at 01:06):
it is scoped to include registries. See Argo PD....
Eric Haas (Aug 09 2019 at 01:11):
I will let Brett chime in but I think a tracker to relax to 0.* with a note that is typically 1 for an actor would be reasonable.
Lloyd McKenzie (Aug 09 2019 at 01:52):
I'd prefer separate profiles for each use.
Eric Haas (Aug 09 2019 at 02:35):
One of our design goals is too have a single minimal profile to meet the broadest range of use cases possible.
Brett Marquard (Aug 09 2019 at 10:53):
Correct. It supports both use cases
Lloyd McKenzie (Aug 09 2019 at 16:03):
@Brett Marquard Should it? The needs when you're trying to identify and provide basic information about a Practitioner who did something (or you want to do something) is rather different than the rules you'd have for describing everything you know about the practitioner.
Brett Marquard (Aug 09 2019 at 16:04):
sure, but don't you think it reasonable to have a base beneath both?
Lloyd McKenzie (Aug 09 2019 at 16:06):
Maybe. The question is whether having separate profiles would be more useful.
Brett Marquard (Aug 09 2019 at 16:09):
feedback on PractitionerRole for Data Query access has been limited...it's unclear how many systems have actually implemented. The majority of requirements (which have been loosened) were driven by provider directory effort a few years back.
Brett Marquard (Aug 09 2019 at 16:10):
so I agreed with your maybe, but it hasn't been a focus this cycle.
Nick George (Aug 09 2019 at 17:10):
The documentation seems to suggest the profile is for what roles the practitioner _could_ play
Nick George (Aug 09 2019 at 17:12):
It seems if we're trying to have a single profile for both use cases we'd need 1..*
Gabriela Espinosa (Aug 09 2019 at 17:19):
hi there, we have seen use cases for PractitionerRole where we see a need for more than one specialty. It is common for instance to see a role of "referring provider" from a provider with more than one specialty. The source for this data does not really specify a specialty per role necessarily. So I believe some flexibility on the cardinality would be very useful as we currently need to randomly use one of the listed specialties for a given role. Or is there a better way of capturing this?
Eric Haas (Aug 09 2019 at 18:50):
In us core we make things min =1 only after lots of consultation. We mostly use min = 0 + must support as a send it if you have it. These are vendor lead requirements.
Nick George (Aug 09 2019 at 20:30):
the min 0 makes sense to me, it's the max 1 that we're asking about
Nick George (Aug 09 2019 at 20:30):
erhm sorry, min 1
Nick George (Aug 09 2019 at 20:31):
bah, confusing wording - min 1 makes sense, max 1 is our question
Eric Haas (Aug 09 2019 at 21:13):
Can make a tracker to us core? Same as making a tracker to FHIR. Just change the specification field to us core.
Last updated: Apr 12 2022 at 19:14 UTC
