Stream: implementers
Topic: Observation nesting and cardinality
Erich Schulz (May 17 2016 at 22:54):
so... I'm looking at observations which seems to have a "central observation" and (code, value, reference range, reason absent) are present both at a root level and as a collection...
Erich Schulz (May 17 2016 at 22:57):
i'm just curious about how locked in this and rationale?
Erich Schulz (May 17 2016 at 23:00):
I can see a rationale for some kind of roll-up mechanism but this only covers subset of possibilities of the n x mbase observations and the derivative "summary conclusion observations"
Grahame Grieve (May 17 2016 at 23:19):
can you provide some specific examples?
Erich Schulz (May 17 2016 at 23:21):
i guess echocardiography reports would be one I was thinking off
Erich Schulz (May 17 2016 at 23:23):
lots of cryptic numbers get rolled up into more friendly things like EF, and valve disease severity (using mild, moderate, severe as a scale)
Erich Schulz (May 17 2016 at 23:24):
i can think of lots of blood panels that include summary interpretations
Erich Schulz (May 17 2016 at 23:24):
an ABG is a bit of a classic actually
Grahame Grieve (May 17 2016 at 23:24):
well, I would expect blood panels to be a series of observations with a panel, and a summary observation
Grahame Grieve (May 17 2016 at 23:25):
ECG, the data would be a single observation with a SampledData - or a few observations any way
Erich Schulz (May 17 2016 at 23:25):
"base excess" and "anion gap" - and of CO2, pH and HCO3 only 2 are measured and other is calculated
Grahame Grieve (May 17 2016 at 23:25):
ABG - arterial blood gas? yes, all the things you have mentioned are sets of observations
Erich Schulz (May 17 2016 at 23:25):
well an ABG has ~ 3 summary measures
Erich Schulz (May 17 2016 at 23:26):
pH being overall, then BE and CO2 for metabolic and resp components
Grahame Grieve (May 17 2016 at 23:26):
calculated fields- they are nothing special. Most things are somewhat caclulated
Erich Schulz (May 17 2016 at 23:27):
so i'm just lost then about why the "1 + n" structure
Erich Schulz (May 17 2016 at 23:28):
if a calculated value is just another value...
Erich Schulz (May 17 2016 at 23:30):
btw was talking of "Echo" not "Electro" cardiography
Erich Schulz (May 17 2016 at 23:36):
but it just seems like significant complication to the data model that only addresses a very small fraction of use cases (eg Apgar, and GCS scales)
Erich Schulz (May 17 2016 at 23:38):
sorry not meaning to be difficult :-)
Erich Schulz (May 17 2016 at 23:40):
I can just see it leading to a stack of arbitrary and divergent conventions for when to repeat the "1" and when to drop into the "n"
Grahame Grieve (May 17 2016 at 23:41):
well, we agree that this is a challenge. And unfortunatelythe horse bolted decades ago too.
Erich Schulz (May 17 2016 at 23:41):
and the extra computational cost of having to query both the "1" and the "n" to find the a value...
Erich Schulz (May 17 2016 at 23:41):
darn
Grahame Grieve (May 17 2016 at 23:41):
as in, much of this stuff we are constrained by existing patterns of reporting in v2 messages
Grahame Grieve (May 17 2016 at 23:41):
Observation = OBX
Grahame Grieve (May 17 2016 at 23:41):
but we and others are working on this. Have you seen the vital signs profile? that's the sort of thing we want to do
Erich Schulz (May 17 2016 at 23:41):
i thought that maybe the case
Erich Schulz (May 17 2016 at 23:42):
got a url?
Erich Schulz (May 17 2016 at 23:42):
if the "1" could be retired I think that would be a step forward for humanity (IMHO)
Grahame Grieve (May 17 2016 at 23:43):
the "1"?
Grahame Grieve (May 17 2016 at 23:44):
http://hl7-fhir.github.io/observation-vitalsigns.html
Erich Schulz (May 17 2016 at 23:44):
as in observation.value cf observation.component.value
Grahame Grieve (May 17 2016 at 23:49):
well, the presence of component is problematic, but so would it's absence be. none of the cases you mentioned should be done with component observations.
Grahame Grieve (May 17 2016 at 23:50):
blood pressure, some machine things, it's not widely applicable, though it's important when it is
Erich Schulz (May 17 2016 at 23:50):
oh really?
Erich Schulz (May 17 2016 at 23:50):
I was just thinking the reverse!
Erich Schulz (May 17 2016 at 23:51):
Erich Schulz (May 17 2016 at 23:52):
it common to grab a bunch of observations in a single go
Grahame Grieve (May 17 2016 at 23:53):
sure. you would use _include or _revinclude to get them
Erich Schulz (May 17 2016 at 23:53):
but thay kinda solves my issue...
Erich Schulz (May 17 2016 at 23:54):
i'm wanting to catch more encounter based observations.... so can just type a stack of observation records to each encounter
Erich Schulz (May 17 2016 at 23:55):
that actually works pretty neatly
Erich Schulz (May 17 2016 at 23:55):
so I'll keep the "1" and avoid the "n"
Erich Schulz (May 17 2016 at 23:55):
:-)
Erich Schulz (May 17 2016 at 23:57):
its a bit more denormalised - would have preferred the other way around but its probably simpler
Erich Schulz (May 18 2016 at 00:21):
So thanks @Grahame Grieve that's been very helpful.
Erich Schulz (May 18 2016 at 00:23):
just to clarify when you say "none of the cases you mentioned should be done with component observations." you mean that an ABG or an echo should be made up of 10-30 seperate observations and that vast bulk should have zero (0) components?
Grahame Grieve (May 18 2016 at 00:41):
yes. As long as these have separate interpretations, and seperate error conditions, they should be different resources. Components should only be used when there is only one method, one observation, one interpretation, one performer, one device, one time
Grahame Grieve (May 18 2016 at 00:41):
most of your cases fail at least one of those
Erich Schulz (May 18 2016 at 00:51):
thanks @Grahame Grieve that is very clear an helpful...
Erich Schulz (May 18 2016 at 00:52):
the "one interpretation" test is not specified in the definition, or in the introductory text
Erich Schulz (May 18 2016 at 00:52):
http://hl7.org/fhir/observation-definitions.html
Erich Schulz (May 18 2016 at 00:53):
it makes complete sense tho
Grahame Grieve (May 18 2016 at 00:54):
we probably should - can you do me a favour and create a gForge task proposing that it made clearer and add my language to the task?
Erich Schulz (May 18 2016 at 00:59):
sure thing
Erich Schulz (May 18 2016 at 01:00):
noting that arguably that means that the component should never be used...
Erich Schulz (May 18 2016 at 01:01):
(which I wouldn't oppose)
Grahame Grieve (May 18 2016 at 01:08):
there's a number of observations which produce composite values that meet those criteria
Erich Schulz (May 18 2016 at 01:09):
that are always "Hi" and "Low" together?
Grahame Grieve (May 18 2016 at 01:09):
well, that are always interpreted together, or where these is only one number that is interpreted
Erich Schulz (May 18 2016 at 01:10):
even with BP - DBP can be low but MAP and SBP can be normal
Grahame Grieve (May 18 2016 at 01:10):
well, BP is problematic in that respect, I guess.
Grahame Grieve (May 18 2016 at 01:11):
there was some discussion about that - don't know where it landed
Erich Schulz (May 18 2016 at 01:11):
I think you may find it applies to many/most
Erich Schulz (May 18 2016 at 01:12):
often the reason a series of different measures are somehow combined is that they individually have some noise
Erich Schulz (May 18 2016 at 01:17):
I guess the useful definition maybe more along the lines "that we would want to interpret individually"??
Erich Schulz (May 18 2016 at 01:17):
have created issue btw
Erich Schulz (May 18 2016 at 01:17):
thanks for all the guidance really appreciated
Grahame Grieve (May 18 2016 at 01:17):
np
Rob Hausam (May 28 2016 at 02:38):
I'm thinking that component may be creating more problems that it is solving - Eric H. and I and others have been working on the language in the OO discussions, but I think the boundaries tend to be difficult to describe and often may be counterintuitive (e.g., Erich's "I was just thinking the reverse!" comment)
Michelle (Moseman) Miller (May 28 2016 at 03:36):
GF#9676 has been applied, such that there is now support for Observation.component.interpretation.
Part of the discussion (that led to the approval of the GF#9676) was that Observation.component.referenceRange already existed -- and reference ranges and interpretations are closely related. It's hard to justify one without the other.
Rob Hausam (May 28 2016 at 03:49):
@Michelle (Moseman) Miller - I guess I missed that quarter! I do agree that having a reference range without an interpretation doesn't really make much (if any) sense. But if we start adding all of the "missing" observation elements to component, then we'll have even more overlap and confusion with it vs. related observations.
Erich Schulz (May 28 2016 at 05:20):
gad
Michelle (Moseman) Miller (May 28 2016 at 18:13):
Agree, @Rob Hausam -- If it makes you feel any better, the extent of the discussion was focused on adding interpretation only. The origins of the change request were related to the same example above (from @Erich Schulz) when we tried to represent systolic and diastolic blood pressure as components of an overall blood pressure. Our system tracks interpretation for each component since some meds are intended to control either SBP or DBP, so having an 'aggregate' interpretation at the observation level wasn't ideal when the interpretations of SBP and DBP can differ.
Erich Schulz (May 28 2016 at 22:54):
In that case it makes the distinction between components and the single observation even more arbitrary
Rob Hausam (May 30 2016 at 13:49):
@Erich Schulz Agree
Erich Schulz (May 30 2016 at 22:18):
is it fixable @Rob Hausam ?? it still seems to me that the element to get rid of would be the observation value... it seems like a rare thing to me to make single observations...
Grahame Grieve (May 30 2016 at 22:44):
I think the opposite. It's the normal thing
Grahame Grieve (May 30 2016 at 22:44):
Observation.component should be constrained for multi-value single observations
Rob Hausam (May 31 2016 at 00:55):
Yes, I would agree with Grahame regarding the commonality. And it would seem strange (and definitely a deviation from precedent) not to have Observation.value, but trying to clearly explain and constrain for what are "multi-value single observations" that should be represented in Observation.component is also definitely a challenge.
Last updated: Apr 12 2022 at 19:14 UTC
