Stream: implementers
Topic: Core vitals Units
Jenni Syed (Apr 07 2020 at 20:24):
Trying to understand what the intent of the Core Vitals profile is in regards to units...
Jenni Syed (Apr 07 2020 at 20:25):
In the past, we've had many discussions on how it's unsafe to represent a different value than what the source system has: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Observations.20and.20Unit.20of.20Measures.3F
Jenni Syed (Apr 07 2020 at 20:26):
And so this extension is often mentioned: http://hl7.org/fhir/extension-iso21090-pq-translation.html
Jenni Syed (Apr 07 2020 at 20:27):
However, the Core vitals profile just states that units must come from the table: http://hl7.org/fhir/r4/observation-vitalsigns.html#bnc
Jenni Syed (Apr 07 2020 at 20:28):
I assume we're hoping that the underlying system is using those units. But if not, I wouldn't want to convert to those units in the core valueQuantity for the same reasons mentioned in the previous discussion as well as things like reference ranges applying to specific units (as an example)
Jenni Syed (Apr 07 2020 at 20:29):
I would want to convert (assuming I can and the data isn't just wonky) using the translation extension so that other systems have both the source with precision and the converted value.
Jenni Syed (Apr 07 2020 at 20:29):
However, that looks like it would make a server non-conformant?
Grahame Grieve (Apr 07 2020 at 21:25):
it would. is that a problem in the real world?
Jenni Syed (Apr 08 2020 at 01:50):
Likely? EG: ounces isn't listed as an ok unit
Jenni Syed (Apr 08 2020 at 01:50):
for weight
Jenni Syed (Apr 08 2020 at 01:51):
To be fair, we've seen some pretty messy things that have come in which were recorded as strings too (which we wouldn't be able to convert)
Jenni Syed (Apr 08 2020 at 01:52):
I can see if we have any idea of how often
Lloyd McKenzie (Apr 08 2020 at 03:47):
I think the expectation is that the units will be converted to the standard measurement. The original can be sent in an extension.
Jenni Syed (Apr 08 2020 at 13:31):
That seems backwards since extensions can be ignored unless they're modifiers and this does have impact given ranges etc will be in the original unit. Also, we are supporting modify and wouldn't want them to expect the write back in to change the underlying unit (nor would we be able to "force" the extension coming back in)
Jenni Syed (Apr 08 2020 at 13:31):
And for patch, which we'll be supporting, it's messier.
Jenni Syed (Apr 08 2020 at 13:31):
There are decimal and precision concerns when you convert as well
Jenni Syed (Apr 08 2020 at 13:33):
Also, for SMART apps, doctors get pretty frustrated when the data shown doesn't match what is in the system/what they see in the main chart
Jenni Syed (Apr 08 2020 at 13:33):
Again, going to try to find out how common this is
Michele Mottini (Apr 08 2020 at 13:37):
For what is worth we are not trying to do any conversion outbound
Michele Mottini (Apr 08 2020 at 13:37):
(we = in our server)
Eric Haas (Apr 10 2020 at 23:03):
would adding oz to the valueset solve the majority of these edge cases?
Richard Townley-O'Neill (Apr 15 2020 at 04:02):
Does it matter that all US customary units are defined in terms of metric? So 1oz (mass) = (exactly) 28.3495 gm.
Lloyd McKenzie (Apr 15 2020 at 14:12):
Why would that make a difference?
Grahame Grieve (Apr 22 2020 at 04:38):
did we get to the bottom of this?
Jenni Syed (Apr 22 2020 at 15:37):
We are running some queries to find out how common this is in our system. We have found instances already where the units wouldn't match the ones required by vitals but are trying to get more specific information
Jenni Syed (Apr 22 2020 at 15:38):
And yes, in my experience, changing the unit has implications (like the decimal issue above), especially for practitioners viewing that data in other apps. I still think we can convert for interop, but shouldn't represent that as the "source" data.
Jenni Syed (Apr 22 2020 at 15:38):
And read/write adds more complexity since that could actually change the source data without intending to.
Jenni Syed (Apr 22 2020 at 20:50):
Still digging in a bit, but I can confirm that there is a lot of data that wouldn't match the profiles. Most common "drift" I see (and this is data heavily biased towards US because that's the source, I would expect different drift outside of US): Height in ft. Height in meters. Weight in oz. (Edit: removed weight in kg since that isn't drift)
Jenni Syed (Apr 22 2020 at 20:50):
For BMI, I see some data using percent instead of kg/m2
Jenni Syed (Apr 22 2020 at 21:26):
Taking height as an example, of a bit over 1 bil data points:
in (though some are technically in_us... weird): 38%
cm: 58%
m: 0.01%
ft: 1%
"other": 3%
Jenni Syed (Apr 22 2020 at 21:36):
Weight (>1.2 bil data points):
kg: 60%
lb: 28%
oz: 7%
g: 0.5%
mg: very small :)
"other": 4%
Robert McClure (Apr 22 2020 at 22:34):
Other wight units? Stone? troy oz? :slight_smile:
Lloyd McKenzie (Apr 23 2020 at 00:15):
What does a BMI in % even mean?
Abbie Watson (Apr 23 2020 at 00:19):
It's a differential measurement from a baseline measurement (either personal or population wide). This is basically the baselining and observation rollup discussion I've brought up in the patient empowerment meetings.
Grahame Grieve (Apr 23 2020 at 00:21):
so if your BMI goes up from 20 to 22 it's gone up by 10%? really?
Abbie Watson (Apr 23 2020 at 00:25):
BMI itself is a mediocre measure to begin with. But as a heuristic, sure. The point is that baselining allows pretty much _any_ Observation to be converted into proportional ratios (i.e. normalized).
Grahame Grieve (Apr 23 2020 at 00:26):
does LOINC have codes for this?
Grahame Grieve (Apr 23 2020 at 00:27):
I dont see that but I do see BMI as % for percentile
Abbie Watson (Apr 23 2020 at 00:30):
Eh, not really. It's more of a primary care or personal trainer methodology. By definition it's subjective, and LOINC and laboratories like to be objective. (But it's subjective in a precise way, and that's important.)
Grahame Grieve (Apr 23 2020 at 00:35):
it's subjective in a precise way
my new favorite sentence
Lloyd McKenzie (Apr 23 2020 at 00:57):
I would say that's not a legitimate value for the regular LOINC BMI code. If you were going to have a BMI with a measurement expressed as a percent that would need to be explicit as to the time period. I.e. Is this a BMI change in the last year? The last month? The meaning would be quite different depending on the time-period - and not at all comparable to a regular BMI measurement
Jenni Syed (Apr 23 2020 at 13:18):
The "other" above for height and weight are likely data we wouldn't attempt to convert - they're weird. We would really have to dig into the data to figure out what is going on, some could be in error (the units make no sense for a height or weight). There's data like that for all categories
Jenni Syed (Apr 23 2020 at 13:19):
I had assumed the % for BMI was more likely a percentile classification. EG: https://www.cdc.gov/healthyweight/bmi/resultgraph.html
Jenni Syed (Apr 23 2020 at 13:20):
And not likely something we would convert :)
Lloyd McKenzie (Apr 23 2020 at 14:48):
My leaning is that you treat % for BMI as 'other' - if you can't convert it and you don't have a clear understanding of what it means, don't share it.
Eric Haas (Apr 23 2020 at 16:50):
http://hl7.org/fhir/us/core/StructureDefinition-pediatric-bmi-for-age.html is an example of a BMI based on a scale.
Eric Haas (Apr 23 2020 at 16:50):
where unit are %
Robert McClure (Apr 23 2020 at 16:50):
@Jenni Syed @Lloyd McKenzie Yes, BMI can be expressed as a % based on comparison to a normal chart for age, just as you found at the CDC. This is used only in pediatrics and works just like weight and length/height. IMHO when used you need to say which chart you are using - they are sex-specific - but for now, people just assume it's correct for birth sex. Here is a snap of the LOINC codes used. This is not an "other"
image.png
Jenni Syed (Apr 23 2020 at 16:53):
@Lloyd McKenzie I don't think not exposing the data is a good answer - this is data they can view today in the chart and may make clinical decisions on. Again, some of it may be entered in error, but we also return those from the API so other systems can be corrected since clinical decisions could have been made on the previous state of data as well.
Jenni Syed (Apr 23 2020 at 16:53):
Also, sometimes humans are better at judging data than computers
Jenni Syed (Apr 23 2020 at 16:54):
So, ignoring the "other" type results above...
Jenni Syed (Apr 23 2020 at 16:55):
and back to the question around converting units - wouldn't it be better to use the existing extension to say "hey, this data exists and here is the original form, but here's the conversion for you" (assuming you can convert)
Jenni Syed (Apr 23 2020 at 16:56):
And still be able to meet the profile?
Eric Haas (Apr 23 2020 at 16:58):
what would be the values - can you mock up a simple example?
Jenni Syed (Apr 23 2020 at 17:13):
It's a standard extension, let me find it
Jenni Syed (Apr 23 2020 at 17:14):
Actually, linked to it above: http://hl7.org/fhir/extension-iso21090-pq-translation.html
Jenni Syed (Apr 23 2020 at 17:15):
Let me apply that to one of the example vitals :)
Jenni Syed (Apr 23 2020 at 17:30):
...
"valueQuantity": {
"value": 83,
"unit": "oz",
"system": "http://unitsofmeasure.org",
"code": "[oz_av]",
"extension": {
{
"url": "http://hl7.org/fhir/StructureDefinition/iso21090-PQ-translation"
"valueQuantity": {
"value": 5.19,
"unit": "lbs",
"system": "http://unitsofmeasure.org",
"code": "[lb_av]"
}
}, ...
Jenni Syed (Apr 23 2020 at 17:32):
I rounded the decimal there on the conversion, could have sent the full 5.1875 :)
Eric Haas (Apr 23 2020 at 18:25):
Thanks that make it a lot clearer for me....
so... what would the constraint be? use the prescribed valueset in either the valueQuantity or in the extension?
Eric Haas (Apr 23 2020 at 18:29):
I think adding oz_av] to the VS makes sense too.
Lloyd McKenzie (Apr 23 2020 at 23:22):
If you can perform the conversion based on age/gender and expose things in the official units, then you could send it conformantly. If the table might vary or you don't have access to the gender or age or whatever to be able to convert it into standard units, then it's not going to be useful to external recipients (and also wouldn't be FHIR-compliant right now).
Grahame Grieve (Apr 24 2020 at 03:11):
so I'm not sure it's clear - BMI as percentile is not covered by the vital signs profile
Jenni Syed (Apr 24 2020 at 17:50):
Neither is weight in oz and some of the other examples up there. I'm trying to figure out how we both maintain clinical accuracy and the FHIR resource as it's stored in source (and don't override that on write on accident), and also provide better interop for systems that want the standard units
Jenni Syed (Apr 24 2020 at 17:53):
I'm trying to find the happy medium with real world data vs. meeting the vitals profile, and avoiding the issues we've talked about on other threads re: bad practice to convert/misrepresent the data as it exists in the underlying system
Lloyd McKenzie (Apr 24 2020 at 18:16):
I'd be in favor of introducing the 'translation' extension into the profile as mustSupport and relaxing the units constraint to an invariant that either the base quantity or one of the translated quantities must use the 'required' unit.
Jenni Syed (Apr 30 2020 at 23:13):
Ok, now the last blockbuster question: If I have something that is clearly a vital, and clearly a height based on it's code... but the unit is unrecognizable or unconvertible to me - do I still return it?
Jenni Syed (Apr 30 2020 at 23:13):
I assume if someone queries by the category: yes. But the result (if my server supported it) wouldn't be tagged as matching the profile?
Jenni Syed (Apr 30 2020 at 23:14):
A hilarious example from my research above was a height in ml
Grahame Grieve (Apr 30 2020 at 23:15):
clearly a typo. So you should handle it like any other data error.... a data absent reason
Jenni Syed (Apr 30 2020 at 23:15):
I assume (hope) that was a fat finger and the result was in-error in the source system. But my data doesn't link that way so I can't confirm :)
Jenni Syed (Apr 30 2020 at 23:16):
@Grahame Grieve a DAR on the unit? IE: don't show original data? Or (if we accept the jira I'm going to log to request that the extension is accepted) - a DAR on the tranlsation unit part?
Jenni Syed (Apr 30 2020 at 23:16):
BMI % is an example where we can't translate it but it is totally human (and some computer) understandable
Grahame Grieve (Apr 30 2020 at 23:18):
well, I think on the value.
Jenni Syed (Apr 30 2020 at 23:19):
In the BMI example, wouldn't that mean that someone that could understand it won't get the clinical data?
Jenni Syed (Apr 30 2020 at 23:27):
Jira logged for extension proposal: https://jira.hl7.org/browse/FHIR-27004 (I didn't see a good way to point to the core vitals profile, may have missed it)
Lloyd McKenzie (May 01 2020 at 01:19):
You could stick in the narrative - but it being in the discrete data isn't going to be super useful
Eric Haas (May 01 2020 at 03:53):
I think GG meant use the DAR element and leave Value[x] empty.
BMI % is only translatable if you know the table from where it was derived. It's answering the wrong question thus is in error as well. The only way to fix that is to add BMI percent code to vitals and an element to indicate the source table from where is calculated.
John Moehrke (May 01 2020 at 15:43):
It would be nice if us-core did have some recommendations for consistent handling of data that is not us-core compliant. recommended behavior for servers being asked to create or update to height in ml, and clients being told that a height is N ml. I don't think it is right for us-core to mandate something, as local clinical practice policy would need some ability to define what clinically is right.. but some baseline recommended behavior in the absence of local policy.
Lloyd McKenzie (May 01 2020 at 16:23):
This isn't a US Core issue - the expectation around the units for vital signs is part of the base spec.
John Moehrke (May 01 2020 at 17:05):
understood.. but the US-Core does define a valueset of specific units of measure that are within conformance
Jenni Syed (May 01 2020 at 19:26):
No, that's actually in the Core (international) Vitals spec. US Core inherits from that.
Eric Haas (May 05 2020 at 19:44):
discussed tracker J#27004 on OO on FHIR today:
- add oz to weight.
- Is BMI as % a thing for adults? already have the US Core profiles for peds. No enthusiasm for adding BMI % for adults
-
concern that this weakens the international standardization of representing vitals and units are a key part of that standardization
- counter-proposal is to reconsider original proposal to put the standard value in the valueQuantity element and the original value in the extension.
- if no translation then the valueQuantity is empty and use DataAbsentReason
- don't agree assertion that is a modifier extension is correct.
- Unclear why the client app could not display the original value. If they choose to ignore is on them. we could must support the extension and provide guidance to clients.
- counter-proposal is to reconsider original proposal to put the standard value in the valueQuantity element and the original value in the extension.
Jenni Syed (May 06 2020 at 20:41):
I don't think I mentioned a modifier extension.
Jenni Syed (May 06 2020 at 20:41):
Where was a modifier extension discussed/in relation to what?
Jenni Syed (May 06 2020 at 20:42):
I do worry that on a modify, they could completely exclude the extension that was the original data. That would tell our server to overwrite the original value in the data. What was response to that/discussion around read/write challenges?
Jenni Syed (May 06 2020 at 20:44):
And next, will this pattern proliferate to the profiles that are doing other similar "translations" to break apart pre-coordinated codes? I worry we're setting a problematic pattern. Also, implications to those that do digital signature on Provenance (not sure how broad that is) since the resource won't read out the way it was signed.
Eric Haas (May 19 2020 at 23:31):
after devoting another call to this topic we have :
-
Add 'oz_av' to units valueset
-
Add comments for BMI, Wt and Ht that indicate that % measure is a derived pediatric measure from the base [unit] measurements and are not part of the FHIR core vitals sign profiles. Instead, other profiles such as US Core
US Core Pediatric BMI for Age Observation Profile
US Core Pediatric Weight for Height Observation Profile
should be used to represent them.
( if apply 1 and 2 do we need 3-5 i.e., is this still an issue)?
- Introduce the 'translation' extension (http://hl7.org/fhir/extension-iso21090-pq-translation.html) into the vitals profile as a mustSupport.
- original unit data in valueQuantity and if not a standard unit the translated value and unit in the extension in 2. above
- Change the invariant for units to require the standard unit in valueQuantity or by using the standard extension uses that unit.
Lloyd McKenzie (May 20 2020 at 00:01):
So that will be changes to both US Core and to the core profiles?
Jenni Syed (May 20 2020 at 13:59):
One other question/clarification (esp if we're updating this): are annotations allowed on the ucum units (since those don't change the calculation)? EG: is {Breaths}/min allowed? I didn't see anything specific called out in the profile.
Lloyd McKenzie (May 20 2020 at 15:12):
Strong preference to prohibit annotations - stick them in 'unit', but they make life much more difficult in code.
Lloyd McKenzie (May 20 2020 at 15:13):
(Or if we're going to have them, fix what they SHALL be, don't allow variability)
Eric Haas (May 20 2020 at 21:12):
This is for the core spec which is referenced by us core
Eric Haas (May 20 2020 at 21:13):
No on annotations.
Eric Haas (May 20 2020 at 21:14):
Don’t think any guidance that should be part of profile but part of quantity datatype.
Jenni Syed (May 20 2020 at 21:26):
We've definitely allowed the annotations on ucum in general: http://hl7.org/fhir/valueset-ucum-common.html
Jenni Syed (May 20 2020 at 21:26):
I think it would have to be on the specific profile
Jenni Syed (May 20 2020 at 21:27):
(and at a quick glance, both beats and breaths per min are in there as annotation examples that are expected, and would be applicable to the vitals profile)
Lloyd McKenzie (May 20 2020 at 23:04):
They might be 'applicable' and they're certainly legal UCUM. But I'm quite sure we don't want to be in a situation where there can be more than one 'code' for a given unit. So either we prohibit annotations in the vital sign resources or we lock each profile to mandate a single specific annotation. My preference is to prohibit annotations because while the units are generally seen as language-independent, the annotations wouldn't be.
Eric Haas (May 21 2020 at 05:31):
I think the examples need to be changed
Jenni Syed (May 21 2020 at 13:56):
When I said "example" I didn't mean an actual json resource example, just meant examples of values listed in that value set which could apply to vitals. Sorry for confusion @Eric Haas :)
Jenni Syed (May 21 2020 at 13:57):
to be clear: I'm not arguing that vitals shouldn't take a stand on this. I think it should since annotations in ucum are definitely allowed in general for FHIR. It would be good to actually document expectations one way or another on the profile. I'll log a tracker jira
Jenni Syed (May 21 2020 at 14:09):
Jenni Syed (May 21 2020 at 14:09):
interestingly, ucum states that parsers need to throw those annotations away and should ignore them
Christof Gessner (May 21 2020 at 15:30):
That is: code parsers that are built to analyze the UCUM code as a post-coordinated UCUM expression, and how it relates to its canonical representation and SI base units. That is IMHO not parsers that aim at looking up a code in a given value set, without further inspection of that code's internal structure and meaning. Such a value set may contain codes having annotations and considers them as significant.
Christof Gessner (May 21 2020 at 15:36):
So I postulate that there are two equivalence relations: One regarding the "metrological" equivalence or comparability of unit concepts, the other one regarding "string equivalence" with items in a (finite?) value set, i.e. within a given well-defined business context.
John Moehrke (May 21 2020 at 15:58):
so following Postel's Law... we should be designing to be robust to some level of deviation from perfect conformance to the standard. Might it be useful to have a GitHub repository with some examples that are slightly off. We could classify them as close-enough to display, but we could also just leave them non-judged. (Note some of the examples would also be good to be completely off base, as consuming these should not break a system) I tend to think they should all be non-judged as the actual judging would be so use-case specific (Create from a UI, Import from other organization, etc) -- Does this already exist somewhere?
Eric Haas (May 21 2020 at 16:11):
to be clear: I'm not arguing that vitals shouldn't take a stand on this. I think it should since annotations in ucum are definitely allowed in general for FHIR. It would be good to actually document expectations one way or another on the profile. I'll log a tracker jira
I am countering that I think the FHIR should take a stand on this ( ie always allowed or never allowed) and not leave it up to individual profiles to decide. I don't understand what John said either.
Jenni Syed (May 21 2020 at 16:41):
UCUM argues that if you remove the annotation capability, people won't use your standard (which is why they allow for it) and calls out some of our realm as one of the specific groups that is pretty sure we "need" annotations :)
Jenni Syed (May 21 2020 at 16:41):
that would be my main concern about making this a fhir-wide rule vs. use case specific
Christof Gessner (May 21 2020 at 17:01):
Example from medicinal product regulations: The dose form is documented in coded form in a data set. Nevertheless, it is required to repeat the dose form in the expression of product 'strength' , for example you must say '100 mg per tablet'. Typically solved with textual representation as UCUM annotation: '100.mg/{tablet}' where '100 mg/1' would be sufficient.
Eric Haas (May 21 2020 at 18:26):
at least here, FHIR says nothing about this now.
it is sounding like should say something to effect of "expectation is that '{annotation}' can be used unless specifically prohibited by use case. " + an example or two
Lloyd McKenzie (May 21 2020 at 19:08):
I'd say we should at least say it's "discouraged". It adds complexity and FHIR has a better solution (Quantity.unit)
Eric Haas (May 21 2020 at 21:19):
But that doesn't agree with the UCUM guidance according to Jenni...
Jenni Syed (May 21 2020 at 21:35):
You all can go read it and draw conclusions - don't take my word for it :) I quoted it and linked on the issue
Jenni Syed (May 21 2020 at 21:36):
From ucum: https://unitsofmeasure.org/ucum.html (section 2.1, §6 curly braces)
Jenni Syed (May 21 2020 at 21:36):
Can't actually link to the section, sadly
Jenni Syed (May 21 2020 at 21:37):
@Lloyd McKenzie usually we put the internal display in unit, which wouldn't be a standard.
Jenni Syed (May 21 2020 at 21:38):
but it does fit the "human readable" need :)
Lloyd McKenzie (May 21 2020 at 22:44):
There's no need for what goes in the unit to be standard - it's for human readability. What goes in the curly braces isn't "standard" and is for humans. If you only have one slot, then curly braces allow you to send something that sort-of satisfies both purposes. But given that we have two slots, I'd prefer to optimize what we put in 'code' for computers and leave the 'make the humans happy' bit to unit - which is what it's for.
Lloyd McKenzie (May 21 2020 at 22:45):
I'm not arguing to prohibit curly braces in code in FHIR (except perhaps for the fixed vital signs units), but I think discouraging them and pointing to unit instead is completely reasonable.
David Simons (Oct 13 2021 at 12:08):
What is the consensus now on including additional units in vital signs? (scope: universal/core profiles, not us-core.)
Use extension http://hl7.org/fhir/StructureDefinition/iso21090-PQ-translation for the original units, and translate to the required units on vital-signs valueQuantity?
Since derivedFrom and component are not applicable/sub-optimal, it seems.
Lloyd McKenzie (Oct 13 2021 at 14:42):
That sounds right to me
Last updated: Apr 12 2022 at 19:14 UTC
