Stream: implementers
Topic: Handling Observations with different units
Erik Moll (Oct 05 2017 at 08:03):
If I have a system that works internally with metric units (meter, Celsius, kilogram, .. ) and I have sensor device / application that report Observations like weight / length / temperature in US / imperial units (feet/inch, Fahrenheit, pounds), what would be a good way to model this using FHIR Observation resources?
Note that a single observation includes a CodeableConcept that can have multiple codings, but that an Observation can only have a single value.
Options considered are:
- creating two Observation resources, one with the original unit / quantity and one with the converted unit / quantity - using the "related" attribute with relation type "derived-from" or "replaces".
- creating an Observation resource with the internally used unit / quantity and a component with the original unit / quantity.
- creating an profile/extension by adding "originalValue" to an Observation resource.
Is this a general enough problem to be solved in the standard FHIR resources?
What would be seen as advantages / disadvantages of the listed options?
Michel Rutten (Oct 05 2017 at 08:13):
You could also choose to persist the device output data in the original format and perform queries in another format using a library such Fhir.Metrics:
https://github.com/furore-fhir/Fhir.Metrics
Erik Moll (Oct 05 2017 at 13:33):
That is certainly an option as well, but that would imply that the needed conversions are done each time the observation is included in a query.
Also note that the mentioned library does NOT include all imperial to metric conversions (yet).
We would like to convert only once and keep the original observation as well.
Jason Walonoski (Oct 05 2017 at 15:26):
This doesn't answer you're question, but I think all Observations internally should use the metric system by default, or whatever the recommended units are if the Observation uses LOINC. For example, LOINC recommends degrees Celsius for Body Temperature.
I'm in the US. Conversion of those units into feet, inches, pounds, Fahrenheit, etc -- should all be done by display or export. Storage should be consistent.
Eric Haas (Oct 05 2017 at 16:48):
Michel and I talked about this a bit in San Diego and I'm in favor of his suggestion is using a retrieval method that does the conversion from the original. Perhaps a set standard search parameter like _metric or _usunits ( which could be part of us-core) -_impunits ( what is a stone anyway?)
Eric Haas (Oct 05 2017 at 16:59):
I don't like any of the choices above but rather this one: GF#13988
Jenni Syed (Oct 05 2017 at 17:40):
I like the gforge option as well - an extension. We've seen profiles that try to get servers to do conversions to standards on output. This seems like a great idea until you try to put it into practice. For eg, many apps want to see exactly what's in the source (for example, a doctor switching from his native app to a SMART app that shows the same data but does additional work). Also, if you convert going out, writing becomes an issue - trying to determine if the client was trying to modify the value and trying to determine what units you should record it in the source system
Jenni Syed (Oct 05 2017 at 17:41):
While I would love to say that all source systems should be metric, I don't see that happening anytime soon :)
Jenni Syed (Oct 05 2017 at 17:41):
And even then - do you prefer kg, g, etc
Jenni Syed (Oct 05 2017 at 17:41):
Not to mention all the fun decimal precision issues you may encounter when converting and trying to compare...
Jenni Syed (Oct 05 2017 at 17:42):
The extension is nice because it allows you to return the source of truth as well as conversions
Grahame Grieve (Oct 05 2017 at 19:54):
hmm. I really should have done this already. I've just added a new extension http://hl7.org/fhir/StructureDefinition/iso21090-PQ-translation that you can use in a Quantity to add another quantity that's a translation of the same quantity to a different set of units
Grahame Grieve (Oct 05 2017 at 19:55):
(should be visible in the next 20min or so)
Rob Hausam (Oct 05 2017 at 19:55):
sounds like a good way to move ahead on it
Brian Reinhold (Oct 05 2017 at 20:04):
Erik,
Unfortunately the units associated with the valueQuantity, in spite of being a code, does not support multiple translations to other coding systems like the coding element. That being said, I would upload the unit code the device provides. That is what is done, in any case, in the PCHA PHD upload profiles. It is then up to the readers to make the necessary transition of the value and units to the realm of interest.
Elliot Silver (Oct 05 2017 at 21:48):
I assume that if you were to do a search for a quantity with a certain value/range/etc. you'd want it to search the quantity as well as the extension.
(Actually, from a user point of view, I'd probably want it to search for a value in the range I give in my choice of units, regardless of the element's choice of units or presence of an extension. I say 20-30 kg, and it matches anything between 20 and 30 kg, 20,000 and 30,000 g, 44 and 66 lbs, or 3.1 to 4.7 stone. Ouch.)
Grahame Grieve (Oct 05 2017 at 21:50):
on my server, the server automatically normalises units when you search for a quantity.
Grahame Grieve (Oct 05 2017 at 21:50):
but only ucum units
Eric Haas (Oct 05 2017 at 22:01):
grahame's behavior is documented here: http://build.fhir.org/search.html#quantity
""The search processor may choose to perform a search based on canonical units (e.g. any value where the units can be converted to a value in mg in the case above).
Michel Rutten (Oct 09 2017 at 09:01):
For .NET-based implementations, you can leverage the Fhir.Metrics library to perform unit conversions:
https://github.com/furore-fhir/Fhir.Metrics
Usually, I think a user would expect a FHIR server to be able to return submitted resources as-is, i.e. with the original values in the original units (esp. for audit logs). However this expectation does not prevent a server from calculating and storing conversions on insert/update (e.g. in some internal db tables), in order to speed up retrieval and search.
Christiaan Knaap (Oct 09 2017 at 11:39):
Vonk stores a canonicalized value if the input is a UCUM unit, accounting for the precision. It does not alter the value in the resource itself, but stores it along with it to support search. Quantities in a search operation are canonicalized the same way, so as long as units are convertible to each other it does not matter which one you use in the Resource and which one in the search operation. We leverage the Fhir.Metrics library that @Michel Rutten mentioned, so if any conversion is missing from it I would like to hear which.
Allowing an extension for conversions of the same value is fine in our solution. I would just suggest to also add a SearchParameter to it that enables searching the value in this extension.
John Moehrke (Oct 10 2017 at 14:36):
another good use-case where a Resource might be legitimately modified by the server... I point out as another example of where Digital-Signatures that are not well designed (with experience) would break. Crude solution is this update is a version following the signed version, but that puts into question 'this' version vs the version that was digitally-signed... blunt digital-signatures are very strong, but fragile. I have updated our wiki page on digital signature challenges http://wiki.hl7.org/index.php?title=FHIR_Digital_Signature_Working_Page
Brian Postlethwaite (Oct 16 2017 at 03:59):
Our server does quantity conversions for searching in the same way (using the Fhir.Metrics lib too)
Suranga Kasthurirathne (Oct 24 2017 at 18:14):
hmm. I really should have done this already. I've just added a new extension http://hl7.org/fhir/StructureDefinition/iso21090-PQ-translation that you can use in a Quantity to add another quantity that's a translation of the same quantity to a different set of units
Hi there! trying to work with the PQ Translation Quantity extension. It looks like the link Grahame posted goes 404. mayhap this is the resource he is talking about? https://build.fhir.org/extension-iso21090-pq-translation.json.html :)
Lloyd McKenzie (Oct 24 2017 at 18:27):
"http://hl7.org/fhir/StructureDefinition/iso21090-PQ-translation" is the correct URL. It doesn't resolve yet because the definition was defined as part of R4 which is not yet published
Lloyd McKenzie (Oct 24 2017 at 18:27):
However, yes the URL you pointed to is where you can find the current definition
Suranga Kasthurirathne (Oct 24 2017 at 19:39):
excellent! thank you :)
Venkateswara R Davuluri (Oct 25 2017 at 13:19):
what is opinion about this.. https://en.wikipedia.org/wiki/EIDAS for digital signatures
Eric Haas (Oct 25 2017 at 15:39):
sounds like a new thread to me.
John Moehrke (Oct 25 2017 at 16:08):
Yes, EIDAS should be a different thread... but EIDAS is simply a set of EU hosted services. The result of a digital signature under this, would fit nicely into the FHIR Signature data-type; specifically use of Provenance.signature can hold this. Nothing new, just a deployment of 'trustable Identities that the EU is declaring they support.
Christiaan Knaap (Nov 07 2017 at 06:26):
On the combination of different units for the same observation and digital signatures an idea popped up: Would it be feasable to have something like ElementDefinition.inSignature, akin to .isSummary? So you can change some values that are not considered vital to the signature.
John Moehrke (Nov 07 2017 at 13:48):
The elements that would be covered by a signature would be specific to that signature, each signature standard has a method of excluding/including. We are leveraging existing signature standards and their capability. I also am not sure we could flag elements that everyone would want to be in/out of a signature.
Lloyd McKenzie (Nov 07 2017 at 14:13):
It would be straight-forward enough to define an extension you could drop anywhere and a canonicalization algorithm that only grabbed elements with the extension. But I'm not sure that approach would be a common enough use-case to define the approach as part of core.
Last updated: Apr 12 2022 at 19:14 UTC
