Stream: Orders and Observation WG
Topic: Observation.related vanishing
Brian Reinhold (Mar 02 2018 at 14:28):
Its probably late to get in on this discussion but have been locked out of FHIR work for a while. There is a proposed change to 'simplify' the Observation.related element to two inline elements that are more narrowly defined. Previously, the Observation.related element could point to one of at least two resources, another Observation and the Questionnaire. In the PHD Implementation Guide, the use of this element was critical in order to link the 'current' Observation to what is known as the 'Coincident Time Stamp Observation' and any other Observation linked by what 11073 20601 calls the 'Source-Handle-Reference'.
The former is an Observation which contains information about the PHD time stamp and how it was corrected (if it needed to be corrected) and whether or not the time stamp is provided by the PHD or the time of reception (among other details). Given that PHDs tend to have unsynchronized time clocks, correct ion is frequent and the Coincident Time Stamp Observation is essential. The VA in the US was adamant on this topic. The source-handle-reference points to another Observation that this Observation is somehow associated with. An example is the activity 'Session' Observation in activity monitors which scopes Observations like heart rates, calories burned, speed, intensity, etc. contained within that session. Or meal and carb consumption information associated with Glucose measurements.
The proposed solution, as understood from its description, is semantically inconsistent with the current usage. The Observation pointed to in the Observation.reference is really 'derivedFrom' the current Observation, and not the reverse.
Continua thinks it is much better to start with the Observation and find all items associated with it (the Device, Patient, Coincident Time Stamp, etc) than have to do the reverse.
Is our understanding of this change correct? If it is still semantically consistent in the new interpretation to point to these related Observations in the new version as the old, we are happy. But note, in the Continua usage, the Observation.related value is derived from the current Observation, and not the reverse!
Martin Rosner (Mar 02 2018 at 15:19):
@Erik Moll as it relates to your IG ballot comment - GF#15460.
Lloyd McKenzie (Mar 02 2018 at 15:38):
In FHIR, the general rule is that the resource that's created second points to the one created first - so Observations always point to the things they derive from, not the reverse. It's not clear from your description whether/how this would pose a problem.
Eric Haas (Mar 02 2018 at 20:01):
@Brian Reinhold I agree with Lloyd and your use of .related was/is pointing the wrong way.
Erik Moll (Mar 05 2018 at 09:43):
@Erik Moll as it relates to your IG ballot comment - GF#15460.
Using the .derivedFrom in a FHIR observation that represents a coincident time stamp pair will make finding the time stamp pair for a given observation probably less efficient. Also note that a coincident time stamp pair will typically have a lot of ".derivedFrom" referenced observations, since a coincident time stamp is only generated when there is a relevant change in the device time / clock. To me this use of .derivedFrom seems to stretch the semantics: the coincident time stamp is not derived from the set of observations that need it. It is a related observation that is essential to interpret the original observation fully. A similar reasoning would hold for the source-handle-reference mapping.
When .related is replaced by .derivedFrom and .hasMember, the semantically correct way to map IEEE 11073 PHD observations would be to use the .hasMember reference for the coincident time stamp and source-handle-reference observations, while still having a Observation.value[x]. This looks OK to me, but contradicts the described intended use of Observation.hasMember. See http://build.fhir.org/observation.html#obsgrouping.
Martin Rosner (Mar 06 2018 at 20:22):
@Lloyd McKenzie and @Eric Haas would the use of .hasMember as proposed by @Erik Moll be acceptable regardless of the fact that it contradicts the intended use? If Yes, then we can probably work with it. If No, then what would be your proposed approach to solve the dilemma that results from vanishing .related?
Lloyd McKenzie (Mar 06 2018 at 20:37):
What relationship would you have used with the old .related element? (The set of codes available there were fixed)
Erik Moll (Mar 07 2018 at 08:33):
This was not specified yet in H.812.5 nor in the PCHA implementation guide text, and this was not required, since the cardinality of .related.type was 0..1.
When a value has to be picked from the available set, I would pick "qualified-by" for both the coincidentTimeStamp reference and the SourceHandleReference: "The value of the target observation qualifies (refines) the semantics of the source observation (e.g. a lipemia measure target from a plasma measure)." - http://hl7.org/fhir/STU3/valueset-observation-relationshiptypes.html
Eric Haas (Mar 07 2018 at 17:29):
Are these independent measures? I was talking about this the other date and would component of a better choices? How would one use coincidentTimeStamp as independently? Also would the coincidentTimeStamp observation preceed the Device measurement ( e,g., a NIBP) ?
Eric Haas (Mar 07 2018 at 17:30):
I would personally treat as components or if it needs to be a separate indepent measure us an extension call it what you want.
Last updated: Apr 12 2022 at 19:14 UTC
