Stream: implementers
Topic: Tension between observation codes and free choice of units
Morten Ernebjerg (Dec 19 2018 at 11:53):
I am working on a profile for blood glucose for a context in which both mg/dL and mmol/L are commonly used as units (they differ only by a conversion factor). I expected there to be a LOINC code that would cover both units, but as far as I can tell (corrections welcome...), the relevant LOINC codes are either specifically for blood glucose in moles/volume (15074-8, 14749-6) or in mass/volume (2345-7). One could imagine different ways of dealing with this:
1. Make two profiles - one per LOINC code - fixing the units accordingly
2. Make a single profile for which the code field is bound to a value set containing the two LOINC codes (and possibly with constraints enforcing the appropriate units based on the code)
3. Make a single profile with a custom code for blood glucose (no unit format specified) and allow both units.
4. Choose one set of units and the corresponding LOINC code, and force clients to convert on their side if they use the other units.
The examples I have seen (which may be from regions where only a single unit is common) go with option 4. Option 1 is easier on the clients, sticks with a standard code system, and avoids complicated constraints (making it more transparent), but it requires two profiles for what is really a single type of measurement. Does anyone have experience and/or good arguments from similar cases?
Lloyd McKenzie (Dec 19 2018 at 15:08):
1. is easier on clients for creating, but harder on clients for querying, harder on decision support systems, etc. Having the data in consistent form is generally useful. And for the clients, they're often having to do some degree of unit conversion and code conversion even to comply with the base LOINC codes, so a bit more conversion to a standard representation isn't necessarily that much of an ask. (And doing so benefits everyone downstream.)
Lloyd McKenzie (Dec 19 2018 at 15:09):
#1 is the approach we've taken for standardizing vital signs.
Morten Ernebjerg (Dec 19 2018 at 21:20):
Thanks @Lloyd McKenzie ! Just to make sure I understand you correctly, are you saying that #4 (single profile w. single LOINC) is preferable (consistent, easy query, not much extra work for clients)?
Lloyd McKenzie (Dec 19 2018 at 21:27):
Yes. It's a bit more work for clients on the create side, but easier for all clients for query/analysis/decision support
Grahame Grieve (Dec 19 2018 at 22:11):
This is a trap, this one, because it's not about unit conversion. concentration vs mass is a bit more fundamental than this. if you're good, you can still convert, but you need to know the mass of a glucose molecule to do so. Bread and butter once you do (for a lab weenie anyway). I don't believe that LOINC captures the molecular mass anywhere? (we could publish a code system supplement?)
Grahame Grieve (Dec 19 2018 at 22:13):
I think that most clinical chemists would argue that this kind of conversion is outside the scope of what software should be doing; they choose mass or concentration for a reason (and reflecting on this, mass vs concentration in plasma is much more complicated than a simple conversion in simple aqueous solution). So from a clinical perspective, you have to choose either #1 or #2. I'd lean towards #2 but I don't know what your deployment issues are
Jan-Marc Verlinden (Dec 20 2018 at 08:21):
Nice to see another answer from the clinician than from a developer.. :-), seen that before. To my believe standardisation is not letting every clinician walk the same direction. It's a bit of a joke, but also my experience. So your answer will be at the client side (ask the doctor..)
Morten Ernebjerg (Dec 20 2018 at 10:55):
Thanks for the input! Once again, things turn out to be more complicated than they first appear, but with this I can makr a more informed choice.
Mikael Rinnetmäki (Jan 23 2019 at 12:25):
Hi @Morten Ernebjerg, what's your current status with this?
We're just profiling blood glucose observations for Finnish PHR and discussing this very matter.
Mikael Rinnetmäki (Jan 23 2019 at 12:28):
@Grahame Grieve
I don't believe that LOINC captures the molecular mass anywhere? (we could publish a code system supplement?)
In fact they do. See for instance https://s.details.loinc.org/LOINC/15074-8.html?sections=Comprehensive, MEMBER OF THESE EQUIVALENCE GROUPS, LG49883-8 Glucose|Pt|Bld|180.156 g/mole
Sulka Haro (Jan 23 2019 at 12:34):
Hi @Morten Ernebjerg, what's your current status with this?
We're just profiling blood glucose observations for Finnish PHR and discussing this very matter.
Where this gets complicated is when modeling data produced by devices used by diabetics for glucose measurement. Most continuous glucose monitors create the originating data in mg/dl, even if the device has been set to display mmol/l for the user, and implementing a system that requires all data to be stored in mmol/l would mean requiring unit conversion to happen on storage, which in turn can result in the data stored in the FHIR system to be different from the originally observed value (and in many cases different from the originally produced data).
Morten Ernebjerg (Jan 24 2019 at 09:32):
@Mikael Rinnetmäki In the end, I went for option (2), i.e. a single profile allowing for two possible overall LOINC codes (blood glucose in mass/volume and in moles/volume). I also bound the units to a ValueSet with the two value we allow (mmol/L & mg/dL) and put in constraints that ensure that the units match the overall LOINC code. It sticks with standard codes and in the end, it made sense to me to have this as a single profile since corresponding Observations differing only in the the units are stating the same physiological fact. What I'm not entirely happy about is the use of constraint to enforce the code-unit correlation, I think constraints are much easier for implementers to miss.
(nice stand-up talk on Nightscout in Amsterdam, BTW!)
Mikael Rinnetmäki (Jan 24 2019 at 11:46):
Thanks @Morten Ernebjerg. That approach puts some more responsibility on the apps (the apps need to be aware of both codes and units). As I'm making a diabetes app that's anyway well aware of both units I appreciate that. I also see the other view, though, that for generic apps it's easier to fix one code and unit and stick to that. There's only burden for apps writing the data (they need to do the conversions), not for apps presenting it and doing analytics. Let's see where we end up in the context of #finnish PHR...
John Silva (Jan 24 2019 at 12:58):
FYI, I think we see difference in units in other observations and I believe (from what I've heard from our clinical folks) that there are some that are specified in mmols and others in micrograms. If I remember right, Sodium and Potassium are two where we see this difference in clinical practice in the US and Europe.
Mikael Rinnetmäki (Jan 25 2019 at 10:41):
@John Silva with blood glucose it also depends on market, but is even more variable. Some countries in Europe use mg/dl, others mmol/l.
Christof Gessner (Jan 25 2019 at 11:08):
@Mikael Rinnetmäki ...which implies a different LOINC, of course.
There are many useful "co-constraints" between Observation codes (LOINC et al.) and units (UCUM et al.) published in the "harmonized Rosetta Table" on https://rtmms.nist.gov - unfortunately, the site is affected by the shutdown, some information here: https://www.nist.gov/itl/ssd/systems-interoperability-group/medical-device-communication-rtmms
John Silva (Jan 25 2019 at 11:16):
@Mikael Rinnetmäki - thanks for the feedback. My observation (pun intended) was that it doesn't only happen with Glucose, it happens with other measurements. In my example of Sodium and Potassium I didn't remember the correct units, it is mmol/L and mEq/L (I think mEq/L is used more in the US, mmol/L in Europe if I remember right.) BTW, here's a reference that talks about the unit conversion for this: http://unitslab.com/node/50 From what I remember talking to our clinicians, this is not always a straight forward calculation because it depends on the solution (I think)?
Kelly Watson (Feb 13 2019 at 16:35):
Good to see some nightscout/openaps'ers on this thread :wave:
Last updated: Apr 12 2022 at 19:14 UTC
