Stream: implementers
Topic: Representing a distribution of observable entity
Ana Kostadinovska (May 21 2021 at 08:41):
We have Body Posture Data reported, that contains the following attributes: upright, supine, prone, lying_left, lying_rights, and unknow. For each of the attributes, minutes are reported (or ratio) of the detected posture within an hour. For example: upright = 20, supine = 15, prone = 0, lying_left = 15, lying_rights = 10, unknow = 0.
In general how can such distribution of an observable entity over a period of time be reported as a FHIR Observation resource(s)?
We are considering to report each item in the distribution as a component of an Observation, with the actual posture as Observation.component.code and the number of minutes as Observation.component.valueQuantity.
John Moehrke (May 21 2021 at 11:46):
sounds reasonable. The consideration we get concerned about when a solution uses .component, is to ask if each measurement could stand alone. Seems this is a set of measurements taken as a set? Is this set of measurements already recognized as a LOINC panel?
Ana Kostadinovska (May 21 2021 at 12:32):
Thank you for your answer! Indeed is a set of meassurements taken as a set of observed body postures distributed over a period of time. Thus, I think it would not make sense to have each measurement stand alone. We havent found neither LOINC nor SNOMED appropriate concepts. Please let me know if you are aware of some. Thank you!
Rob Hausam (May 22 2021 at 03:18):
@Ana Kostadinovska The guidance here is what should be taken into account when you are trying to decide whether data is suitable to be represented using .component, or not (the original link in the R4 spec is here):
Observation.componentis used for any supporting result that cannot reasonably be interpreted and used outside the scope of the Observation it is a component of. Component observations may make up the separate and individual parts of the observationor may provide qualifying information to Observation.codeand may only be able to be understood in relation to the Observation.code (for example, see the $stats operation). Therefore all code-value and component.code-component.value pairs need to be taken into account to correctly understand the meaning of the observation. Components should only be used when there is only one method, one observation, one performer, one device, and one time. Some use cases for using this structure include:
- Observations that are commonly produced and interpreted together. For example, systolic and diastolic blood pressure are represented as a single Blood pressure panel.
- Assessment tool results that are commonly produced and interpreted together. For example, a newborn Apgar score that is a single Observation with five components.
- Representing multiple answers to a question (relationship and boundaries between Observation and Questionnaire/QuestionnaireResponse). For example, reporting the types of alcohol consumed by a patient
On the other hand, any observations that are clinically relevant outside the context of being a component of another observation should be represented by separate Observation resources. For example a Body Mass Index (BMI) Observation should not contain components for height and weight because they are clinically relevant observations on their own and should be represented by separate Observation resources. See the section below on how to relate independent Observations.
I've added the strikethrough above as that particular text was added only in R4 and seems to be causing some confusion, and we are seriously considering removing it in R5 and remaining with the original guidance for how and when to use component. I think that given this guidance, these postural measurements likely are best represented as a panel and should probably be represented by separate observations for the individual items related to the "panel" observation by hasMember (the "panel" observation itself, presumably for "Body Posture Data", would not have a value of its own). That's my take at the moment.
Lloyd McKenzie (May 22 2021 at 12:23):
Qualifying information is essential to convey in a component. Communicating that a blood pressure was standing or sitting or sharing the cuff size or sharing the antibiotic that an organism was found to be 'sensitive' too are all essential parts of the base observation. They don't mean anything on their own. Cuff size isn't really an "Observation of its own" - it's a qualifier on the base observation.
Eric Haas (May 24 2021 at 17:20):
By that same reasoning , I think that a postural measurements should be components as well.
Eric Haas (May 24 2021 at 17:21):
I disagree with Rob (sorry :-))
Erik Moll (May 26 2021 at 08:57):
What we now have is that we can model a distribution as an Observation with a set of components for each element in the distribution.
We do not have a generic model that identifies the concept of a “distribution” of an observed entity.
How would a receiver / FHIR client know that a set of components is a distribution of a value over time?
The generic question was how to represent a distribution of an observable entity (in this case patient posture) over time.
It could as well be a heart rate zone distribution over a patient's revalidation session, or sleep stage over a night of sleep. The time spend in HR one zone or sleep stage does not have much meaning on its own.
We could consider a new kind of value[X] – valueTimeDistribution consisting of set of value pairs for such distributions as a generic way to handle this. This would remove the use of components to model the distribution, but has a bigger impact on the FHIR standard.
Would such generic approach be considered useful?
Alternatively we can think of an observation profile using components to represent such distributions.
Grahame Grieve (May 26 2021 at 09:04):
have you looked at SampledData?
Erik Moll (May 26 2021 at 10:02):
SampledData could be used to generate such distribution, but cannot be used to represent it.
Lloyd McKenzie (May 26 2021 at 13:14):
We had a couple of data types to represent distributions in HL7 v3. We didn't bring them across because they weren't well used. We would either need to define a complex extension or a new data type. My leaning would be to start with a complex extension. Is there a 'base' data type that would make sense to hang a distribution off of?
Grahame Grieve (May 26 2021 at 13:30):
I'm not really sure what it is. Is this a statistical summary?
Erik Moll (May 26 2021 at 14:48):
It is a form of statistical summary. In this particular example the sensor report the patients posture by reporting number of minutes within an hour that the patient was observed to be in that posture.
In general, such distribution reports the time or the percentage of time an observable entity has a certain value or falls in a certain range.
Rob Hausam (May 26 2021 at 15:50):
@Lloyd McKenzie @Eric Haas I think the real problem is that the added phrase of "or may provide qualifying information to Observation.code" has opened the door but hasn't been sufficient to describe what is and isn't allowed and when and how an observation component may be used to "qualify" a base observation. So I think we do need to decide whether to go back to the original language or more completely describe the use of component in this way. Lloyd's statement (emphasis added) that "Qualifying information is essential to convey in a component." is pretty strong (and I would say it's too strong, as I'm sure it isn't strictly true). That additional "qualifying" information itself may be essential, but it's not necessarily essential that it must be conveyed using component.
The suggestion (at least implied) that "the antibiotic that an organism was found to be 'sensitive' to" should be represented using component is interesting, particulary in light of the discussions that we are currently having on the Friday OO Lab/LIVD calls regarding coming to a greater degree of consensus and a recommended approach to representing microbial culture and susceptibility results in FHIR. I can see how the battery of results from a panel testing the susceptibility of a particular organism isolate to a set of antibiotics (antimicrobial drugs) could be done using component. But it's not the only way to do it (and, as I recall, using component for that hasn't even been brought up in the discussion so far). And I think we've already established that component is not the correct choice for representing many other lab panels/batteries, such as CBC, chem panel and many others where the individual results would potentially have useful meaning and could be used separately. So a question there, I think, would be whether it's better to use component to represent the individual antibiotic susceptibility values (because you can), or better to use separate observations with hasMember to be more consistent with many (or most) other panels?
Lloyd McKenzie (May 26 2021 at 17:02):
It's essential to convey using component because you can't presume that anyone will ever have access to any other Observations. Someone has to be able to look at an Observation and understand what it means without looking at any other Observations. It's fine a hemoglobin and a white blood cell count to be separate observations, but it's not fine for a systolic value and the cuff size and whether they were sitting or standing to be separate observations. The latter two are useless on their own and understanding the systolic value really depends on the latter two being available.
Lloyd McKenzie (May 26 2021 at 17:04):
Batteries where you have multiple tests is fine. Part of the problem is that in LOINC, the notion of 'battery' mixes up things that should be components vs. those that might reasonably be separate observations. Having systolic and diastolic as separate is fine (though we've agreed because they're almost always evaluated together, having them as components is also ok). But if you're going to separate them, you'd want to repeat cuff size, exertion level, body position, etc. as components of each, not as separate observations in a panel.
Last updated: Apr 12 2022 at 19:14 UTC
