Stream: implementers
Topic: UCUM bpm - heart rate at wrist
Alexander Henket (Jun 27 2017 at 06:58):
Looking at http://hl7.org/fhir/observation-vitalsigns.html which does not have wrist but has Heart Rate, you should measure that in /min. Looking at this CDC document https://ftp.cdc.gov/pub/CLIAC_meeting_presentations/pdf/Addenda/cliac0313/13B_CLIAC_2013March_TableofExampleUCUM.pdf it says to measure in {beats}/min.
I'm sure they are equivalent, but almost no system would probably agree because they don't understand that UCUM works like that. So just for the record: do we stick with the exact "string" /min or would {beats}/min also be allowable?
Alexander Henket (Jun 27 2017 at 07:32):
For the record and for reference: the example UCUM units column under the LOINC code that FHIR uses also says {beats}/min. -- https://s.details.loinc.org/LOINC/8867-4.html?sections=Comprehensive
Alexander Henket (Jun 27 2017 at 07:42):
GF#13573 added
Eric Haas (Jun 27 2017 at 14:41):
Its up to the vendors and implementors on whether to use the {} syntax in UCUM. I've been pushing uphill for a while to use this more human readable style but the reception has been lukewarm at best. Another example is count where I think {count} is more descriptive than a cryptic 1 I'm sure there are other technical issues...
Brian Reinhold (Jun 27 2017 at 14:44):
I MUCH prefer the {bpm}/min. /min could be anything, for example my cycle tempo!
Lloyd McKenzie (Jun 27 2017 at 16:46):
The problem with using the {} style is that those aren't actually computable - there's no constraints on what anyone can put there - which means that there's no chance of computer interoperability with "dumber" systems. A smart system will treat "{count}", "{capsule}", "{capsules}", "{Capsules}", "{shovel-full}", etc. as equivalent. A dumb system will treat them as separate. And you're going to be in pain either way. Don't put human-readable stuff in the part of the code that's intended for computation. That's what Quantity.unit is for.
Alexander Henket (Jun 28 2017 at 07:00):
All true, but since LOINC and CDC both suggest {beats}/min, and FHIR profiles have the expression power to be precise about spelling and case sensitivity of codes, I see no reason why you would choose anything but the exact string {beats}/min, not {bpm}/min, not {b}/min or any other potentially reasonable alternative
Eric Haas (Jun 28 2017 at 16:34):
reiterating Lloyds point the {} stuff is really for human consumption so if we have it in the units element then putting in the code element will muddy the waters.
Alexander Henket (Jun 28 2017 at 19:34):
No it will make FHIR match LOINCs suggestion and that of the CDC, but let's see where the ticket takes us.
Last updated: Apr 12 2022 at 19:14 UTC
