Stream: Orders and Observation WG
Topic: linking two observations wth hasMember vs derivedFrom
François Macary (Aug 21 2019 at 09:03):
We want to specify whether the oxygen saturation was measured under oxygen gas administration or nor, and if yes, what was the inhaled oxygen flow rate value. Therefore we want to relate oxygen saturation (LOINC 2708-6) to inhaled oxygen flow rate (3151-8).
What is the best option for that?
1) Observation oxygen saturation (2708-6) . hasMember -> Observation inhaled oxygen flow rate (3151-8)
2) Observation oxygen saturation (2708-6) . derivedFrom -> Observation inhaled oxygen flow rate (3151-8)
Thanks for your advices.
Lloyd McKenzie (Aug 21 2019 at 12:16):
I wouldn't use either. "hasMember" is more about organizing Observations into groups/panels. And you didn't calculate the saturation based on the flow rate. Instead, I would capture the flow rate as a component of the saturation because the saturation should always be read/interpreted knowing what the flow rate was.
Rob Hausam (Aug 21 2019 at 12:29):
The possible issue I see with that is that the flow rate is a completely independent (standalone) observation that could easily (and likely would be) interpreted and used without necessarily even knowing or caring that the oxygen saturation was being measured. In this case it is likely a separate recording of the flow rate for the specific purpose of interpreting the O2 saturation results, so maybe that sufficiently pushes it toward being a reasonable use of component?
Lloyd McKenzie (Aug 21 2019 at 13:55):
If it's something we'd expect to be captured on its own, then perhaps we need a new relationship type (at least as an extension)?
François Macary (Aug 21 2019 at 14:02):
We raised the question because the case is borderline and does not fit in any of the options described in http://build.fhir.org/observation.html#obsgrouping
These two observations are produced and recorded independently as @Rob Hausam says, and they do not fulfill the rule "same method, same device, same observation", which excludes using component.
However the value of saturation cannot be interpreted without knowing the value of flow rate, as @Lloyd McKenzie says, and we are not in the situation of a panel of two observations, which excludes hasMember.
The oxygen saturation is not strictly derived from the inhaled flow rate in that sense that it is not a calculation nor a direct interpretation, but could we say that it is influenced by the flow rate, and consider this as a kind of loose derivation?
Rob Hausam (Aug 21 2019 at 14:10):
This could be an extension, as Lloyd mentioned, but it is something that 100% (or very nearly so) of systems that exchange this data need to deal with. So ultimately whatever solution we settle on should be (or become) core.
François Macary (Aug 21 2019 at 14:19):
An extended element like:
influencedBy 0..* Reference(Observation | MolecularSequence | QuestionaireResponse |ImagingStudy |DocumentReference)
Lloyd McKenzie (Aug 21 2019 at 14:24):
Is it "influencedBy" or "informedBy'? The former I would read as "changes the value measured", while the latter would be "changes the evaluation of the value measured"
François Macary (Aug 21 2019 at 14:26):
Yes, "informedBy". Thank you. Is the thinking of having a core extension or adding the element right away into R5?
Lloyd McKenzie (Aug 21 2019 at 14:28):
I think the starting point would be core extension. We could look at moving that to a new "related" type in the future once we have a better sense that: a) the extension meets our needs; and b) the extension is widely supported
Rob Hausam (Aug 21 2019 at 14:28):
somehow "informedBy" isn't sounding quite accurate or sufficient to me - we can discuss further
Rob Hausam (Aug 21 2019 at 14:33):
in the case of O2 Sat, the actual measurement value is "influenced by" the O2 that is being administered (based on the flow rate) and the interpretation and use of that result is dependent on having that information recorded and available at the time of interpretation
François Macary (Aug 21 2019 at 14:34):
So shall I create a tracker specifying this future core extension? Or build the extension in Forge directly and submit it?
Lloyd McKenzie (Aug 21 2019 at 14:35):
Tracker is all that's needed. Authoring in HL7 is in spreadsheets, so submitting something from Forge wouldn't help that much (though proposed definition/implementation notes would be useful.)
François Macary (Aug 21 2019 at 14:46):
I'll build the tracker, trying to provide the proper notes and comments.
@Rob Hausam would "dependsUpon" be more appropriate and more generic than "informedBy"?
Lloyd McKenzie (Aug 21 2019 at 14:48):
Trick with 'dependsOn' is that it would overlap with 'derivedFrom'
Rob Hausam (Aug 21 2019 at 14:55):
it's something to consider - at first I thought it might be a better choice - but again in the case of O2Sat, if you somehow didn't have the O2 flow rate recorded you might be able to make some use of the measurement (you would be likely assuming it was on room air), but having the O2 flow rate information allows the interpretation to be more accurate and more useful
so I think it's actually "supporting information" - which we already have in the supportingInfo extension (http://hl7.org/fhir/StructureDefinition/workflow-supportingInfo)
François Macary (Aug 21 2019 at 15:00):
That was worth looking up :-) So here is what we were looking for!
From there, maybe what is missing is a complement of the section http://build.fhir.org/observation.html#obsgrouping mentioning this existing core extension for cases that fit neither of the other relationships (hasMember, derivedFrom, component).
Eric Haas (Aug 21 2019 at 15:10):
In US Core and Argonaut we are doing it this way: http://build.fhir.org/ig/argonautproject/R4/branches/master/StructureDefinition-us-core-pulse-oximetry.html ( Rob voted for this ) Also we had this discussion last cycle and Rob and I created this extension which we wound up not using anyway in Argonaut anyway. http://build.fhir.org/extension-observation-precondition.html So before we try to create a 4th way of saying this and spend a lot of time in [Groundhog day]() mode we already have many way to associate measures.
Eric Haas (Aug 21 2019 at 15:13):
These measure are typically omitted when on room air and measured and entered into the device when recorded.
Eric Haas (Aug 21 2019 at 15:16):
We have rewritte http://build.fhir.org/observation.html#obsgrouping nearly every cycle and I have come to the conclusion that:
- nobody reads it and they do want they want
- Until we get enough implementers adopting one pattern over another more modelling discussion will not yield any better results.
François Macary (Aug 21 2019 at 15:27):
Agreed. Thanks to this discussion, the good news for me is that we have not one but at least two available core extensions addressing our issue.
Isabelle Gibaud (Aug 21 2019 at 15:30):
The supportingInfo extension (http://hl7.org/fhir/StructureDefinition/workflow-supportingInfo) sounds good to me. What do you think?
Rob Hausam (Aug 21 2019 at 16:59):
Thanks for reminding me that I voted for that, @Eric Haas. :) In my first response I did say that with the likelihood of separately recording the flow rate specifically for this purpose that "maybe that sufficiently pushes it toward being a reasonable use of component?" So I'm not unalterably opposed to that approach. But I do think that the flow rate actually is "supporting information".
Eric Haas (Aug 21 2019 at 17:06):
@Rob Hausam What do we do with http://build.fhir.org/extension-observation-precondition.html then? it seems like it will be a source of confusion?
Rob Hausam (Aug 21 2019 at 17:17):
I don't think that the flow rate is a "precondition" for the O2Sat measurement (it's just a fact that is, not a precondition for it). Since it's a gray area and the US Core/Argonaut approach isn't wrong (especially considering the separate recording aspect), it might be compelling to align with that.
Rob Hausam (Aug 21 2019 at 17:17):
But the precondition extension certainly has valid uses - we just may have not described it optimally and didn't choose a good example. Fasting status (e.g. for glucose) actually is a precondition for that measurement, but we called that out separately in Specimen. And in lab preconditions actually should (always?) apply at the time of the specimen collection, I think. So we may want to do some reconsideration on that extension (or leave it alone and see if anyone ever uses it and complains).
Rob Hausam (Aug 21 2019 at 17:20):
We could at least change the example in the precondition extension to something other than fiO2.
Rob Hausam (Aug 21 2019 at 17:27):
Maybe to something like what is described for LOINC 1504-0 "Glucose [Mass/volume] in Serum or Plasma --1 hour post 50 g glucose PO". The observation that 50 g glucose was administered orally 1 hour prior to specimen collection would be a precondition.
Eric Haas (Aug 21 2019 at 17:30):
I still think we have too many way to associate obvervations and too many way to mess up interoperability
Eric Haas (Aug 21 2019 at 17:31):
Hard to pair em down to fewer later
Rob Hausam (Aug 21 2019 at 17:32):
agree - but it's also not particularly easy to come up with exactly and only the "right" ones in the first place - which is why we arrive at where we are, I think
Eric Haas (Aug 21 2019 at 17:36):
I think we should resteer our design to bigger buckets and not more and more nuanced ones. But that is always the challenge.
Robert McClure (Sep 11 2019 at 15:20):
@Rob Hausam @Eric Haas @François Macary Help me catch up here. Are you saying that the Argonaut approach of using component is not what we want to use? Help me understand why that will not work well and it would be better to push people to use supportingInfo? I can think of many situations where an observation of the environment has an impact on the primary observation even (as we should do) focusing this specifically on observations where we typically do state important environmental/concomitant observations such as fasting state, inspired O2, and orientation of the patient. So if we decide in these situations we should take a particular approach, let's please make sure it's done consistently and with a good justification.
François Macary (Sep 11 2019 at 16:40):
I don't know enough about Argonaut and will let @Eric Haas and @Rob Hausam address this side of the question. The cases discussed in this thread are not covered by "component" from my perspective because the statements below (part of the requirements for component), are false in the current cases (e.g. inhaled O2 related to oxygen saturation measured by pulse oximetry):
1: "component is used for any supporting result that cannot reasonably be interpreted and used outside the scope of the Observation it is a component of." The inspired O2 may be interpreted outside the scope of the oxygen saturation, although the other way round is not true.
2: "Components should only be used when there is only one method, one observation, one performer, one device, and one time.". The inhaled O2 is using a different device and a different method from the oxygen saturation.
Eric Haas (Sep 11 2019 at 16:52):
OK so i concede that the language in the spec should be updated to reflect usage. We have several structures to link observations and some are more tightly bound than others. I agree that it would be nice to do it one way. But everybody thinks their way is best. which why there are so many standards out there.
Rob Hausam (Sep 12 2019 at 12:27):
Are you saying we should relax that language (that @François Macary quoted), @Eric Haas ? I think that's about the only guidance that we have that keeps everyone from just treating components and related observations as essentially interchangeable (except that components are "easier" and they can only be nested at one level).
Lloyd McKenzie (Sep 12 2019 at 12:53):
If it's a different device and different method, I don't see why it shouldn't be a separate Observation...
Eric Haas (Sep 12 2019 at 14:39):
It reflects a theoretical boundary and not real world usage. In other you words its breached more often that not IMO.
Eric Haas (Sep 12 2019 at 14:42):
Is not easier to use components if you need the observation to be separate for your other use cases and reuse. I think that will be the ultimate driver of usage.
Rob Hausam (Sep 12 2019 at 14:42):
to Lloyd's question, it certainly can be a separate observation - and it's required for accurately clinically interpreting and acting on the O2 saturation measurement, so logically it's "supporting information" and the two observations (or components) need to be reported together (linked with workflow-supportingInfo or hasMember, or as components)
Rob Hausam (Sep 12 2019 at 14:52):
a possible justification for doing this with components may be that this particular recording of the O2 flow is almost certainly being done specifically for its use in interpretation of the O2 sat measurement and it is not going to be used independently for other purposes
Eric Haas (Sep 12 2019 at 14:54):
The argument I have for component lines up with your second point and how US CDI regs read.
Eric Haas (Sep 12 2019 at 14:55):
We have not heard vendors pushing back on this as wrong either.
François Macary (Sep 13 2019 at 09:01):
I see "real world usage" as still in the beginning of the FHIR learning curve. My feeling is that the best practises on FHIR are still ahead of us rather than behind. For this reason, rather than relaxing the wording in the specification I would strengthen the existing guidelines, which already imply a non-ambiguous path for linking observations:
- Observation is part of a panel (e.g. CBC, urinalysis, serum electrolyte...)? Use hasMember
- Observation performed as a single action (same time, method, device) produces an array of values (e.g. arterial pressure)? Use component
- Observation is derived by computation or interpretation of a set of observations, images, docs (e.g. trisomy 21 likelihood in fetus derived from echography and beta HCG free)? Use derivedFrom
- Observation result should be interpreted in light of another independant observation (oxygen saturation, knowing inhaled oxygen flow rate)? Use the workflow-supportingInfo core extension.
A more explicit and clearer specification may impact existing pioneer implementations like Argonaut in the US. But is it a sufficient reason for not improving the spec?
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Apr 30 2020 at 11:56):
O2 flow and O2 sat are usually among other results reported in blood gas panels. (Not sure if this is Francois's use case?) There may be other observations such as whether the patient is on room air or nasal cannula, PEEP, BIPAP, and other vent settings that repiratory provides the laboratory with the blood gas order. When the gas is run, these items are entered as results in the panel that is reproted back to teh ordering provider as they provide important clinical results/information for this critical care test.
Last updated: Apr 12 2022 at 19:14 UTC
