Stream: implementers
Topic: Association of observations with each other.
Mariano Garuz (Sep 20 2018 at 09:43):
Hi everyone,
Is there any way in HL7 FHIR to associate between them observations of a taken measure?.
That is, if in a pulse oximetry measurement, I get Spo2, heart rate, and perfusion index. How could you define that these observations belong to the same measure?
Or for example, to add the cardiac pulse in a measure of blood pressure, but associated with it, and not as an independent observation.....
Brian Reinhold (Sep 20 2018 at 09:48):
@Mariano Garuz
I link then with the derivedFrom element (not the best name as it is misleading; I was assured that it does not mean the measurement was actually obtained from that measurement during the balloting process).
John Moehrke (Sep 20 2018 at 12:24):
Those other measurements could also be seen as all part of the same Observation. Thus you have a primary Oxygen saturation value, and a set of components. This indicates that those component values are all part of the same observation. They don't stand on their own. In the component element they can be well defined, so the fidelity doesn't get lost. http://hl7.org/fhir/STU3/observation.html#10.1.4.1
Lloyd McKenzie (Sep 20 2018 at 14:51):
@John Moehrke These wouldn't all be on the same Observation. SPO2 and heart rate are completely separate measures. They often can be captured independently and can certainly be analyzed independently. (That's different than the parts of an APGAR or a susceptability level and an antibiotic - for those, they need to be reported together to be useful.)
Lloyd McKenzie (Sep 20 2018 at 14:53):
Association of Observations right now is just linked by same performer, same device, same or proximate time. You could, if you wanted, report them as a panel - so an overall Observation with multiple members as a way of linking them too. Do you have a need for somethign more than those options?
Lloyd McKenzie (Sep 20 2018 at 14:54):
derivedFrom isn't appropriate unless there's true derivation - and cardiac pulse and blood pressure aren't derived from each other.
Brian Reinhold (Sep 20 2018 at 15:02):
derivedFrom isn't appropriate unless there's true derivation - and cardiac pulse and blood pressure aren't derived from each other.
I will be very disappointed, I remitted on my negative vote on this change because I was assured what I could do with the former 'related' element (I think it was) I could still do. 'derivedFrom'is still perhaps okay in my use case but in that case there is no direct derivation. It does contain some important information that may have helped in populating some of the elements in the current observation.
Eric Haas (Sep 20 2018 at 15:35):
I don't understand what the issue is. They are independent measures. How are they related besides be taken at the same time by the same device? If you want them reported as a panel then use a panel. Otherwise there is no intrinsic dependency or preconditions on the measurements.
Eric Haas (Sep 20 2018 at 15:38):
If there is a requirement to interpret one observatino in light of another observaition then see this... http://build.fhir.org/observation.html#refine But again - as a clinician - I don't see this applying here either.
Rick Geimer (Sep 20 2018 at 15:38):
You could always group them in a List resource where List.source points to the device that created them all.
Eric Haas (Sep 20 2018 at 15:39):
There a many ways to group Observations documented here... http://build.fhir.org/observation.html#obsgrouping
List is not one of them
Rick Geimer (Sep 20 2018 at 15:43):
If we are suggesting that List never be used to group Observation resources, then perhaps that should be noted here:
http://build.fhir.org/list.html#bnr
Lloyd McKenzie (Sep 20 2018 at 15:44):
List can be used to group all sorts of things, but grouping Observations would be somewhat unusual. It certainly wouldn't be an appropriate way to convey "these things were Observed as a group".
Lloyd McKenzie (Sep 20 2018 at 15:44):
hasMember or grouping in a DiagnosticReport would be the appropriate solutions for that.
John Moehrke (Sep 20 2018 at 16:00):
There a many ways to group Observations documented here... http://build.fhir.org/observation.html#obsgrouping
List is not one of them
as is indicated in this section "Because the idea of what to group together is often highly contextual and based upon the end user's point of view, the choice of which structure to use will be driven by jurisdiction, organizational practice and context. Profiling will normally be necessary for implementation."
John Moehrke (Sep 20 2018 at 16:02):
so clearly there is an important IG or Profile needed to deal with Lab results that do have many values. Like Pulse Ox, Cholesterol, etc... Lacking these, then any of these groupings seem up for grabs
Lloyd McKenzie (Sep 20 2018 at 17:13):
There's specific guidance in the core spec. You can't use "componentOf" unless the observation can't reasonably be interpreted independent of others - and obviously that's not true of the relationship between heart rate and blood pressure. There's similar guidance for the others. The expectation is for implementers to follow the guidance provided. There will certainly be some degree of variance. Some will report APGAR without components, some will report it with. Some will organize data into panels, others won't. But you can't choose components for something that aren't clearly components, nor can you split data that's not separably interpretable into distinct Observations.
John Moehrke (Sep 20 2018 at 18:27):
that is indeed the point... Lacking those guides where there is questionable independent observations we will have some using one Observation with multiple component values where others will be reporting multiple Observations. This is simply the state of the FHIR standard, and typical for a standard to offer regional or other alternatives.
John Moehrke (Sep 20 2018 at 18:29):
Hi everyone,
Is there any way in HL7 FHIR to associate between them observations of a taken measure?.
That is, if in a pulse oximetry measurement, I get Spo2, heart rate, and perfusion index. How could you define that these observations belong to the same measure?
Or for example, to add the cardiac pulse in a measure of blood pressure, but associated with it, and not as an independent observation.....
seems to me an SpO2 Observation could have components of the heart rate during that measurement, and perfusion index during that measurement. That specific question, seems legitimate to be one Observation. The heart rate is key to the SpO2 measurement. to take it as a standalone heart rate seems less useful.
Lloyd McKenzie (Sep 20 2018 at 18:33):
SpO2 is a measure of oxygen saturation. It's not clear to me how heart rate is a key to that measure. In this specific case, there are already mandatory vital signs profiles implementers are expected to adhere to. And heart rate and oxygen sat are captured as separate Observations.
Mariano Garuz (Sep 21 2018 at 09:47):
I think there is no clear way to relate independent, yet related measures because they are done for example in the same clinical intervention.
Patrick Werner (Sep 21 2018 at 10:04):
I think there is no clear way to relate independent, yet related measures because they are done for example in the same clinical intervention.
that would be Observation.partOf(Procedure)
Eric Haas (Sep 21 2018 at 16:26):
I think this stream is getting a little off topic. The original question was how to relate independent measures. Lloyd answered correctly. Physiologically hr and bp are correlated but the measures are independent. What I think Brian meant was equivalent to saying “the code for a bp when the hr is X. “. We have both guidance and an extension if you want to be explicit about all the associated concurrent measures and I encourage everyone to read the spec. I personally think you don’t need to do this though
Eric Haas (Sep 21 2018 at 16:58):
And do as Lloyd suggested
Eric Haas (Sep 21 2018 at 17:01):
http://hl7.org/fhir/StructureDefinition/observation-precondition is extension.
Eric Haas (Sep 21 2018 at 17:02):
New in R4 and I thought was in response to Patrick’s tracker
Craig McClendon (Oct 10 2018 at 16:23):
I've read this thread a couple of times, the STU3 guidance, and current guidance; and I'm still not clear on the best route to take.
To add to the conversation, here is another use-case.
I have a fitness tracking device which will send a daily summary of various things for a period (step count, calories burned, exercise minutes, heart rate highs/lows, etc.)
I would like to maintain some grouping of the individual Observations, if possible.
The guidance on DiagnosticReport states that it should be associated with an order - not the case here.
Creating a grouping/parent Observation and linking the Observations via Observation.related could make sense in STU3, but less clear in R4 as Observation.related becomes Observation.derivedFrom.
What is the best way to do this - or is there a "best" way.
Thanks
Lloyd McKenzie (Oct 10 2018 at 16:35):
Each Observation would be captured on its own. Those leaf-level Observations would not show any relationship to each other. However, you could also create a grouping/panel Observation that pointed to each of the leaf-level Observations using the hasMember element. (derivedFrom would potentially be appropriate to link minutes or steps to calories burned if the calorie calculation was made based on one or both of the other Observations, but it would not be appropriate to link most of them with that relationship.)
Craig McClendon (Oct 10 2018 at 18:12):
Thanks Lloyd. I need to check my reading comprehension skills, ha.. Somehow I overlooked 'Observation.hasMember'. So in STU3 I can use 'Observation.related' with a type code of "hasMemeber" and in R4 transition to 'Observation.hasMember'.
Lloyd McKenzie (Oct 10 2018 at 18:15):
Correct
Last updated: Apr 12 2022 at 19:14 UTC
