Stream: implementers
Topic: Must Support in Core Spec
Elliot Silver (Sep 28 2021 at 19:43):
The discussion of must support in FHIR says that MS is IG dependant and no elements in the core spec are flagged as MS. However, vital signs declare several elements as MS. What is the required MS meaning for these?
The base vital signs profile makes component.value[x] must support. Height and Weight derive from the base vital signs profile, (and thus, inherit the base profile's MS obligations) but it would be (I assume) unusual to find component.value[x] in a height or weight. What is the intended obligation of a system to support component in this case?
Lloyd McKenzie (Sep 28 2021 at 20:19):
I think there's a change request about this already. It's definitely something that needs to be addressed, because we're not following our own methodology around mustSupport
Elliot Silver (Sep 28 2021 at 20:34):
Ah -- J#20192 covers the fact that vitals use MS but we don't specify what is required; J#28190, J#28191, J#28192 cover the fact that MS doesn't make sense on component.value[x] for height, weight, and BMI (although, I'm not sure their inclusion is a typo as claimed in the tickets).
Elliot Silver (Sep 28 2021 at 20:38):
I'm hoping that those two sets of tickets will end up meaning that a system that supports vital signs will not be expected to support component.value[x] (or actually, any of component) unless the system supports one of vital sign profiles that explicitly makes use of component, i.e. panel.
Lloyd McKenzie (Sep 29 2021 at 02:30):
(or blood pressure)
Grahame Grieve (Sep 29 2021 at 06:11):
maybe take up that specific point with #Orders and Observation WG
Eric Haas (Sep 29 2021 at 15:01):
I think they are typos because they were introduced/copied from argo data query without removing the MS tags which are meaningless without a definition. This solution would mean that there will be no MS on these profiles. FHIR-20192 proposed resolution is potentially troublesome for downstream profiles which might have a conflicting MS rules with any base MS rules.
Lloyd McKenzie (Sep 29 2021 at 23:30):
I don't think that's the solution. I think the intention really is that at least some elements are supported. (Claiming to comply with the profile and not having an Observation.value but instead sticking the value in Observation.code.text or something is definitely intended to be non-conformant.) However, the mustSupport expectations do need to be clarified and to make sure they're only in places they need to be.
Eric Haas (Sep 30 2021 at 02:38):
I think the intention really is that at least some elements are supported.
I authored the core profile and I failed to consider that the must support language was missing. Ergo it is indeed an error of omission for which in retrospect was a good thing. I think getting consensus on MS rules in the core spec now is going to be hard. I drafted a proposal that outlines some basic FHIR RESTful Rules that may be anodyne enough to pass muster. see FHIR-20192
Lloyd McKenzie (Sep 30 2021 at 02:47):
I think that's weaker than necessary. I'd say "Sender: If your system is capable of capturing the vital sign with discrete data values and recognizing that it is a vital sign that falls within the scope of the profile, then you SHALL be capable of populating those elements marked as mustSupport with data." I don't think we much care what receivers do with the data.
Last updated: Apr 12 2022 at 19:14 UTC
