Stream: implementers
Topic: Generic way of encoding average measurements
Morten Ernebjerg (Jul 10 2021 at 12:15):
I am looking at data from a service that aggregates measurement from wearable devices, e.g. heart rate data & want to map it into FHIR Observation instances. The service allows pulling data for different time intervals (e.g. 24 hours) and the returned result is then an average(or sum, as appropriate) over this interval. For a few cases, there are indeed LOINC codes for such averages e.g. Heart rate 24 hour mean. But not every combination is covered, e.g. I will also have resting heart rate 24h average and here LOINC only offers a point-in-time code, as far as I can tell (40443-4).
Hence my question: is there are generic way of creating Observation instances representing quantity X averaged over time interval T ? I am thinking of cases where there is code of a point-in-time measurements of X, but no code for the T-average, cf. the case of resting heart rate. I can think of two general ways of approaching this, but am not sure if either one is acceptable:
- Using the point-in-time code in
Observation.codeand then using another field (eg.Observation.methodor an extension) to indicate that this is an average over a specific time interval. - Using post-coordinates SNOMED expressions. For instance, using 444981005 (Resting hear rate) and combining it with the temporal context attribute (408731000) set to some appropriate value (alas, my SNOMED-skills do not quite suffice for actually saying how this would work in detail).
Are there standard approaches in either of these direction (or a third one)?
Lloyd McKenzie (Jul 10 2021 at 16:38):
Best is to have a single code, but in theory you could have a generic code that simply says "averaged systolic blood pressure" and capture the period as an Observation.component. I doubt you'll get a LOINC code issued for "averaged systolic blood pressure" because they prefer that sort of stuff to be coordinated, but you could define such a thing in a code system of your own. That said, you could also define a pre-coordinated code of your own - and that would make it easier to map to a 'standard' LOINC code if one ever comes along.
Rob Hausam (Jul 11 2021 at 03:23):
@Morten Ernebjerg @Lloyd McKenzie
I would say that this LOINC code comes pretty close to what Lloyd theorized about for "average systolic BP" :
96608-5 Systolic blood pressure unspecified time mean
Fully-Specified Name
Component: Intravascular systolic
Property: Pres
Time: XXX^mean
System: Arterial system
Scale: Qn
Method:
There are also pre-coordinated codes for the specific 1, 8, 10, 12 and 24 hour time intervals.
Morten Ernebjerg (Jul 11 2021 at 15:25):
OK, sounds like I will have to live with custom codes for the cases where I cannot find the exact LOINC matches.
I was wondering if it would still be allowable/desirable to combine a custom code with one or more additional codes from LOINC in the Observation.code.coding-array. I.e. take the case of "resting heart rate - 24 hour mean". I could define and add a custom code with that exact meaning. But could I now additionally also add LOINC 40443-4 (Heart rate --resting) and/or LOINC 41924-2 (Heart rate 24 hour mean)? My initial feeling is that it would it be dangerous because systems that known only LOINC might misclassify the Observation & a 24 mean can be quite different from a point measurement. But both of these LOINC codes clearly semantically overlap with my custom code , so I'm not quite sure where they fall in terms of the "slightly different granularity"-zone allowed by FHIR for different codes in a single CodeableConcept.
I doubt you'll get a LOINC code issued for "averaged systolic blood pressure" because they prefer that sort of stuff to be coordinated,
@Lloyd McKenzie I only know post-coordination from the SNOMED & ICD contexts (compound codes/expressions) - how does it work in the context of LOINC?
Lloyd McKenzie (Jul 11 2021 at 15:36):
This wouldn't be post coordination, it'd be a qualifier code sent as a separate Observation.component. (Similar to how you might send a susceptibility and the drug it's susceptible to as a component
Josh Mandel (Jul 11 2021 at 15:36):
When you think about applying multiple Codings, I think the key is you want to make sure that each one is accurate in its own right -- different levels of granularity are okay, but It would be inaccurate to assign a "resting heart rate" code to a measurement that actually represents a 24-hour average (which presumably combines measurements at rest and during activity)
Rob Hausam (Jul 11 2021 at 15:39):
@Morten Ernebjerg LOINC doesn't have any provision for post-coordination of codes. You would need to use the most specific LOINC code that applies, and then handle any remaining details using information model constructs (i.e. FHIR elements). Maybe we could try to work through one or more examples and see if/how this could work? As far as including multiple codes, the additional codes would all have to be generalizations of the entire meaning - not just different parts of it. I don't think you're going to find any useful "correct" way to do that with the "leaf" level LOINC codes. You might be able to use some of the LOINC part (LP) codes from the multi-axial hierarchy, but I don't expect that it would help you to do that. [I don't think that anything that I've just said is contradictory with what Lloyd and Josh just said, but I was writing it before I saw their posts.]
Rob Hausam (Jul 11 2021 at 15:47):
I will say that there are some questions and concerns and recent discussions within OO about the use of Observation.component for "qualifiers" as Lloyd has described. That definitely wasn't originally intended for 'component' (it was excluded through STU3), but the idea was added in R4 and has been the source of some confusion about what can and can't (or should and shouldn't) be done with it. On the Friday OO Lab/LIVD calls we are working through a recommended approach for microbiologiy results reporting, and I don't think that using 'component' is likely what will be recommended for representing susceptibility test results.
Morten Ernebjerg (Jul 11 2021 at 15:54):
OK, thanks - that confirms my suspicion that additional LOINC codes would not be good. And thanks for clarifying the notion of post-coordination with LOINC! - I thought I'd missed some major part of LOINC logic :smile:
@Rob Hausam Post-coordination example using non-code FHIR elements sounds like an interesting idea. In fact, given that SNOMED at ICD-11 provide ways of encoding things that are also explicitly represented as FHIR element (e.g. Observation/Condition.bodySite), the general question of how to divide information between a (complex) code and other FHIR elements seems very relevant to me. It is certainly something I have wondered about! I suppose that there are no universally valid rules for this, but it might be interesting to discuss the various approaches somewhere in the spec.
Rob Hausam (Jul 11 2021 at 16:02):
@Morten Ernebjerg Yes. This is the classic Terminfo issue - which we are still discussing. :smile: The SNOMED on FHIR group is attempting to address this, and there should be something about it in the SNOMED on FHIR (whatever name we give it) IG - when that is finally published. The issue is most relevant to the use of SNOMED CT, but it isn't limited only to that - and it arises in a somewhat different way, but it certainly also applies for LOINC, as we've just said. I think it's reasonable to consider what we might/could say about it more in the base FHIR spec.
Morten Ernebjerg (Jul 11 2021 at 18:37):
@Rob Hausam Interesting, good to know.
Brian Alper (Jul 11 2021 at 23:53):
@Morten Ernebjerg Let me know if you want to review the Evidence Resource in R5 which provides structured ways to specify statistics such as averages.
Morten Ernebjerg (Jul 12 2021 at 06:31):
@Brian Alper Thanks for the tip! I did indeed not have Evidence on my radar and had a look. It seems it does not quite fit my use case, though, as I am not in the context of a study and do not have a population (or rather, a population of one) and treat the the value as a simple value rather than evidence for particular underlying phenomenon.
Brian Alper (Jul 12 2021 at 09:23):
@Morten Ernebjerg Here is a simple use of Evidence to cover a population of one:
variableDefinition
..variableRole = population
..observed = Group (member = Patient, quantity = 1)
variableDefinition
..variableRole = measuredVariable
..observed = EvidenceVariable (characteristic = LOINC code)
statistic
..statisticType = http://build.fhir.org/valueset-statistic-type.html / C53319 / Mean
..quantity = the result
..numberOfEvents = the number of measurements that are averaged
But if you only want to show the value this may be more than you need. The value of the Evidence Resource is if you want to add additional information like a 95% confidence interval or standard deviation to go along with the value. But it does have the structure to code the "average" as a statistic type.
Morten Ernebjerg (Jul 12 2021 at 15:32):
Nice! Like you say I think it does not fit the current use case, but it could definitely be useful for us if we generate aggregate data ourselves.
Last updated: Apr 12 2022 at 19:14 UTC
