Stream: implementers
Topic: Observations and Unit of Measures?
John Silva (Mar 21 2019 at 10:49):
How do you deal with systems sending in FHIR Observations (e.g. from an HL7 V2 interface) where the unit of measure is not what your system expects? In other words, if your system expects a normalized (base) unit for a particular observation, how or where do you do the unit conversion?
One way would be to have the sender do the unit conversion to the normalized unit, e.g. if the sender has Kg but the receiver expects g (grams) then they could perform the conversion. Another way would be to have the receiver perform the conversion (normalization) as part of or in addition to it's storing of the observation. If the receiver did this, it would want to maintain the identifier (business identifier) reference to the original Observation in case there is an update to it, e.g. an updated Lab value. I suppose one could create a new Obs with the relatedTo pointing to the original Obs with the sender's UofM but this seems like a lot of extra work (and house-keeping). It would be easier if the FHIR Obs supported a notion of alternative UofMs for a valueQuantity (or an array of valueQuantity?) Another related topic to this, which I believe has been discussed before is the notion of precision. This is especially important when performing unit conversions but there doesn't seem to be any way to communicate this in the FHIR Observation (or FHIR datatypes unless I'm missing something).
René Spronk (Mar 21 2019 at 11:02):
I think it's a best practice for receivers to do the conversion, and for a data source to record the units as-is when some data was captured. If one is using UCUM conversion should be easy to achieve at the receiving end.
John Silva (Mar 21 2019 at 12:09):
@René Spronk -- Thanks for the quick response. If the receiver does the conversion, where does it store the results; in another FHIR Obs with a referTo reference? I'm concerned about the problem of updates to the original FHIR Obs from the sender, e.g. a corrected Lab result. Also, there is still the concern about the precision; inevitably when doing unit conversions there is a concern about the precision. For example, even in the simple case of a power of ten conversion (Kg to grams) what amount of precision should be preserved? (This is especially a problem with JSON since numbers in JSON don't "do" precision well.)
Craig Newman (Mar 21 2019 at 12:13):
Technical issues aside, I'd be wary of display considerations if the receiver does the conversion. A lot of sender (labs in particular) are very adamant that what they send is what is stored and displayed to users. In particular, if this is coming from a v2 message where the reference range is a string (not not also tranformable), the interpretation of that may be adversely affected if the result units are transformed.
John Silva (Mar 21 2019 at 12:33):
@Craig Newman -- good point; there is an implicit (if not explicit) precision in the equipment making the original measurements that needs to be preserved. Just because a multiplication or division produces more digits doesn't mean that the measurement has more precision. (I like the example of WBC -- typically reported in x10000; what does that mean about the actual precision of the instrumentation/method used to perform the measurement?) https://www.pathologystudent.com/8423/
René Spronk (Mar 21 2019 at 12:48):
Why would a receiver have to store a converted value? It should store the original value+unit as-is, and only convert on-the-fly for display reasons. As for the precision issue - I'm aware there's some wording around that in the FHIR spec, but it's not my area of expertise...
Michele Mottini (Mar 21 2019 at 13:09):
See http://hl7.org/fhir/datatypes.html#decimal: 'The precision of the decimal value has significance:
e.g. 0.010 is regarded as different to 0.01, and the original precision should be preserved . . . '
Grahame Grieve (Mar 21 2019 at 20:35):
so: it's a matter of hate the users when you say:
- you must use our units for display
- we won't coordinate with each other so that we all use the same units
Grahame Grieve (Mar 21 2019 at 20:35):
but such is life in lab data all over the world
Grahame Grieve (Mar 21 2019 at 20:36):
however in FHIR, life is much more complicated than receiver and sender. There's n repositories in the picture. It's better to think of data source, data store, and data user
Grahame Grieve (Mar 21 2019 at 20:37):
data source doesn't know the unit expectations of the data user, who's probably n steps away any (and there will be n*n data users). Data stores might have a policy to impose a common unit. or they might not.
Grahame Grieve (Mar 21 2019 at 20:37):
anyway, this extension is available: http://hl7.org/fhir/extension-iso21090-pq-translation.html
Grahame Grieve (Mar 21 2019 at 20:37):
and data stores might want to use it
Grahame Grieve (Mar 21 2019 at 20:38):
the question of search is much more vexed. My server supports search on canonical units if a UCUM code is provided as a way to work around this - but it is dependent on UCUM being aavailable
Last updated: Apr 12 2022 at 19:14 UTC
