Stream: implementers
Topic: units on vitals
Mark Jones (Jun 11 2021 at 18:57):
The US Core example JSON for pediatric BMI shows unit of "%" at:
https://www.hl7.org/fhir/us/core/Observation-pediatric-bmi-example.json.html
However, http://hl7.org/fhir/R4/valueset-ucum-units.html indicates that code % should use Display "percent". Is that a hard rule or is unit more freeform while code is not?
Lloyd McKenzie (Jun 11 2021 at 20:08):
@Grahame Grieve
Grahame Grieve (Jun 12 2021 at 01:36):
unit is freeform - what the user saw
Eric Haas (Jun 12 2021 at 02:22):
specifically the Quantity data type is not like CodeableConcept - there is no display element
resourceType: Observation
id: pediatric-bmi-example
# snip
effectiveDateTime: 2019-05-04T12:12:29-07:00
valueQuantity:
value: 65
unit: "%" #<<<<< this is a display unit and decided by the data source it could be "percentile"
system: http://unitsofmeasure.org
code: "%" #<<<<< this is a UCUM code
note:
- text: CDC Males, 2-20 years Chart
Mark Jones (Jun 14 2021 at 13:24):
Does anyone know the answer? Just checking. :)
Vassil Peytchev (Jun 14 2021 at 14:12):
It sounds like Quantity.unit corresponds more closely to CodeableConcept.text, than to Coding.display, and therefore there is no expectation that it will contain the unit display value from UCUM.
John Silva (Jun 14 2021 at 15:05):
Also, could the unit be a (human language) translation of the coded value of the UofM?
Eric Haas (Jun 14 2021 at 15:38):
yes see the example above...
John Silva (Jun 14 2021 at 15:58):
[I meant, e.g. Spanish, French, etc. not just the way people normally think of the coded UofM.]
Grahame Grieve (Jun 14 2021 at 16:49):
it could be. It should be in the language of the resource
John Silva (Jun 14 2021 at 17:03):
Yes, forget about the meta.language property. Brings up an interesting question; if a system (FHIR server) was to provide different translations of the same resource (Obs with valueQuantity or any other) how would that be done? It seems like there shouldn't be separate resource instances because of the risk of the instances not being kept 'in sync'. If someone provides a product based on a FHIR server (store) that was meant to serve users in different languages, how would that be accomplished? (Maybe this would be done by some backend middleware rather than the FHIR server itself.). [Just a 'theoretical question' for thought.]
Grahame Grieve (Jun 14 2021 at 17:17):
users can ask for a resource in a language of their choice, though few systems can accomplish this with anything but pre-translated documentation
Mark Jones (Jun 14 2021 at 17:59):
Also, sorry to ping again when apparently folks had replied! For whatever reason they didn't show up this morning.
John Silva (Jun 14 2021 at 18:05):
@Grahame Grieve - I was only thinking of things that could be pre-translated, e.g. units, code.text strings, etc. not clinical notes entered by a practitioner. In the 'bad old days' ;-) of using relational DBs and "thick client GUIs" these would be in DB tables and (language) resource files.
Grahame Grieve (Jun 14 2021 at 18:06):
sure, those can be. Marginal value, but yes, possible
Robert McClure (Jun 16 2021 at 16:07):
My take of the primary issue here is that Observation.valueQuantity uses Quantity data type and Quantity.unit is a string therefore it should contain whatever the creator of the value exchanged decided to put into it. If someone translates that they would be doing it based on translating a string value, not a coded item. I'd doubt that happens very oftenm and would never expect it in a received resource. It also means that any error checking would need to be based on checking string values.
Colin E. (Jul 12 2021 at 10:04):
Eric Haas said:
specifically the Quantity data type is not like CodeableConcept - there is no display element
When I first started looking at UoM in FHIR it seemed to me, and still does, that the Unit of Measure associated with a Quantity should itself be a CodeableConcept. Doing so would I think allow for-
1) A unit code plus a distinct human-readable unit display representation for each UoM
2) The option of having multiple codes and/or representations for each unit. Each of these would be assumed to be mathematically equal. Whether they are assumed to be actual synonyms is probably something that would cause much debate.
Lloyd McKenzie (Jul 12 2021 at 15:12):
The decision was that translations were quite uncommon in existing systems and so support for that was moved to extension. Also, with quantity sometimes the translations include an alternative value, so that also drove the approach. We do have ability to capture the human-readable display - that's what goes in Quantity.unit.
Last updated: Apr 12 2022 at 19:14 UTC
