Stream: implementers
Topic: FHIR Example in US Core
Ankita Srivastava (Feb 22 2022 at 16:06):
Hello All,
I was just going through following example and observed that something is not correct here - we have valueQuantity mentioned under component as well as outside the component. However, as per my understanding, if we have valueQuantity defined at component level then we can't have it outside the component at the same time.
https://www.hl7.org/fhir/us/core/Observation-satO2-fiO2.json.html
Can somebody confirm on this?
Lloyd McKenzie (Feb 22 2022 at 16:12):
There's no issue with having a valueQuantity as a value and as a component. The base valueQuantity is indicating the O2 saturation. The component valueQuantity is indicating how much oxygen the patient was on at the time (which qualifies the understanding of the base value). What part of the spec led you to believe this wasn't allowed?
Ankita Srivastava (Feb 22 2022 at 16:24):
Based on below:
Each Observation must support:
-
a result value
-> if the result value is a numeric quantity, a standard UCUM unit -
a reason if the value is absent*
- component results
https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-vital-signs.html
I understood that it is OR condition - value can be either result value OR dataAbsentReason OR component.value[x].
Daniel Venton (Feb 22 2022 at 16:34):
I don't think there is an applied operator between the list of items. You have to support these 3 things. Either individually or in concert with the others. Perhaps there is another implied constraint of shall not have data absent when value is specified. But that'll be hard to reconcile with the multitude of different observations.
Lloyd McKenzie (Feb 22 2022 at 16:38):
I think there's an implied or between "absent reason" and having a value. There's typically an implied or between an absent reason and components, though not always. There's definitely not an or between having a value and having components.
Agree that the wording could be clarified. Can you submit a change request @Ankita Srivastava?
Ankita Srivastava (Feb 22 2022 at 16:41):
Thank you @Lloyd McKenzie & @Daniel Venton for the clarification. Will submit the change request for this. Thanks again :)
Ankita Srivastava (Feb 23 2022 at 08:27):
Change Request ID - FHIR-36083
Yunwei Wang (Feb 23 2022 at 14:54):
@Ankita Srivastava These are "Must Support" requirements, not "Must Have". Please check section 2.2.5 (https://www.hl7.org/fhir/us/core/conformance-expectations.html#must-support-elements) for US Core's expectation for Must Support elements
Ankita Srivastava (Feb 23 2022 at 16:06):
@Yunwei Wang thank you for your suggestion. However, it is not related to Must Support requirement. Lloyd & Daniel have clarified my query. Thanks again
Yunwei Wang (Feb 23 2022 at 18:42):
It is related to MS requirement. In your 2nd post: "Each Observation __must support__:"
Eric Haas (Feb 28 2022 at 17:39):
this narrative is simple list of the Must support requirements. For specific guidance you need to look elesewhere.
Ankita Srivastava (Mar 01 2022 at 23:53):
@Eric Haas Please guide me, where can I find details on simultaneous usage? Thanks
Eric Haas (Mar 02 2022 at 01:13):
there are examples in the US Core here: http://build.fhir.org/ig/HL7/US-Core/Observation-satO2-fiO2.html
there is code and value and separate component codes value pairs that 'qualify' the main code value pair
the table at http://hl7.org/fhir/R4/observation-vitalsigns.html
shows many other examples where the additional code/value pairs can be use to qualify the main code value pair for many of the additional codes it makes no sense to record them separately since without the context of the main code value pair they have little or no value
Ankita Srivastava (Mar 02 2022 at 12:15):
@Eric Haas , I have seen this example thats why raised the query.
Last updated: Apr 12 2022 at 19:14 UTC
