Stream: implementers
Topic: Wearable devices
Michele Mottini (Nov 20 2018 at 16:54):
Does anyone have example or guidance on how to represent wearable devices (Apple Watch, FitBit) using the Device resource ? (Or another resource if more appropriate?)
Grahame Grieve (Nov 21 2018 at 05:07):
this is FAQ enough that there should be examples
Grahame Grieve (Nov 21 2018 at 05:07):
@Eric Haas does openMHealth define codes for these?
Eric Haas (Nov 21 2018 at 20:46):
Omh describes them in the header schema using a text There isn’t a formal code system defined for it but that is a good suggestion. One thing is that these device come and go and is hard to keep up.
Eric Haas (Nov 21 2018 at 20:49):
I’m writing a mapping guide and will add a extensible code system.
Michele Mottini (Nov 21 2018 at 22:47):
Thanks!
Grahame Grieve (Nov 22 2018 at 04:20):
Should LOINC track these thing?
Eric Haas (Nov 26 2018 at 16:48):
What things? Consumer devices?
Michele Mottini (Nov 26 2018 at 17:03):
Consumers devices and the data they generate - how to code it
Craig McClendon (Nov 26 2018 at 18:10):
I think in a lot of cases the Observation codings are defined.
For example, some codes I've used for activity monitor Observations are:
LOINC 41950-7 "Number of steps in 24 hour Measured"
UCUM unit: {steps}/(24.h)
LOINC 41979-6 "Calories burned in 24 hour Calculated"
UCUM unit: kcal/(24.h)
What does not seem to exist is a device classification which would fit Device.type.
But since these devices have such varying capabilities, it would have to be something pretty generic like "personal activity tracker" or some such.
Michele Mottini (Nov 29 2018 at 17:21):
To map data coming from Apple HealthKit we came up with this: https://docs.google.com/spreadsheets/d/1BtfVd8YL4yXMye3GdENyWYlD3J0fcLo8ymhGlPL29u0/edit?usp=sharing
Michele Mottini (Nov 29 2018 at 17:22):
We found LOINC codes for everything except DietarySugar
Michele Mottini (Nov 29 2018 at 17:22):
(comments / suggestions welcome!)
Mikael Rinnetmäki (Dec 02 2018 at 06:31):
Great resource @Michele Mottini, thanks! Some initial feedback:
For HKQuantityTypeIdentifierBloodGlucose https://developer.apple.com/documentation/healthkit/hkquantitytypeidentifierbloodglucose?language=objc says
Blood glucose samples may be measured in mg/dL (milligrams per deciliter) or mmol/L (millimoles per liter), depending on the region.
So the code may also be 15074-8 Glucose [Moles/volume] in Blood. You should check it entry by entry, I believe. The same thing with units may apply also to other things too...
Do you have a reasoning for selecting the ultra sound version for HKQuantityTypeIdentifierWaistCircumference? I believe most entries in Apple Health would rather be 8280-0 Waist Circumference at umbilicus by Tape measure (there are more specific methods in LOINC too...).
The vital signs profile https://www.hl7.org/fhir/observation-vitalsigns.html asks you to record blood pressure as a panel in FHIR, with components.
Many of the nutrient intake LOINC codes you use are for 24h intake. I believe Apple Health stores those values as point-in-time entries (for instance, when a meal logging app stores an entry per meal), and then suggests you to calculate the 24 h cumulative values if required (https://developer.apple.com/documentation/healthkit/hkstatisticsquery?language=objc). I'd like there to be codes in LOINC for point-in-time entries for macro and micronutrients and am willing to work on that a bit if anyone else is interested.
Still on the nutrient intake, you're using the Measured variants of the LOINC codes. My assumption is that a majority of entries in Apple Health would rather be Estimated. Any views on this?
Finally, regarding the Dietary Sugar, the closest I can think of is 81050-7 Sucrose intake 24 hour Measured (or, again, the estimated version 81049-9 Sucrose intake 24 hour Estimated). Not sure whether HKQuantityTypeIdentifierDietarySugar would include lactose too...
Michele Mottini (Dec 02 2018 at 14:48):
Thanks @Mikael Rinnetmäki ! That's great feedback.
Michele Mottini (Dec 02 2018 at 14:50):
I confess I am not the author of that table - I know very little about coding, I'll rely your suggestion and question to the coding experts at my place - and thanks again
Michele Mottini (Dec 02 2018 at 15:03):
@Ricky Bloomfield @Pascal Pfiffner would Apple be interested in a standard mapping from HealthKit to LOINC codes? (See above) Or maybe one already exists?
Ricky Bloomfield (Dec 03 2018 at 05:04):
Hey @Michele Mottini! If you go to the avatar icon on the "Today" tab of the Health app, you can choose to "Export Health Data." This may take awhile if you have lots of data there. Once that process is finished, AirDrop it to your Mac (or send it some other way) and you will find a CDA file called export_cda.xml. This file does encode your health data as LOINC where possible. This is an older, somewhat hidden feature that predates me, but please check it out. We'd be happy to get your feedback.
Michele Mottini (Dec 03 2018 at 14:18):
Cool, thanks @Ricky Bloomfield
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 05 2019 at 13:17):
Apologies, late to the conversation about LOINC. @Mikael Rinnetmäki @Eric Haas @Grahame Grieve @Michele Mottini @Ricky Bloomfield fyi
Regarding Health app (and HealthKit) naming of lab results (aka observations), why are folks changing the name from the original name provided by the performing laboratory? In doing so, meaning may be lost like the old "telephone game."
As a LOINC Committee Member concerned about some recommended implementations of LOINC names in FHIR apps. LOINC LONG Common Name (LLN) was NOT designed to be used as a laboratory order or result name, such as promoted in some developer videos. The LOINC code and name representing the code is designed to be mapped to the performing laboratory’s test name for the order or result, sometimes referred to as the local name. The LOINC User’s Manual indicates LLN are not user-friendly. Further, on page 59 in the latest version (LOINC release 2.65 December 2018), “we have always expected that users would link their own local preferred names to LOINC terms for use in reports and displays.” Sharing as it would be great if the developer community would promote Best Practice Usage of LOINC.
On page 122 of the LOINC User’s Guide, there is guidance in using the LOINC Long Common Name especially in HL7 messaging (no matter the version: v 2.51, FHIR, v3, etc.). “Furthermore, we recommend the simultaneous communication of the sender’s local code and local name (in addition to the LOINC code and name) as allowed in the messaging structure to facilitate debugging and detection of mis-mappings. Laboratory local codes are often required to be sent by the performing laboratory to meet CLIA (U.S) and laboratory accreditation regulatory requirements in many countries.” Also, “It is also worth noting that use of the Long Common Name in messaging does not dictate which test name is displayed in user interfaces to clinicians. There are often regulatory requirements and/or local policies that influence what is shown to clinicians. Many of the implementations around the world using LOINC have a local “interface name” that users see.”
One of the challenges with laboratory data is two laboratories may use the same description for a test, but they are performed differently (units, methods, specimens, etc) and thus would have different LOINC codes. The opposite is true, two different names (say, CBC or Complete Blood Count and ABC for Automated Blood Count) may be used by two labs and if performed the same way would have the same LOINC. This is the value of LOINC, helping to distinguish test results or orders, especially to avoid comingling results that have clinically significant differences and impacts on patient care. (One wouldn't comingle a temperatures such as 32 C and 32F on the same scale as they have vastly different implications too!)
In short, best practice is for the performing laboratory name to be sent in messages, but it may be mapped to the LOINC code accompanied by the LLN in messages as the human readable LOINC description to facilitate identification of accurate mappings. Do note, that in some countries, they have their own coding system which is utilized/required instead of LOINC. LOINC can be successfully used to map to laboratory test orders and results behind the scenes so that the data is structured and encoded and available for use in clinical decision support, precision medicine, population health and other downstream applications.
Happy LOINCing :)
Mikael Rinnetmäki (Mar 05 2019 at 14:02):
@Andrea Pitkus, PhD, MLS(ASCP)CM, CSM Thanks for the feedback.
The way I've understood it, none of the data in the google sheet linked by @Michele Mottini originate from a laboratory. Rather, they are entries from wellness apps.
I believe some of those wellness apps would be happy to use LOINC codes too, or it would be nice if Apple included LOINC codes to its framework. But currently, there is no "original name provided by the performing laboratory".
Mikael Rinnetmäki (Mar 05 2019 at 14:02):
The other thing is that I don't think a LOINC code exists for most of the data, especially Point of Time measurments of micronutrients.
Ricky Bloomfield (Mar 05 2019 at 16:43):
Apologies, late to the conversation about LOINC. Mikael Rinnetmäki Eric Haas Grahame Grieve Michele Mottini Ricky Bloomfield fyi
Regarding Health app (and HealthKit) naming of lab results (aka observations), why are folks changing the name from the original name provided by the performing laboratory? In doing so, meaning may be lost like the old "telephone game."
As a LOINC Committee Member concerned about some recommended implementations of LOINC names in FHIR apps. LOINC LONG Common Name (LLN) was NOT designed to be used as a laboratory order or result name, such as promoted in some developer videos. The LOINC code and name representing the code is designed to be mapped to the performing laboratory’s test name for the order or result, sometimes referred to as the local name. The LOINC User’s Manual indicates LLN are not user-friendly. Further, on page 59 in the latest version (LOINC release 2.65 December 2018), “we have always expected that users would link their own local preferred names to LOINC terms for use in reports and displays.” Sharing as it would be great if the developer community would promote Best Practice Usage of LOINC.
On page 122 of the LOINC User’s Guide, there is guidance in using the LOINC Long Common Name especially in HL7 messaging (no matter the version: v 2.51, FHIR, v3, etc.). “Furthermore, we recommend the simultaneous communication of the sender’s local code and local name (in addition to the LOINC code and name) as allowed in the messaging structure to facilitate debugging and detection of mis-mappings. Laboratory local codes are often required to be sent by the performing laboratory to meet CLIA (U.S) and laboratory accreditation regulatory requirements in many countries.” Also, “It is also worth noting that use of the Long Common Name in messaging does not dictate which test name is displayed in user interfaces to clinicians. There are often regulatory requirements and/or local policies that influence what is shown to clinicians. Many of the implementations around the world using LOINC have a local “interface name” that users see.”
One of the challenges with laboratory data is two laboratories may use the same description for a test, but they are performed differently (units, methods, specimens, etc) and thus would have different LOINC codes. The opposite is true, two different names (say, CBC or Complete Blood Count and ABC for Automated Blood Count) may be used by two labs and if performed the same way would have the same LOINC. This is the value of LOINC, helping to distinguish test results or orders, especially to avoid comingling results that have clinically significant differences and impacts on patient care. (One wouldn't comingle a temperatures such as 32 C and 32F on the same scale as they have vastly different implications too!)
In short, best practice is for the performing laboratory name to be sent in messages, but it may be mapped to the LOINC code accompanied by the LLN in messages as the human readable LOINC description to facilitate identification of accurate mappings. Do note, that in some countries, they have their own coding system which is utilized/required instead of LOINC. LOINC can be successfully used to map to laboratory test orders and results behind the scenes so that the data is structured and encoded and available for use in clinical decision support, precision medicine, population health and other downstream applications.
Happy LOINCing :)
FYI, in the current version of the Health app the lab display name (as determined by the health system) is shown as the primary name if available.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 05 2019 at 16:48):
@Mikael Rinnetmäki Thanks for clarifying more about the use cases!
Seems like there are two needs:
1. Name for observations/results provided by health apps/devices outside of hospital/traditional healthcare settings where similar data are collected in the EHR or LIS (lab information system). Seems like a very similar data model to Point of Care Testing (POCT) where outside of lab devices create data from the analysis of patient specimens or devices used on the floor in patient care or patient observations (height, weight, temperature, etc.)
2. LOINC codes for these items, especially those that are app/device generated (i.e. proprietary methods or calculations) to distinguish external devices/app generated data which is different/has a different "trust" level by health professionals than those that are generated in healthcare settings by healthcare professionals.
Have LOINC codes been requested from Regenstrief Institute for these emerging methods, devices, models? If not, recommend they are requested to distinguish results/data generated. It would also help folks to understand which results are comparable and which are not.
Some additional questions:
1. Are there other needs/reasons for using LOINC in the apps/devices?
2. Is there a desire to integrate the data codified at it's point of origin in the device/app with EHRs or other information systems for patient reporting of Patient Generated Health Data (PGHD) or Social Determinants of Health (SDH)?
If so, highly recommend the data is structured and codified at point of origin in the device or app and indicate (via LOINCs, SNOMED CT codes or other code systems depending on the type of data) so they can be shared, integrated in other software systems. There has been much discussion with the American Hospital Association nd others on SDHPGHD uses, integration, etc.
3. Are said devices/apps intended to be used clinically for monitoring health or only as "entertainment" (sharing self reported achievements more on social media)?
If more clinical, recommend ensuring quality of data where possible, quality checks on data models, etc. to ensure said data is clinically accurate, especially if it will be shared with providers.
As an example, I wear both a fitness device and my Apple Watch during workouts. Both measure activity, exercise time, heart rate, etc. However, each has their own proprietary method acquiring/originating these data. How do I and my physician (if shared) know if the data are comparable or not? If I'm just measuring how long I exercised, it's not as important clinically, other than I'm achieving minimum clinical guidelines each week/day. However other data may have more of a trust level, especially those who have gotten FDA approval in the US (and similar approvals in other countries)
4. Per the Apple comment, I'd be happy to chat with them on recommended Best Practices for use in the Health Kit of terminologies, code systems to help customers and developers achieve their needs. (I've worked for a terminology vendor and CAP, who created SNOMED CT in the past, and am on the LOINC Committee and LOINC mapping expert.)
5. If further clarification is needed with the FHIR resources for developers to guide to Best Practice implementations, feel free to share so they can updated, added into implementation guides, and the like.
Cheers, Andrea
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 05 2019 at 16:52):
@Ricky Bloomfield That is fantastic to hear!
Often, in the US, the performing laboratory's name (if you look at their CLIA Specimen Collection Manual/Test Compendium/Menu) is different from the EHR naming conventions so information may be "lost in translation."
Grahame Grieve (Mar 05 2019 at 17:44):
@Andrea Pitkus, PhD, MLS(ASCP)CM, CSM I'm not entirely sure what's driving this. From a FHIR pov, things are clear:
-
LOINC codes are almost always carried in CodeableConcept. That has a .text which we encourage to be populated and used for display of it's present.
-
lots of observations source from devices / companies outside the LOINC eco-system. We've imposed a low granularity LOINC code on all vital signs, but not on anything else
Grahame Grieve (Mar 05 2019 at 17:45):
A lot pf apps, and devices, otoh, are outside the LOINC eco-system. But just because they are not as high quality as you/we would like does not mean that they are not useful
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 05 2019 at 19:55):
@Grahame Grieve can you elucidate what "this" is?
(Should preface below is mostly with lab data/Lab LOINC)
-Concur LOINCs should be in Codeable Concept.
Seen instances where LOINC names are used as the Concept Name/Description for the Observation, Service Request, etc. Suspect the reason folks are using LOINC names is they need a name for their observation/service request in their apps/devices. Ideally, the names/descriptions for user facing app GUIs would not be a LOINC name, but use LOINC names behind the scenes as described in the LOINC User Guide.
If folks are using LOINC for this purpose, would expect they would follow Best Practices of using LOINC. The LOINC User Guide indicates the intention is to be mapped to a "Concept" Name with the LOINC Name used for troubleshooting mapping, exchanged in messages, stored in the database, etc. In other words, the LOINC name shouldn't be the sole name used for the concept/description of an observation/service request, especially laboratory data. Discussion at Laboratory LOINC meetings have also indicated that LOINC Short Names should not be used for displays as they are cryptic and a patient safety issue. LOINC does now have Display Names, but they may or may not meet some use cases/needs.
-Also recognize other terminologies might be used in implementations, especially for countries which require another code system/terminology system., both for the "display" name and to what it is mapped.
Grahame Grieve (Mar 05 2019 at 19:57):
"this" = your comments. Generally, I think that what say makes sense for a lab (I was a lab weenie once) but outside that - specially in newbies - there's no framework for a better name than what LOINC provides
Mikael Rinnetmäki (Mar 06 2019 at 07:07):
From my part, I haven't seen LOINC names being used as such in apps. Certainly not for consumer-facing apps, and most certainly not for any consumer-facing apps intended for wide international distribution. LOINC does not provide enough localized terms, which I guess is at least partly intentional. For clinician-facing apps the situation might be different.
Mikael Rinnetmäki (Mar 06 2019 at 07:07):
In Finland we have a separate working group localizing the LOINC terms. I believe they do follow the LOINC best practices, as do the app developers relying on those localizations.
Mikael Rinnetmäki (Mar 06 2019 at 07:08):
And in Finland we also do have many regional codes and codes used by certain laboratory systems, and we do want to present those to clinicians as well. But we're also using LOINC to harmonize those codes.
Mikael Rinnetmäki (Mar 06 2019 at 07:21):
@Andrea Pitkus, PhD, MLS(ASCP)CM, CSM regarding your question 2 on whether codes have been requested from Regenstrief Institute, I do know some codes were passed through that process, for instance 82290-8 Frequency of moderate to vigorous aerobic physical activity.
I'd be happy to learn more about the process, though. If we'd for instance want to have LOINC codes defined for point-in-time micronutrient intake (the use case being that I'm using a meal logging app and enter all the data from the nutrition information label on a pre-packaged meal, for instance). In essence, we'd likely map all the codes in 81941-7 Micronutrient intake panel to point in time measurements, instead of the 24h summary measurements that already have those codes. How would that process go, and would it be enough to just propose these to be added, with this kind of a justification and description of the use case, or should someone then drive the process more actively?
Mikael Rinnetmäki (Mar 06 2019 at 07:32):
@Andrea Pitkus, PhD, MLS(ASCP)CM, CSM and regarding your additional questions;
1. For instance in comparison to Snomed CT, LOINC has a wider global reach across markets.
2. Yes, there is a desire to integrate data from apps and devices with EHR. Yes, it needs to be codified. That's one of the reasons why FHIR is interesting for app vendors.
3. Both do exist. The more clinically relevant are more interested in FHIR, LOINC, and Snomed CT at the moment. Quality checks have been discussed in some communities I've been involved in, but I feel that's a bit separate topic. The consensus that I've seen so far is that he healthcare professionals should understand the quality of the data in general (9851 steps taken does not necessarily mean exactly 9851 physical steps performed by the individual wearing the device), and I believe for the most part they already do. Anyway, this has more to do with how that data is actually used in healthcare setting.
4. I can't speak for Apple, but as you can read from this thread, some people in the community would see value in having the data in Apple Health having LOINC codes.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 06 2019 at 21:40):
It's true that there is no global standardized naming convention for lab tests or some other clinical data for that matter. There are terminology companies that provide interface terminology to fill that gap and provide human friendly/readable terms that are often better suited than some of the descriptions for code systems.
Even from a lab perspective, it would be nice that all instances say of a particular test result from a instrument/POCT device/performing lab, you'd think would have the same naming convention no matter which provider ordered it, which EHR the results appeared in, etc. Sadly, this is not the case. The LOINC names are not designed for GUIs either, except for display names depending on the use case. I wouldn't use "what's available" just because it's available unless it meets use case needs. Further, use of the LOINC name for GUIs isn't how it was intended to be used according to the User Guide. I'll also say for some clinical terms, the LOINC descriptions may be simple, short, clear and be used for some data items. It's variable.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 06 2019 at 22:12):
Regarding LOINC requests...
1. see https://loinc.org/submissions/
2. would check to make sure someone else hasn't already requested term here: https://loinc.org/submissions/queue/ or here: https://loinc.org/prerelease/ (usually updated monthly with next release items)
3. Submissions can be made via processes outlined here: https://loinc.org/submissions/new-terms/
3a. Using RELMA
3b. Using new term request form (beta) https://loinc.org/submissions/request/
4. Some of the info may not apply as it tends to be lab specific. However, it gives you an idea of what is needed: https://loinc.org/submissions/new-terms/ As vendor/developer, would describe the data you create with the app/device and how it is similar or different from other LOINC codes.
5. With the micronutrient intake panel, it seems reasonable to have the point in time results/panel. Will preface that I'm not on the team that creates LOINC so those folks will ultimately decide. They also may ask clarifying questions. It might be helpful to know this is patient reported or performed on a specific device too with these new types of Patient Generated Health Data (PGHD) or Social Determinants of Health (SDH).
Best,
Armin Griebler (Jul 01 2020 at 06:30):
Hello, I've got a question about Loinc-Codes and Wearables. For example, if you want to represent a sleep hypnogram using a common wearable device, from a "medical point of view" there would be the Loinc-Code 28633-6 "Polysomnography (sleep) study". But wouldn't such a code be a bit too specific for wearable devices? How to decide, whether a code is to specific or not? Or would a code, as described in the example, be okay anyway?
Last updated: Apr 12 2022 at 19:14 UTC
