Stream: argonaut
Topic: fhir-28392: Encoutner.serviceProvider instead of location?
Eric Haas (Oct 28 2020 at 22:46):
J#28392 Commenter proposed that Encoutner.serviceProvider is of more value instead of location? Seeking feedback here
Michele Mottini (Oct 28 2020 at 22:56):
:-1: we do not have that data - we have locations and participants
Reece Adamson (Nov 20 2020 at 16:08):
I know its a little late to provide comments on this issue after its resolution (sorry!), but I'm interested in how the proposed solution voted on yesterday relates to the base FHIR definition of MustSupport.
Make both serviceProvider (US Core Organization) and Location Must Support and include text that you may have both but Must Support one or the other. Add clarifying sentence about location address.
FHIR R4 Must Support Definition (emphasis mine):
Labeling an element MustSupport means that implementations that produce or consume resources SHALL provide "support" for the element in some meaningful way.
Marking an element as MustSupport and then providing language that effectively allows an implementation to provide no support for an element seems like an incorrect usage of MustSupport, despite how loose the base FHIR definition is. I don't have a problem with the business rule itself, but I think enforcing it with the clarifying sentences or an updated element description would be better than applying must-support in a way that seems counter to its definition. Thoughts on this?
Yunwei Wang (Nov 20 2020 at 17:35):
@Lloyd McKenzie @Eric Haas @Brett Marquard
Eric Haas (Nov 20 2020 at 18:18):
currently there is no other way to express choice of mustsupport elements
We will document this fully on our conformance page - this is still pending further editing
see how implemented here so far:
Vassil Peytchev (Nov 20 2020 at 18:19):
Is an invariant not possible?
Eric Haas (Nov 20 2020 at 18:19):
invariant to say must support A or B ?
Yunwei Wang (Nov 20 2020 at 18:27):
Maybe need an extension to support say that must support element A or element B
Vassil Peytchev (Nov 20 2020 at 18:27):
A combination:
Must support for A and must support for B are defined as must support when present (this is possible, correct?)
Invariant states that if A is not present, B must be present, and vice versa.
Yunwei Wang (Nov 20 2020 at 18:29):
That is different. Invariant is on resource instance level so that any resource instance must be either A or B. Must support is on the server capability level. A single resource does not have either A or B. But all resources (of the same type) on the server as whole need to support either A or B.
Michele Mottini (Nov 20 2020 at 18:37):
Just write it in English, that's enough
Yunwei Wang (Nov 20 2020 at 18:45):
Plain English is not computable. Our concern is that we can no longer looking at the StuctureDefinition to know if an element is must support or not. Also this violates the "must support" defined in the FHIR spec unless we say that "not support" is a kind of "support"
Eric Haas (Nov 20 2020 at 19:23):
@Yunwei Wang , I feel your pain but currently not a way to do this using SD. in future the datatype codeableReference and changes to resources may help
Michele Mottini (Nov 20 2020 at 19:29):
Computability is not very important - especially for something like must support that cannot really be checked automatically. What is important is the English description: it is an implementation guide - it guides implementers - that are humans
Robert Scanlon (Nov 20 2020 at 20:45):
For the MedicationRequest.reported[x] example, why not just put the 'must-support' flag on MedicationRequest.reported[x], and leave it off MedicationRequest.reportedBoolean/MedicationRequest.reportedReference? Doesn't that computably mean the same thing as what is written out in guidance?
Yunwei Wang (Nov 20 2020 at 20:56):
There is a tiny difference. reportedReference itself is a reference type. Just marking reported[x] as must support means that at least one of reportBoolean, reportedReference is must supported but it does not indicate which reference in reportedReference is a must support.
Robert Scanlon (Nov 20 2020 at 21:17):
But the language says "or a reference using MedicationRequest.reportedReference to Practitioner or other resource."
Yunwei Wang (Nov 20 2020 at 21:20):
That language is not accurate. From the SD, the reportedReference to US Core Practitioner is must supported.
Lloyd McKenzie (Nov 20 2020 at 21:43):
An invariant is not possible. Invariants reflect what must appear in instances. mustSupport reflects what systems must be capable of in their design - in user interfaces, in their database, in their decision logic, etc. Invariants don't apply there.
I think US Core's approach is the best we can handle right now. mustSupport says that the rules around its meaning must be defined in the IG or the profile. I think it's reasonable for the rules to also be defined in the usage notes for individual elements. Essentially seeing the mustSupport flag on a particular element says to the implementer "There are obligations around the implementation of this element - go look at the documentation to understand what they are". The absence of mustSupport on the other hand says "so long as you meet the technical cardinalities and invariants of the instance, there are no rules at all around whether you need to store, display or otherwise take into account the value of this element.
Last updated: Apr 12 2022 at 19:14 UTC
