Stream: implementers
Topic: Representing compound observations
Sathish Tiptur (Jan 25 2019 at 10:57):
I am looking for clarity on representing compound observations. The blood pressure is a great example, nicely fits in. At the top level, I specify the code for blood pressure, then I will have 3 components one each for Systolic, Diastolic and Average blood pressure. The DeviceMetric resource that it references will have the unit specified as mm[Hg] which all makes sense. My question is whether it is mandatory for all the components in a single observation resource to have the same unit of measure. For example, if I am measuring Fetal Heart Rate, I have two connected observations. One is the heart rate itself and the other is signal quality. But these have different units of measure. Is it right to include these two measurements as two components of single observation resource? If yes, should I leave out the unit of measure in the DeviceMetric resource that it references?
Eric Haas (Jan 25 2019 at 14:56):
My question is whether it is mandatory for all the components in a single observation resource to have the same unit of measure.
No
However, I would not expect the top level code to have units if it is representing a bunch of components. In your case you could ideally do one of two things. have a unitless panel code and two components name value pairs or a top level name value and single component name value for signal quality.
Lloyd McKenzie (Jan 25 2019 at 15:23):
The top-level Observation should only have units if it has a value. Some Observations with components will have a top-level value (e.g. APGAR score), while others won't.
Eric Haas (Jan 25 2019 at 17:05):
While I agree with @Lloyd McKenzie, I think in the real worlds implementers may (mis)use existing codes for their purposes such as for top level codes even though they have units and tack on components with other units. While we may frown on this - I don't think there is much we can do to prevent it....
John Silva (Jan 25 2019 at 18:28):
If a system charts observations as post-coordinated concepts then it is likely that there would be represented as multiple components in a 'parent' observation. For example, if I chart a Central Line, I might have the top-level be the code for the C-line, then a set of components that represent the insertion site, the insertion time, maybe even type of catheter, etc. If the source EHR charts these as part of one 'measurement' then these pieces all belong together. If it is an EHR that sends out data in HL7 V2 it is also very likely that the top-level (C-line concept in this example) is conveyed in the OBR and each of the other elements in OBX segments (and this V2 is converted to a FHIR Obs with top-level being CLine concept (OBR) and other elements being components (OBX).
Last updated: Apr 12 2022 at 19:14 UTC
