Stream: implementers
Topic: Participants: Reference(Organization) vs Reference(Practi...
Josh Mandel (May 24 2021 at 19:46):
Is there a modeling principle at work here?
Immunization.performer.actorallows Reference(Practitioner | PractitionerRole | Organization)Condition.asserterallows Reference(Practitioner | PractitionerRole | Patient | RelatedPerson | Device)
... is there an underlying reason for these differences and other, when all point back to http://build.fhir.org/participant.html#Participant as a basis for design?
Grahame Grieve (May 24 2021 at 23:09):
because the build points back; the committees don't, but the purpose of the build is to encourage the committees to consider the standardisation
However I think I asked this; the argument was the immunizations are special and can't be performed by patients on themselves, or by related persons to them, and that devices also do not perform them (they may be used).
I think that it's wrong domain analysis, but I'm not the expert. However this is a domain analysis question, not a design methodology issue
Josh Mandel (May 25 2021 at 00:21):
In this case I wasn't actually thinking about Patients, but rather about Organizations. FHIR currently allows us to say that an organization performed or at least acted in an immunization but not to say that an organization asserted or recorded a condition.
Josh Mandel (May 25 2021 at 00:23):
From a methodological perspective, it might be good for us to think about pointing to a pattern and specifically documenting any deviations, so if you are excluding a member of the pattern or including something that's not part of the pattern, you would explain why. I understand this may be too high a bar; just thinking about how to drive more consistency and clarity of documentation.
Lloyd McKenzie (May 25 2021 at 01:11):
I think complaining about the inability of an Organization to be an asserter is reasonable. Sometimes all you know it "Payer XYZ told me this happened". And that's still better than nothing.
Eric Haas (May 25 2021 at 01:42):
my clients give vaccines all the time
Josh Mandel (May 25 2021 at 02:30):
+1 to both points. I can file an issue on these; is there any broader methodological step we should be taking along the lines I mentioned above?
Grahame Grieve (May 25 2021 at 08:42):
no. I don't think so. The point of the pattern work is to make the committees think about this
Lloyd McKenzie (May 25 2021 at 09:27):
Methodology shift would be to remind people that when choosing alternatives for resource targets, the 80% rule doesn't apply. I.e. once you decide a reference is 'in' from an 80%, you should allow all targets that are 'reasonable', even if some aren't currently super-common.
Josh Mandel (May 25 2021 at 15:40):
The point of the pattern work is to make the committees think about this
You mean, making them document their thought process is out of scope for the pattern methodology @Grahame Grieve? (I'm OK with this, just want to make sure I understand where you're drawing the distinction.)
Grahame Grieve (May 25 2021 at 15:40):
I would love them to document, but I live in the real world ;-)
Josh Mandel (May 25 2021 at 15:46):
Added:
for the specific missing participants here; won't propose any methodological changes at this time.
Paul Denning (May 25 2021 at 21:03):
I added comments to those Jira issues to also consider using CoedeableReference
Josh Mandel (May 25 2021 at 21:31):
I'm not sure I follow -- what kind of "CodeableConcept" would be available for a person or organization? Are you thinking like an identifier? We already have Reference.identifier when this is known @Paul Denning .
Lloyd McKenzie (May 25 2021 at 22:28):
You might just have "asserted by a 'payer'" - i.e. you're capturing the type of organization or type of provider, but not specifically who.
Josh Mandel (May 25 2021 at 23:42):
Hmm. I'm not sure that's consistent with how we use CodeableReferences elsewhere, and I'm not sure it's what Paul has in mind.
Lloyd McKenzie (May 25 2021 at 23:53):
That's true, actually. Perhaps CodeableReference should only be allowed for resources that are primarily identified by their code (e.g. Medication, Substance, etc.) Thoughts @Grahame Grieve?
Grahame Grieve (May 26 2021 at 00:15):
Well, you could argue that the pattern is similar - a particular clinician or 'my immunologist'
But the CodeableReference pattern really applies when the resource being referred to an effectively an instantiation of the reference grammar behind the coding system. E.g. you can turn RxNorm codes into Medication Resources, and so you can see 'an RxNorm code' or 'a Medication resource' as functionally interchangeable
That's not some thing that applies here - a Practitioner is not an instantiation of the logical model of 'a kind of practitioner', instead, you would be using the codeable part as a short cut to the one attribute of the referenced type that might substitute. We could document that as a pattern variant, one we allow for purposes of operational efficiency, but we'd have to be sure that wit was obvious which attribute was intended.
So in this case, there's both a methodological question and domain questions: is just referencing a type of practitioner a meaningful thing? @Paul Denning hasn't provided actual use cases or business analysis
Last updated: Apr 12 2022 at 19:14 UTC
