FHIR Chat · vitals profile, LOINC and PCHA / Continua guidelines · implementers

Stream: implementers

Topic: vitals profile, LOINC and PCHA / Continua guidelines

Eric Haas (Jul 27 2017 at 21:10):

This is a new chat to follow up on GF#13652. To set the context OO committee has discussed this before GForge and Zulip and remains steadfast in resisting loosening the requirements on the vitals profiles. Only new information specific to PHD should be discussed that may be important factors in reconsidering our stance. So review the above links before contributing.

Lloyd McKenzie (Jul 28 2017 at 04:05):

Could we carve out a specific exception for medical devices? That doesn't mean we need to, but it's certainly a lesser evil than removing the requirement in general.

Lloyd McKenzie (Jul 28 2017 at 04:06):

(And if we keep the requirement, there'd be a need for a service that injects the LOINC translations for data received from a device.)

Erik Moll (Jul 28 2017 at 07:21):

(deleted)

Erik Moll (Jul 28 2017 at 07:22):

I am copying here some relevant messages from the email thread on this in IEEE PHD / PCHA:

The actual problem is that the FHIR base spec is requiring LOINC for Vital Signs. That is the only requirement the base spec is making for the case we are concerned about. What should be happening instead is that coding schemes are mandated in profiles.

Right now the PCHA profiles are requiring 11073 10101 codes (since they are provided by the device) and allowing translations to any other coding system as desired. Unfortunately the current FHIR spec requires that I add to this profile that if a vital sign, I have to mandate a translation to LOINC as well as the 11073 code in order to be FHIR compliant.

Brian Reinhold, LNI
===
This requirement should go wider, as many countries that have adopted other coding schemes, such as SNOMED, will also not want to follow a mandated LOINC encoding. It appears US centric - there should not be a mandated coding in a message protocol of this type, as it will be completely geographic or organisation specific.
Regards

Malcolm Clarke, Brunel
===
I agree with Brian’s comment about profiling. This is my understanding for the typical use case and requirement for FHIR profiling.

Unfortunately, I cannot attend to support this point.

Nathaniel Hamming
Consultant
HMT Consulting
Systems Engineer

On behalf of:
Roche Diabetes Care GmbH
DCRDII..6918
Sandhofer Strasse 116
68305 Mannheim/Germany
===
Hi Erik,

Just a brief note to thank you for your proposal to include 11073 Nomenclature in the FHIR Nomenclature repertoire. It might help to note that 11073 Nomenclatures include the general standard, 10101, as amended (10101a with 10101b well along the way); 10102 (Annotated ECG); 10103 (Implantable Cardiac Devices); as well as a number of subsets in the 104xx-series related to Personal Health Devices [PHD]; most of these are approved IEEE and ISO standards.

In general, I don't see the advantage to a general methodology like FHIR to restrict semantic scope and see a lot of potential advantage to facilitating growth of application scopes, esp, w.r.t. specialized medical device nomenclature/semantics. In addition, there have been LOINC-11073 nomenclature harmonization activities ongoing for some time and expected in future to facilitate pre-coordination of common semantics for applications that can avail of higher-use subsets where semantic equivalence is beneficial.

Please keep us posted on progress.

Best regards, /Jan Wittenber (IEEE PoCD chair)
===

Hello all

I share this concern. In particular the use of LOINC requires acceptance of a Regenstrief Licence which is permissive with caveats. A magic value, as proposed by Richard Kavanagh, would not require licence acceptance for this use case and would avoid favouring one code system over another.

Nicholas Oughtibridge BSc FBCS CITP
Committee Chairman – BSi Information Systems Technology / Health Informatics
+44 113 397 4296
nicholas.oughtibridge@bcs.org.uk
===

Grahame Grieve (Jul 28 2017 at 07:23):

I don't understand the value of using a magic code from yet another coding system, so as not to favour one coding system over another.

Grahame Grieve (Jul 28 2017 at 07:24):

the decision is not US centric.

Grahame Grieve (Jul 28 2017 at 07:25):

Note also that the profile does not restrict semantic scope in any sense at all

Grahame Grieve (Jul 28 2017 at 07:29):

I'm thinking about Richard's point about acceptance of a Regenstrief license. @Daniel Vreeman say someone is required by HL7 to put LOINC codes in their Observation resources because of these profiles, are they required to enter into any agreement with Regenstrief? I've just read the license agreement twice and I can't decide..

Stefan Sauermann (Jul 28 2017 at 08:54):

This is a new chat to follow up on GF#13652.

Stefan Sauermann (Jul 28 2017 at 08:59):

Since 2015 we have had thorough discussions with stakeholders in Austria and throughout Europe on the IT architecture for telemonitoring, from the nordics down to Spain, from implementers in large companies to high levels in ministries and regions, as well as healthcare providers. The agreement in all domains in 2016 was to use the PCHA / Continua guidelines, to collect values from mobile and home devices. IHE XDS with CDA payloads (HL7 CDA personal healthcare Monitoring report PHMR, uses 11073 nomenclature as well) was then agreed as a useful means to receive the data in the healthcare provider space. Everybody is now waiting for the missing link, FHIR, to connect mobile devices into the server space. Based on this available and proven standards landscape, there is strong (political) motivation to implement, and large investments are on the move in Austria and elsewhere.
The IEEE codes are an integral part of these concepts, agreed between the relevant SDOs ISO, CEN, IHE, HL7, and PCHA. We have strong implementer agreement and experience that the IEEE 11073 nomenclature covers the requirements. The choice to confirm IEEE 11073 nomenclature for telemonitoring vitals signs in Austria considered experience with LOINC from our work on the CDA laboratory report implementation guide in the context of the Austrian national EHR (ELGA).
LOINC as the only mandated nomenclature, and only allowing IEEE 11073 terms as mappings is a severe change in a substantial and well agreed long term position. A change in direction at this point in time will likely have a large impact on many communities worldwide. It may slow down the momentum towards large scale implementation that we have built up successfully over years.
Greetings from Vienna!
Stefan Sauermann

Program Director
Biomedical Engineering Sciences (Master)
University of Applied Sciences Technikum Wien
Hoechstaedtplatz 6, 1200 Vienna, Austria
stefan.sauermann@technikum-wien.at
https://mahara-mr.technikum-wien.at/user/sauermann

Grahame Grieve (Jul 28 2017 at 09:37):

There's a lot of confusion about this. "LOINC as the only mandated nomenclature, and only allowing IEEE 11073 terms as mappings is a severe change in a substantial and well agreed long term position" is not a good reflection of what we've said. in fact, what we've said is: use whatever code you want, driven by local / contextual considerations. But in addition, provide a mapping to a coarse granularity LOINC code, so that everyone can consistently find all the observations. So in fact, our position is really the other way around

Brian Reinhold (Jul 28 2017 at 09:39):

To add to the general discussion on the same topic I wish there was no such thing as 'extensible' coding systems in the spec as this, too, puts a burden on the encoder. In PCHA PHD profiles, the IEEE coding system is used as it is provided by the device reducing the need and size of code dictionaries on the collector and FHIR encoder. Readers of PCHA PHD profiles will need an IEEE dictionary so in all cases IEEE codes are placed first in any coding element if the IEEE code exists. So the reader can look at entry[0] and not go further. However, for those 'extensible' codes, like the productionSpecification in the DeviceComponent (which shows how the IEEE codes map to the specified coding system), the encoder will have to carry both. That may not be a big deal in enterprises but it is in remote patient monitoring where low cost embedded chips for collector units are sometimes needed and upload bandwidth is a cost issue.

Stefan Sauermann (Jul 28 2017 at 09:40):

Note also that the profile does not restrict semantic scope in any sense at all

Dear Graham,
(sorry if I am slow to understand)
If LOINC is mandatory, then I understand that other codes only are allowed if a mapping to LOINC exists. I feel that this restricts the semantic scope. I may be completely in the dark. Can you please clarify probably with an example?

Grahame Grieve (Jul 28 2017 at 09:46):

what we say is, for instance, that if an Observation is a heart rate observation, it must have the LOINC code 8867-4 ('Heart Rate'). We've said nothing about what other codes it may or may not have. So you could see this in an Observation:

Stefan Sauermann (Jul 28 2017 at 09:47):

in fact, what we've said is: use whatever code you want, driven by local / contextual considerations. But in addition, provide a mapping to a coarse granularity LOINC code, so that everyone can consistently find all the observations.

Sounds perfectly reasonable. (Please excuse my ignorance of the FHIR specification space) I am very grateful to learn. Thanks for the examples

Grahame Grieve (Jul 28 2017 at 09:48):

<Observation>
  <code>
    <coding>
      <system value="http//acme.org/private/codes"/>
      <code value="private-code-you-dont-know"/>
    </coding>
  </code>
  <code>
    <coding>
      <system value="http//loinc.org"/>
      <code value="8867-4"/>
    </coding>
  </code>
</Observation>

Stefan Sauermann (Jul 28 2017 at 09:48):

if an Observation is a heart rate observation, it must have the LOINC code 8867-4 ('Heart Rate').

What happens if there is no LOINC code?

Grahame Grieve (Jul 28 2017 at 09:49):

then it's not conformant

Brian Reinhold (Jul 28 2017 at 09:49):

@Stefan Sauermann LOINC codes are mandated in the sense one has to include in the 'coding' element of a CodeableConcept a LOINC expression. To deal with this in the PCHA PHD profiles I require that the IEEE code is placed in the first 'coding' element, and if a vital signs, the LOINC code for that vital sign (as specified in FHIR) is put in the second, and any alternative codes are placed in subsequent elements (recall a coding element has a [0..*] cardinality so it makes a JSON array, for example).
The LOINC code is specified by FHIR, so if the vital signs is a pulse rate, it is always of value X (I don't recall what it is and I am too lazy to look it up). However the IEEE code will indicate that the pulse rate may be from an ECG, Blood Pressure Cuff, pulse ox, or cardio device all of which may have different LOINC codes. THose LOINC codes are not used here, only the fixed value X. What I personally do not like is being required to add that bulk into my code and I know I am going to have to stick this on some limited resource C-based embedded chip.

Grahame Grieve (Jul 28 2017 at 09:50):

we've said nothing about other codes 'needing a mapping' to loinc (there's many things that might mean). One would assume that if the source marked the observation as a heart rate, it has some grounds for doing that, and there's an implied mapping, but we've not made any rules about how that must be

Grahame Grieve (Jul 28 2017 at 09:51):

brian: we don't like extensible bindings either. But welcome to the real world.

Grahame Grieve (Jul 28 2017 at 09:51):

as for concerns about bulk: yes. there is an extra 60-80 bytes, true.

Grahame Grieve (Jul 28 2017 at 09:52):

I was assured that no one would ever put FHIR support on an embedded chip. is that advice wrong?

Grahame Grieve (Jul 28 2017 at 09:52):

and yes, we expect that there will be a variety of IEEE codes etc for the different flavors of heart rate etc. There's lots of information here.

Brian Reinhold (Jul 28 2017 at 09:53):

if an Observation is a heart rate observation, it must have the LOINC code 8867-4 ('Heart Rate').

What happens if there is no LOINC code?

@Stefan Sauermann Recall this is only for vital signs, so it is only 8 items last count. Unfortunatley, most PHDs currently out there do measure vital signs in one form or another. The ubiquitous Glucose meter is the exception.

Grahame Grieve (Jul 28 2017 at 09:55):

so I think that one of the problems here is that people are saying 'we mandated LOINC coding'. I hope I've made it clear that we haven't, at all, mandated LOINC coding. We've mandated a magic LOINC code to identify some observations consistently, where the magic code is not a great code for the observation

Grahame Grieve (Jul 28 2017 at 09:55):

you might argue we've done the opposite from 'mandating loinc coding'

Stefan Sauermann (Jul 28 2017 at 09:56):

I was assured that no one would ever put FHIR support on an embedded chip. is that advice wrong?

We have immediate requirements for embedded implementations e.g. in home care. On the short term embedded without user interface is the only way to achieve adequate privacy and IT security, as long as mobile platforms are not secure enough for healthcare services. We expect many medical device vendors (blood pressure, ECG, whatever) will transmit directly to the server using FHIR, via GSM, G4, etc. using a SIM card to authenticate and encrypt.

Brian Reinhold (Jul 28 2017 at 09:56):

<Observation>
<code>
<coding>
<system value="http//acme.org/private/codes"/>
<code value="private-code-you-dont-know"/>
</coding>
</code>
<code>
<coding>
<system value="http//loinc.org"/>
<code value="8867-4"/>
</coding>
</code>
</Observation>

@**Grahame Grieve**  Not to be picky but is that xml correct? Should it be
<Observation>
  <code>
    <coding>
      <system value="http//acme.org/private/codes"/>
      <code value="private-code-you-dont-know"/>
    </coding>
    <coding>
      <system value="http//loinc.org"/>
      <code value="8867-4"/>
    </coding>
  </code>
</Observation>
In JSON I am doing something that would map to the above.

Grahame Grieve (Jul 28 2017 at 09:57):

yes whoops. good pick up

Grahame Grieve (Jul 28 2017 at 09:58):

@Stefan Sauermann I think you're saying that people will be putting FHIR support in an embedded chip

Stefan Sauermann (Jul 28 2017 at 10:00):

@Stefan Sauermann I think you're saying that people will be putting FHIR support in an embedded chip

I am! :)
That is also what many global device vendors keep telling me.

Brian Reinhold (Jul 28 2017 at 10:03):

@Stefan Sauermann I don't know how soon it will be that sensor devices will be on embedded chips but collector units certainly will be. I have already done collectors using PCD-01. An equivalent FHIR implementation would be more costly but if one can restrict the variability and limit the number of resources it could be done with templating. It certainly will not support a FHIR library or xml library unless one starts shelling out many euro for that chip (more euro than one is willing to pay). However, memory and code size is always a challenge and the fewer the options and the simpler the template, the easier and cheaper it will be.

Grahame Grieve (Jul 28 2017 at 10:06):

I expected that this would be an impost on collectors, not on the devices.

Stefan Sauermann (Jul 28 2017 at 10:07):

@Brian Reinhold I agree. That is the picture I get as well. My feeling is also that a product may combine sensor device(s) and a collector unit.

Grahame Grieve (Jul 28 2017 at 10:07):

anyway, we are talking 72-73 bytes here

Grahame Grieve (Jul 28 2017 at 10:07):

is it that much of a problem?

Brian Reinhold (Jul 28 2017 at 10:10):

I expected that this would be an impost on collectors, not on the devices.

@Grahame Grieve You are correct, this would be a demand on collectors. Many devices are too power-sensitive to support anything more than byte protocols. In addition, manufactures want to spend their device dollars on the sensor and not the transport code.

Grahame Grieve (Jul 28 2017 at 10:10):

right.

Stefan Sauermann (Jul 28 2017 at 10:11):

is it that much of a problem?

Hm. I think, even some bytes are a pain, if there is no hard requirement that they are required. For the last decade embedded implementers have successfully used and are happy with the IEEE nomenclature. They now ask us (naturally) why they should also include LOINC. What is the additional requirement?

Grahame Grieve (Jul 28 2017 at 10:11):

and what have you said in response?

Stefan Sauermann (Jul 28 2017 at 10:12):

and what have you said in response?

so far I did not have to respond. So far LOINC was not on the table. It was only IEEE 11073.

Grahame Grieve (Jul 28 2017 at 10:13):

so the situation we are currently in is that observations are coded with a dizzying array of codes from lots of coding systems. This is not only costly for anyone trying to aggregate the observations, it's dangerous, because they can never close their work.

Grahame Grieve (Jul 28 2017 at 10:14):

of course, it's great for the generator of the observation. They just create the observation, through it over some wall, and shrug. Whatever happens after that is not their cost.

Grahame Grieve (Jul 28 2017 at 10:14):

except it is....

Grahame Grieve (Jul 28 2017 at 10:14):

because the value of their output is reduced by the cost of dealing with it downstream.

Grahame Grieve (Jul 28 2017 at 10:15):

so we've said, for vital signs, since there's every prospect of sharing this data widely, and lots of reasons to do so: let's reduce the cost to everyone by tagging them consistently.

Stefan Sauermann (Jul 28 2017 at 10:15):

observations are coded with a dizzying array of codes from lots of coding systems.

Date that comes from mobile medical and health devices is only coded in IEEEE 11073. I see no other nomenclature for that purpose.

Grahame Grieve (Jul 28 2017 at 10:15):

but data comes from all sorts of other sources too.

Brian Reinhold (Jul 28 2017 at 10:16):

anyway, we are talking 72-73 bytes here

@Grahame Grieve That's only part of it. The idea is that collectors work with many devices and the more the collector can utilize what the device provides and the fewer conditional cases the collector has to support, the fewer the number of internal dictionaries and the smaller the code and templates have to be. In PCHA there has been a standard philosophy of "put the burden on the collector if it saves effort on the sensor' and put the burden on the receiver if it takes the burden of the collector. In this case we are putting the burden on the reader of the PHCA profile. Every reader of the PCHA profile will need to understand the IEEE coding system.

Stefan Sauermann (Jul 28 2017 at 10:16):

but data comes from all sorts of other sources too.

Correct. However data from medical devices stays in the same coding space throughout the further chain. See the HL7 CDA PHMR personal health monitoring report.
http://wiki.hl7.org/index.php?title=Personal_Healthcare_Monitoring_Report

Grahame Grieve (Jul 28 2017 at 10:17):

and man, has the prospect of consistent tagging created such a lot of push back. The push back has been on 3 grounds:
- there's no need to share this data
- we don't want to pay the cost - someone else should
- we don't like the choice of the tag

Grahame Grieve (Jul 28 2017 at 10:17):

Brian just neatly expressed the second. But it's a wrong value proposition to shove it downstream, because PHCA is not the only source of this data.

Grahame Grieve (Jul 28 2017 at 10:19):

it increases everyone's costs downstream, because every different source of data refuses to cooperate, and the recipients of the data just have to deal with all the different codings, different granuarity etc.

Grahame Grieve (Jul 28 2017 at 10:19):

and the real problem is, that's not a bounded problem. You've moved it from somewhere where it's a bounded problem - the collector - to somewhere where it's not.

Grahame Grieve (Jul 28 2017 at 10:20):

of course, it's only not bounded if everyone aligns, but right now, there's every prospect that everyone will refuse. So data will continue to be a mess, and consumers will have to deal with the cost and safety issues of this.

Grahame Grieve (Jul 28 2017 at 10:21):

I can't see how we could've made a less invasive proposition to get consistency here: you can still use the code of your choice, etc. You just have to add a magic tag for consistency.

Stefan Sauermann (Jul 28 2017 at 10:22):

At least in Austria, and in all other commmunities I discussed this so far, everybody agreed that they want to have IEEE 11073 codes on all levels, even downstream. See the HL7 CDA PHMR personal health monitoring report. We do not need to force them. they are already there.

Grahame Grieve (Jul 28 2017 at 10:22):

really? so even EHR sourced data? and all the off the shelf devices?

Stefan Sauermann (Jul 28 2017 at 10:23):

I am talking about the telemonitoring use case. In that use ces: Yes.

Grahame Grieve (Jul 28 2017 at 10:24):

ah, so, of course, you can always pick a limted eco-system and argue that global interop is unncecessary because you have agreement internally, and you want to ignore costs and benefits for anyone outside that eco-system. sure

Grahame Grieve (Jul 28 2017 at 10:25):

from my perspective, that's just kicking the can down the road, since such eco-systems are only transiently isolated.

Stefan Sauermann (Jul 28 2017 at 10:25):

The telemonitoring use case also includes situations where a patient monitors at home, then experiences an incident, goes to hospital, and monitoring values continue to come in via a hospital infrastructure.

Grahame Grieve (Jul 28 2017 at 10:25):

but kicking the can down the road is a time-honoured tradition

Stefan Sauermann (Jul 28 2017 at 10:26):

"kicking the can down the road ": What do you mean? I do nto see that here.

Grahame Grieve (Jul 28 2017 at 10:26):

alternatively, you could argue that (a) the device market is sufficiently big and (b) the IEEE code system is well enough defined and freely available and (c) the right codes exist so that we should mandate device codes instead of LOINC codes.

Grahame Grieve (Jul 28 2017 at 10:27):

kicking the can down the road because you get your internal agrement and it's a closed eco-system - but later, you won't be closed, and then you'll have to deal with all the issues that didn't matter when you were closed.

Grahame Grieve (Jul 28 2017 at 10:28):

but I don't think that mandating a single - additional - device code will make any difference here, actually

Brian Reinhold (Jul 28 2017 at 10:28):

@Grahame Grieve Understood. I am just quoting the PCHA philosophy because it is working in a consumer market and sensors devices, collectors, and the cost of bandwidth come out of consumer pockets which make it much more cost-sensitive. Thus the push 'downstream'. There is also future-proofing here. As one could have 1000s of devices being serviced by 100's of remotely scattered collectors sending to a single server. If a new device comes out reporting a vital sign using a new technique (such as a continuous BPM) the existing collectors will not be able to map this to LOINC since it is not in its dictionary. However, the IEEE code is provided by the sensor. So it will work and upload but the LOINC code will be missing. A system update will be needed to fix all the collectors. That puts more demands on the embedded collector.

Stefan Sauermann (Jul 28 2017 at 10:28):

We have dealt with the issue "down the road". the decision is to also use IEEE 11073 codes "down the road". i therefore can not see "kicking down the road elsewhere".

Grahame Grieve (Jul 28 2017 at 10:29):

you assume that every one will use 11073 codes instead of LOINC codes. That seems like an bad assumption to me

Grahame Grieve (Jul 28 2017 at 10:30):

Brian: sure. It's hard. But consider the case for the downstream: they get data from even more sources... and they don't know the codes at all. how's that supposed to work? I think you're just ignoring that problem altogether

Stefan Sauermann (Jul 28 2017 at 10:30):

you assume that every one will use 11073 codes instead of LOINC codes. That seems like an bad assumption to me

We have an agreement in Austria ( and in all communities internationally that I know of) to use IEEE 11073 nomenclature, even downstream. This is an essential part of the concept.

Grahame Grieve (Jul 28 2017 at 10:31):

I can assure that there isn't agreement at all in any international community I know of to use 11073 codes in observations in clinical software

Grahame Grieve (Jul 28 2017 at 10:31):

I know of agreements to use LOINC, and SNOMED

Stefan Sauermann (Jul 28 2017 at 10:31):

I can assure that there isn't agreement at all in any international community I know of to use 11073 codes in observations in clinical software

In the telemonitoring use case: yes.

Grahame Grieve (Jul 28 2017 at 10:32):

maybe you don't count clinical software as downstream

Stefan Sauermann (Jul 28 2017 at 10:32):

maybe you don't count clinical software as downstream

I count the Autrian national EHR and all healthcare professionals (and other international communities) as downstream.

Stefan Sauermann (Jul 28 2017 at 10:33):

That definitely is clinical software. This will also include a large number of decision support, which definitely relies on very detailed coding, as it comes from the devices.

Grahame Grieve (Jul 28 2017 at 10:34):

well, congratulations for getting such agreement in Austria. I find it extremely unlikely that this will be replicated in many countries

Grahame Grieve (Jul 28 2017 at 10:34):

where it's either LOINC or Snomed CT. (or decision in progress)

Stefan Sauermann (Jul 28 2017 at 10:35):

well, congratulations for getting such agreement in Austria. I find it extremely unlikely that this will be replicated in many countries

We have Austria, regions in Spain, Finland Norway, Sweden, the USA (adopted PCDA Contina) and some others, see the PCHA collection.

Grahame Grieve (Jul 28 2017 at 10:36):

USA has agreed that 11073 codes will be used in EHRs? really?

Stefan Sauermann (Jul 28 2017 at 10:37):

USA has agreed that 11073 codes will be used in EHRs? really?

See this: http://www.pchalliance.org/news/continua-design-guidelines-recognized-oncs-2017-interoperability-standards-advisory-isa

Grahame Grieve (Jul 28 2017 at 10:40):

umm, you don't understand the difference between 'communication between device and EHR using 11073 is in the ISA', and 'EHRs will use 11073 codes to identify their observations'?

Stefan Sauermann (Jul 28 2017 at 10:41):

umm, you don't understand the difference between 'communication between device and EHR using 11073 is in the ISA', and 'EHRs will use 11073 codes to identify their observations'?

Please explain.

Grahame Grieve (Jul 28 2017 at 10:43):

'in the ISA' means that ONC have agreed to add their analysis of the standard to their list of standards. This doesn't constitute an endorsement. (Or even praise - depends on their assessment, which I haven't read). Also, ONC can make all the recommendations in the world that system use PCHA, but that doesn't mean that the mapping problems I'm concerned with have any resolution. Let alone that EHRs will start using 11073 codes internally. No, they'll just add it to their mapping problems....

Stefan Sauermann (Jul 28 2017 at 10:44):

I see the following "interoperability needs": Remote Patient Monitoring to Support Chronic Condition Management,
Patient Education, and Patient Engagement
Push Communication of Vital Signs from Medical Devices
!!!!!Medical Device Communication to Other Information Systems/Technologies!!!!
This last one I guess includes EHRs.

Stefan Sauermann (Jul 28 2017 at 10:48):

Let alone that EHRs will start using 11073 codes internally. No, they'll just add it to their mapping problems....

The communities I talked about have decided to use 111073 codes in the EHRs as they process telemonitoring data from devices. There is no need to map for that use case. Of course there are other use casere where LOINC and other codes are needed. For telemonitoring (blood pressure, blood glucose, ...) 11073 is the choice.

Grahame Grieve (Jul 28 2017 at 10:49):

@Jenni Syed @Danielle Friend @Brett Marquard @Eric Haas @Rob Hausam perhaps one of you would like to comment at this point...

Brian Reinhold (Jul 28 2017 at 11:04):

Brian: sure. It's hard. But consider the case for the downstream: they get data from even more sources... and they don't know the codes at all. how's that supposed to work? I think you're just ignoring that problem altogether

@Grahame Grieve Admittedly, IEEE codes are very device-centric. Devices use them because they take only two or four bytes. I suppose that's why PCHA is using them as they are reporting device data. Maybe behind all of this is an ulterior motive from the device community to get HL7 to fully accept the IEEE device codes. But if you think the downstream coding issue is a nightmare you haven't seen anything until you look at the nightmare of getting the sensor devices to behave in a standardized manner. In the field device to collector communication has been a far greater nightmare than any reading of the downstream data. Fixing the latter part is always relatively easy. Better than that is fixable. Fixing the first stage is not easy. In the end requiring the LOINC codes in the spec is probably more against philosophy (it should be done in profiles and not the base spec) but it is doable. Yes it will cost more for the uploader and it may cause future interoperability problems. But compared to the interoperability issues between the collector and device it's a drop in the bucket. I spend 95% of my time trying to figure out why the device-to-collector exchanges don't work right. When I mess up on the FHIR side its usually "oops! I can fix that" and its done.

Brett Marquard (Jul 28 2017 at 11:11):

When working on device-to-collector, how often is it 'code' related? My suspicion is it's other issues -- and this is relatively minor, but happy to be told i am wrong.

Brett Marquard (Jul 28 2017 at 11:13):

"The communities I talked about have decided to use 111073 codes in the EHRs as they process telemonitoring data from devices. There is no need to map for that use case. " Sure directly into EHR works great, but what about when consumer devices connect, who maintains the mapping to LOINC?

Stefan Sauermann (Jul 28 2017 at 11:19):

"The communities I talked about have decided to use 111073 codes in the EHRs as they process telemonitoring data from devices. There is no need to map for that use case. " Sure directly into EHR works great, but what about when consumer devices connect, who maintains the mapping to LOINC?

My feeling is that only some use cases need a mapping to LOINC. Most use cases I can think of (disease managment of diabetes, heart failure, high blood pressure) are fine with IEEE 11073 codes.
11073 codes are more fine grained than LOINC, so mapping IEEE to LOINC is probably easier than LOINC to IEEE? My feeling therefore is that you may be able to bring in LOINC downstream, if needed, on a more coarse grainded level.

Brett Marquard (Jul 28 2017 at 11:22):

maybe a compromise is require for the ~12 vital signs in the spec with the detailed profiles?

Grahame Grieve (Jul 28 2017 at 11:22):

I don't know what that means

Brian Reinhold (Jul 28 2017 at 11:22):

When working on device-to-collector, how often is it 'code' related? My suspicion is it's other issues -- and this is relatively minor, but happy to be told i am wrong.

@Brett Marquard It is almost always code ... somewhere. The question is where. Low level communications like Bluetooth and ZigBee are complex and often involve many parts from the radio to a low level stack and an application layer. All of that has to be done correctly on both sides. In the end one side ends up not implementing the standard correctly and if it is in the device one has to work around it which may not be possible.
But to answer your question it is invariably code. It's just that code exists at many levels and one may not always have access to it. I can give you countless cases of where devices and collector platforms have incorrectly implemented the specifications and you can't fix it because it is out of your control. If life it good, you find a work around in your application layer. Unfortunately, life is not always good.

Brett Marquard (Jul 28 2017 at 11:23):

@Grahame Grieve at http://build.fhir.org/observation-profiles.html - there are 12 specific vital sign profiles

Grahame Grieve (Jul 28 2017 at 11:24):

sure . but what would the compromise be?

Brett Marquard (Jul 28 2017 at 11:27):

I guess I interpreted Stefan's comment that there were lots of other vital signs that wouldn't benefit from including a LOINC code. When I looked at our latest vital signs profile, it appears we always require LOINC...so I thought why not go for the 12 specific profiles. Although, I suspect that folks are feeling it's too much

Stefan Sauermann (Jul 28 2017 at 11:28):

One use case inluding LOINC and IEEE 11073 is that you compare a blood glucose value that came into the EHR from a device to another value that came from a medical lab. In order to do that, you can extract the value from the device message, using the IEEE code. I agree that this may be viewed as a "mapping nightmare". My feeling is however that existing mapping effort already has brought forward a lot of help for exactly that, e.g. between IEEE and Snomed and LOINC, as mentioned.
The feeling I get from experts around is, that they think it can be done, because all involved coding systems (LOINC, IEEE 11073, Snomed) are "well behaved" and good to handle.

Grahame Grieve (Jul 28 2017 at 11:30):

so there's a published map out there is there? where?

Rob Hausam (Jul 28 2017 at 11:31):

Brian Reinhold mentioned earlier that "In PCHA PHD profiles, the IEEE coding system is used as it is provided by the device reducing the need and size of code dictionaries on the collector and FHIR encoder." It seems to me that the "FHIR encoder" (assuming that's an identifiable entity and not only an abstract notion) would likely be the best place for the (relatively small) burden of adding the LOINC codes for the vital signs observations. Wherever it's done, preparing the data to submit directly to a FHIR interface will require some overhead, and it seems that the additional overhead of including the LOINC codes in that context would be pretty minimal. The burden for doing this would (or certainly could) be placed at the "encoder" level, not on the device itself or necessarily in the collector. Would that not be true?

Stefan Sauermann (Jul 28 2017 at 11:37):

@Grahame Grieve at http://build.fhir.org/observation-profiles.html - there are 12 specific vital sign profiles

In that list I find "DeviceMetricObservation". May this be a specific place to enable the IEEE nomenclature, in all its detail? I may be completely wrong, but might I understand this in a way that a devices generates a "DeviceMetricObservation", including the full IEEE codes, and that then somebody derives the other observations, e.g "BodyWeight", following specific mapping rules? There may be "DeviceMetricObservations" that do not map to the other observations.

Grahame Grieve (Jul 28 2017 at 11:39):

so that profile is the PHCD equivalent, owned by devices. I don't really know why it exists, since its effectively a place holder for PHCD

Grahame Grieve (Jul 28 2017 at 11:39):

and I'm sure it's about IEEE nomenclature. but does having it help PHCD?

Grahame Grieve (Jul 28 2017 at 11:40):

but all this ducks the issue - we mandated certain LOINC codes to foster interop, and some people are objecting to having to tag observations to make processing them manageable downstream

Brian Reinhold (Jul 28 2017 at 11:43):

@Rob Hausam That is what is currently done. The PCHA PHD profile at this time requires the addition of the LOINC code when it is a vital sign. On my Android platform, no issue. I make a dictionary of all the IEEE codes that are vital signs (this is a many to one mapping) and when they show up I add the LOINC code to the 'coding' element. The main issue I have here is that if a new specialization is created (such as the continuous Blood Pressure monitor) I will have new set of codes that need to be mapped to that set of LOINC codes. The IEEE codes are provided by the device, but the LOINC codes are not and my dictionary does not know about these codes. This will require updates of all the collectors in the field. Depending upon the platform, this may or may not be easy.

In an embedded collector, the less it needs to do, the cheaper. This includes maintenance which in remote patient monitoring may not be cheap.

Stefan Sauermann (Jul 28 2017 at 11:48):

so there's a published map out there is there? where?

https://loinc.org/collaboration/ieee/ maps between 11073 and LOINC

Brian Reinhold (Jul 28 2017 at 11:50):

so that profile is the PHCD equivalent, owned by devices. I don't really know why it exists, since its effectively a place holder for PHCD

@Grahame Grieve Is that profile not a leftover of old stuff? I recall when I first had a look at FHIR there was a resource with a name similar to that which disappeared when going to DSTU2. I recall that because I coded a PHD to FHIR mapping which vanished when the spec updated.
Also, do you mean PCHA (Personal Connected Health Alliance) and not PHCD or PHD (Personal Health Device)?

Grahame Grieve (Jul 28 2017 at 11:51):

Stefan: thanks for that. there's 590 codes in there - less than I expected. how complete is it?

Grahame Grieve (Jul 28 2017 at 11:51):

Brian - umm, probably I mean PHD. It might well be legacy.

Grahame Grieve (Jul 28 2017 at 11:52):

@John Rhoads - who would know whether this profile should still exist? (or @Todd Cooper)

Grahame Grieve (Jul 28 2017 at 11:53):

@Rob Hausam @Eric Haas we/OO could potentially say that the LOINC code can be omitted if there's a published unencumbered mapping from the code provided to the relevant LOINC code.

Brian Reinhold (Jul 28 2017 at 11:54):

Brian - umm, probably I mean PHD. It might well be legacy.

Grahame - PHDC is the name given for the USB specification for Personal Health Devices ... PHDC means Personal Health Device Class

Grahame Grieve (Jul 28 2017 at 11:54):

not that that IEEE mapping helps there ;-)

Stefan Sauermann (Jul 28 2017 at 11:54):

Stefan: thanks for that. there's 590 codes in there - less than I expected. how complete is it?

I am not a real deep expert, please re-check. My feeling is it captures the LOINC side. On the 11073 a lot of detail seems missing, that a device often generates, but that has no correspondence in LOINC.

Grahame Grieve (Jul 28 2017 at 11:55):

I don't know 11073 enough to checkc

Stefan Sauermann (Jul 28 2017 at 11:58):

Just asking: Might we elaborate on the idea of a "Device/11073" observation, that holds the device data, probably coded in 11073, which then may be used to generate another observation for a specific use case? This might have the beauty of being very well defined on both ends, so the mapping may be done on a useful level of quality and reliability?
I will remain silent "forever" if you do not like that. :)

Grahame Grieve (Jul 28 2017 at 11:59):

has anyone made 11073 available in a FHIR code system? I know I tried before, but couldn't find something I needed

Stefan Sauermann (Jul 28 2017 at 12:00):

has anyone made 11073 available in a FHIR code system? I know I tried before, but couldn't find something I needed

Hmm. I guess that needs the expertise of the IEEE 11073 PHD group, combined with FHIR experts? Anybody from the Continua / PCHA world?

Brian Reinhold (Jul 28 2017 at 12:00):

@Rob Hausam @Eric Haas we/OO could potentially say that the LOINC code can be omitted if there's a published unencumbered mapping from the code provided to the relevant LOINC code.

That would solve the future compatibility issue sort of. Also, I am wondering how one would test this requirement? There is no way a validator can check if the measurement is a vital sign unless it knows what the IEEE code is. If there is no need to indicate in the Observation.meta.profile element that this follows the vital signs profile OR no requirment to put in a category element indicating vital sign, no one would ever know except the encoder who would feel guilty because he/she is violating the spec.

Grahame Grieve (Jul 28 2017 at 12:01):

I don't know whether I like that until I know what the mapping arrangements are.

Grahame Grieve (Jul 28 2017 at 12:01):

note, btw, that it's not up to me. I have a certain amount of influence but it's an OO decision

Brian Reinhold (Jul 28 2017 at 12:03):

has anyone made 11073 available in a FHIR code system? I know I tried before, but couldn't find something I needed

Hmm. I guess that needs the expertise of the IEEE 11073 PHD group, combined with FHIR experts? Anybody from the Continua / PCHA world?

@Stefan Sauermann Stefan, I did make a Java file containing the codes that I was thinking of giving to James Agnew to add to HAPI FHIR to PHCA PHD profiles could be read and supported. However, I don't know it that is even legal (they are my own translations).

Stefan Sauermann (Jul 28 2017 at 12:04):

"There is no way a validator can check if the measurement is a vital sign unless it knows what the IEEE code is"
Are you calling for a code that says "this observation is a vital sign from a device" "You must know IEEE to interpret the details"? Sounds reasonable and doable. I know no LOINC for that, but something might be defined somewhere, if needed.

Stefan Sauermann (Jul 28 2017 at 12:05):

I don't know whether I like that until I know what the mapping arrangements are.

My feeling is that mapping arrangements may be settled in profiles. This happenend e.g. in the IHE PCD work, and elsewhere.

Rob Hausam (Jul 28 2017 at 12:05):

Right. I have same question that Brian just raised - how would we (reliably) test if the mapping requirement was met? But I agree that it is a possibility that OO can discuss. It still seems to me that, if we require them at all, requiring the LOINC codes to be present at the point that the data is encoded into FHIR (whenever and however that occurs) would make the most sense.

Brian Reinhold (Jul 28 2017 at 12:08):

"There is no way a validator can check if the measurement is a vital sign unless it knows what the IEEE code is"
Are you calling for a code that says "this observation is a vital sign from a device" "You must know IEEE to interpret the details"? Sounds reasonable and doable. I know no LOINC for that, but something might be defined somewhere, if needed.

@Stefan Sauermann Stefan, here I am playing devil's advocate. Say I just ignore the requirement and create the Observation with the IEEE code only. Who would know? To reject the Observation because it violates the spec means it must understand whatever coding system is being used and recognize, hey this baby is a vital sign and I see no LOINC code entry! On that note the server would reject the Observation. BUt THAT is not likely to happen. So the encoder is on the honor system. I know personally that I do not want to intentionally violate the spec even if I can get away with it.

Grahame Grieve (Jul 28 2017 at 12:16):

well, the code system question - where do you get the source for the 11073 codes now?

Stefan Sauermann (Jul 28 2017 at 12:21):

well, the code system question - where do you get the source for the 11073 codes now?

Many of it is here: https://rtmms.nist.gov/rtmms/index.htm#!home

Grahame Grieve (Jul 28 2017 at 12:22):

many? I get a blank page for that. and from memory, there's no download

Brian Reinhold (Jul 28 2017 at 12:23):

well, the code system question - where do you get the source for the 11073 codes now?

@Grahame Grieve I get them from the IEEE Standards (11073 10101 etc) but they are also available here
https://rtmms.nist.gov/rtmms/index.htm
Its called the Rosetta. Not sure if all the PHD codes are in there yet. I know all the PHD codes are not in the LOINC mapping yet. I gave a list of codes to those developing the mapping a couple of years ago and they said they didn't understand them. It didn't go further than that.

Grahame Grieve (Jul 28 2017 at 12:24):

this is one of the problems I encounter with the 11073 codes... there's never a simple answer to 'where do I get the codes'... and as i said, I've never found a download from rosetta

Stefan Sauermann (Jul 28 2017 at 12:24):

@Stefan Sauermann Stefan, here I am playing devil's advocate. Say I just ignore the requirement and create the Observation with the IEEE code only. Who would know?

Agree. Is there a code for this in LOINC? Guess no. Might we define one? Probably? Can this be solved in some way? I guess, yes?

Stefan Sauermann (Jul 28 2017 at 12:26):

The "DeviceMetricObservation" was done by the HL7 Health Care Devices group. May it be wise to contact them?

Grahame Grieve (Jul 28 2017 at 12:26):

that was who I asked above - HCD chairs

Stefan Sauermann (Jul 28 2017 at 12:27):

that was who I asked above - HCD chairs

Sorry. My memory for acronyms and codes is obviously limited. :)

Grahame Grieve (Jul 28 2017 at 12:29):

np

Grahame Grieve (Jul 28 2017 at 12:29):

oops. no problems

Stefan Sauermann (Jul 28 2017 at 12:29):

this is one of the problems I encounter with the 11073 codes... there's never a simple answer to 'where do I get the codes'... and as i said, I've never found a download from rosetta

Just looking at what IHE has: Some of it is in the PCD profile: e.g. http://www.ihe.net/uploadedFiles/Documents/PCD/IHE_PCD_TF_Vol3.pdf

Grahame Grieve (Jul 28 2017 at 12:30):

well, it would make FHIR users a lot easier if we published the 11073 codes as a FHIR code system. A single place to get them all, and to load them into all the terminology servers

Brian Reinhold (Jul 28 2017 at 12:31):

well, it would make FHIR users a lot easier if we published the 11073 codes as a FHIR code system. A single place to get them all, and to load them into all the terminology servers

@Grahame Grieve How would you want them?

Stefan Sauermann (Jul 28 2017 at 12:36):

well, it would make FHIR users a lot easier if we published the 11073 codes as a FHIR code system. A single place to get them all, and to load them into all the terminology servers

AGREE!!!! I recently contacted IEEE and asked if we can publish them on our Austrian terminology server. There was a reply, indicationg that this is possible. Shall I make the contact? To whom? I guess this would be "official" in some way, with agreements to be signed?

Grahame Grieve (Jul 28 2017 at 12:39):

well, we can publish them informally, but it's better if we publish them formally.

Grahame Grieve (Jul 28 2017 at 12:39):

Brian - I'll take anything. CSV, excel, database dump, anything I can parse

Stefan Sauermann (Jul 28 2017 at 12:39):

well, we can publish them informally, but it's better if we publish them formally.

email to you is underway.

Brian Reinhold (Jul 28 2017 at 12:45):

Brian - I'll take anything. CSV, excel, database dump, anything I can parse

Grahame, what I meant is what do you need. Clearly not just the code. I assume one would also need an explanation of what the code is.
The codes (numbers) come as partition and term code. Together they make a 32-bit number. The upper 16-bits are the partition and the lower 16-bits are the term codes. Each code has a reference identifier (which is not sent on the wire) but often used by programmers in #define statements. Then one would need a description for what they mean. I can't think of anything else.

Grahame Grieve (Jul 28 2017 at 12:46):

well, in FHIR sense, each concept has a code, a display, a definition, zero or more other designations, and zero or more properties.

Grahame Grieve (Jul 28 2017 at 12:46):

number = code, reference identifier = display, it sounds like

Grahame Grieve (Jul 28 2017 at 12:46):

what do you do with partitions?

Brian Reinhold (Jul 28 2017 at 12:51):

number = code, reference identifier = display, it sounds like

partitions are just convenient way to organize codes into groups. This allows devices to skip partitions on the wire when the partition can be implied by context. For example, partition 4 is dimensions (units). So Unit code values are sent in two bytes and not four. There are not many partitions. Something like 8. There is a partition for disease management, health and fitness, independent living, dimensions, object, etc. In the end in the PHD profiles, I use the 32 bit values across the board (the same is true in V2 messaging). The split is more for bandwidth reduction.

Grahame Grieve (Jul 28 2017 at 12:52):

I think we'd just have to long hand this in FHIR then - a FHIR code is the combination of the pair separated by a "-" or something

Brian Reinhold (Jul 28 2017 at 12:55):

I think we'd just have to long hand this in FHIR then - a FHIR code is the combination of the pair separated by a "-" or something

Grahame, here is an example of its use in FHIR (Glucometer glucose concentration)

                 "coding":[
                     {
                         "system":"urn:iso:std:iso:11073:10101",
                         "code":"160368",
                         "display":"MDC_CONC_GLU_UNDETERMINED_PLASMA: Glucose concentration"
                     }
                 ]

The MDC_CONC_GLU_UNDETERMINED_PLASMA is the reference identifier

I should add that 160368 in HEX is 0x0002 7270. THe partition is the upper two bytes 2 which is partition scada.

Grahame Grieve (Jul 28 2017 at 12:56):

umm, I don't understand that. What does MDC_CONC_GLU_UNDETERMINED_PLASMA do?

Brian Reinhold (Jul 28 2017 at 12:58):

umm, I don't understand that. What does MDC_CONC_GLU_UNDETERMINED_PLASMA do?

Not much. It is a standardized semi-human readable expression of the code. In the PHD profiles it is 100% optional as it is not sent on the wire. However, I can look at that Observation and know what the Observation is. If I just saw '160368' I would have no idea what it is.

Grahame Grieve (Jul 28 2017 at 13:00):

is MDC_CONC_GLU_UNDETERMINED_PLASMA reliable and unique? would it be better to use MDC_CONC_GLU_UNDETERMINED_PLASMA instead of 160368?

Grahame Grieve (Jul 28 2017 at 13:00):

and where does 'Glucose concentration' come from , and does MDC_CONC_GLU_UNDETERMINED_PLASMA offer anything that 'Glucose concentration' doesn't?

Brian Reinhold (Jul 28 2017 at 13:05):

is MDC_CONC_GLU_UNDETERMINED_PLASMA reliable and unique? would it be better to use MDC_CONC_GLU_UNDETERMINED_PLASMA instead of 160368?

Grahame, in theory one could BUT for an encoder that could pose a problem for future compatibility and require a huge dictionary to map the codes to the ref ids. They are NOT sent on the wire from the device. That would be far too costly. IEEE is designed to be extensible so a future specialization using new codes (unknown to the collector) could still upload and encode them into FHIR. If ref ids were required, that could not be done. Clearly the reader would have to know what the code means, so the reader will have to understand the latest codes to understand the latest device measurements.

Grahame Grieve (Jul 28 2017 at 13:05):

figured that's what you'd say, but worth asking

Stefan Sauermann (Jul 28 2017 at 13:05):

does MDC_CONC_GLU_UNDETERMINED_PLASMA offer anything that 'Glucose concentration' doesn't?

It says that the 'Glucose concentration' comes from plasma and not from blood. Quite important in some use cases.

Grahame Grieve (Jul 28 2017 at 13:06):

that's specified in the code, right? so where did 'Glucose Concentration' come from? isn't that wrong?

Stefan Sauermann (Jul 28 2017 at 13:09):

that's specified in the code, right? so where did 'Glucose Concentration' come from? isn't that wrong?

Just found a table, hope that helps: https://standards.ieee.org/downloads/11073/11073-10101a-2015/XSL_Output.1k.x5gt.x3c.2015-12-02T16.html

Brian Reinhold (Jul 28 2017 at 13:10):

that's specified in the code, right? so where did 'Glucose Concentration' come from? isn't that wrong?

Grahame: My laziness. Yes all the details are specified in the code. The full explanation of 160368 would be "Glucose concentration measured from blood plasma, source is not specified". There are a whole set of codes indicating plasma, whole blood, capillary, arterial, venous, etc

Stefan Sauermann (Jul 28 2017 at 13:25):

I am off for the weekend now. Will be happy to continue on Monday! Looking forward, Stefan

Grahame Grieve (Jul 28 2017 at 13:25):

so I think that the MDC_CONC_GLU_UNDETERMINED_PLASMA is another desgnation

Grahame Grieve (Jul 28 2017 at 13:26):

is that all the codes? I will work on it over the weekend

Stefan Sauermann (Jul 28 2017 at 13:28):

is that all the codes? I will work on it over the weekend

These are just the ones that came in in an amendment of the nomenclature in 2015. There are others as well. Did you get the "official" contact via email from me? I hope that this will eventually provide the complete list to you. Probably somebody has a more complete copy. I only have the standard as pdf, useful, but not for automated processing.

Stefan Sauermann (Jul 28 2017 at 13:30):

so I think that the MDC_CONC_GLU_UNDETERMINED_PLASMA is another desgnation

If "another designation" means that it has a unique identifier, that is different from the identifier of e.g. the blood glucose concentration, you are correct.
Am off now. Bye!

John Moehrke (Jul 28 2017 at 13:53):

Is @Paul Schluter still the master owner of Rosetta? @Brian Nantz ?

John Rhoads (Jul 28 2017 at 15:14):

1. DeviceMetricObservation is, to the best of my knowledge and belief, obsolete and deprecated (@ToddCooper has said so too). The resources that are alive, being herded by HL7 Health Care Devices (HCD) WG are DeviceComponent and DeviceMetric.

John Rhoads (Jul 28 2017 at 15:36):

The Rosetta Terminology Mapping Management System (RTMMS) - https://rtmms.nist.gov/rtmms/index.htm#!home - given in a previous post works for me, and there is a download (CSV, XML, maybe Excel too, I forget). You might need to request a userid for that - I will get a up-to-date download and send it to anyone who wants it, starting with @GrahameGrieve.
The mapping-to-LOINC is a work in process and continues to expand (kudos to Swapna Abhankar MD of Regenstreif). It contains in its five hundred plus mappings, I think, pretty much anything that you would call a vital sign. There are hundreds more codes in 11073 but many of them are about fine distinctions and intrastructural details of devices that few if any current EMRS would use in charting or indeed would even save.

Some US-based and international EMRs (e.g. Epic) do indeed understand 11073 codes since the IHE Patient Care Device Device Enterprise Communications profiles encourage (do not require) their use - LOINC and SNOMED are also accepted on a "send as many as you please, and let the receiving system pick out its preference" basis.
And yes, @John Moehrke, @PaulSchluter is still leading the group vetting new codes and feeding the RTMMS database and the IEEE 11073-10101x standards, and promises to continue doing so after leaving GE.

Brian Reinhold (Jul 28 2017 at 15:56):

I do see another potential issue of forcing all vital signs Observations to use a fixed set of LOINC codes. For example, 11073 has many different codes to express a heart rate ( a vital sign) and they all need to be mapped to the same code. A reader that looks only at the LOINC code might misinterpret the context of the measurement. For example, the 11073 cardio specification has a heart rate measurement type which also has additional supplemental types value indicating the heart rate might be an average or maximum during a workout session. Its probably a bad idea for a reader to use this value without knowing the context of the measurement.

Lloyd McKenzie (Jul 28 2017 at 16:22):

@Brian Reinhold - This is in response to something early in this conversation where you mentioned requiring that coding[0] would contain a specific code. It's bad practice to depend on codings in FHIR being in any particular position in a FHIR instance. There's no meaning to the order of the codings. Forcing systems to spit out codings in a particular order just means that systems will have to write custom interfaces for each receiver who demands a different ordering even though they're conveying exactly the same information. (If you require IEEE is first and someone else requires LOINC first and someone else requires SNOMED first - that's 3 interfaces and that will get worse the more attribute combinations considered.) The tiny gain in efficiency from not having to check the system of each coding to find the one you want rarely outweighs the large (and ongoing) cost of developing, testing and maintaining multiple interfaces for all of the communication partners. Best practice is for instance creators to populate codings (and any other repeating element where the order of repetitions is meaningless) in whatever order they choose and for the receiver to extract the repetition that's relevant to them by looking at data in the instance (in this case the Coding.system).

Todd Cooper (Jul 28 2017 at 17:00):

Is @Paul Schluter still the master owner of Rosetta? @Brian Nantz ?

FYI - @Paul Schluter is retiring from GE come the 31st! But is planning on spending his retired leisure (at least in the near term) on continuing to advance the 11073 nomenclature

Brian Reinhold (Jul 28 2017 at 18:30):

@Lloyd McKenzie This is a requirement in the PCHA PHD profile and for uploaders that are following that profile. The idea is that implementers of readers supporting the PCHA PHD profile would only need to carry an 11073 dictionary to decode the message and would not have to search through a list to find the correct system value. I had even though of adding a coding element entry that told what kind of data type the measurement was (Quantity, code, string) so the reader would not have to search through the possible data types to find out what the measurement type is. But I didn't do that though I implemented it and use it in my reader ... I am a lazy coder.

Of course, the reader would only know that it could do that because it sees that the Observation.meta.profile is set to the PCHA PHD profile. Isn't that the idea of a profile? You restrict/constrain the possible behaviors to simplify the implementation? To the uploader its certainly not a problem. The only coding required is the 11073 code unless FHIR requires additional. Of course the application can add whatever additional codings it wants. If someone else wants to require SNOMED first, that would be fine but they would have to do that in their own profile. It would not be complaint with the PCHA PHD profile and should not indicate that in the meta.profile element. I cannot see how this differs in any way from any of the other restrictions one places in a profile. Am I missing something?

There is no rule saying a reader has to take advantage of that information.

On re-reading your comments maybe I didn't understand it. The receiver, I assume, takes whatever it gets. It does not look at the resource beyond what is needed to work with the RESTful FHIR API. This requirement is on the creator of the resource which is then uploaded to a FHIR server.

Lloyd McKenzie (Jul 28 2017 at 18:41):

I'm not understanding the rationale for requiring the code be the first repetition. Why is it a problem for readers to search through the list? It's a tiny amount of coding effort, low performance cost and significantly improves interoperability.

Lloyd McKenzie (Jul 28 2017 at 18:42):

The point of FHIR is I should be able to construct a single interface that spits out FHIR data and all readers - whether they want SNOMED, IEEE or LOINC can grab the data they care about.

Lloyd McKenzie (Jul 28 2017 at 18:42):

Senders don't create one interface per reader. They create one interface for all FHIR consumers. Different FHIR readers grab what data they care about.

Lloyd McKenzie (Jul 28 2017 at 18:43):

If you have to expose a different interface per reader, you don't get a whole lot of benefit out of using a standard.

Brian Reinhold (Jul 28 2017 at 19:02):

@Lloyd McKenzie a generic reader could certainly read the Observation if it understands the 11073 coding system. It would not need to take advantage of any ordering or profile information (which would also tell it what data type the value is without trying different types). However, a reader that does understand the profile can work a little less. The only thing that is limiting interoperability is the coding system. If the reader is looking for SNOMED codes it may find them or it may not. That depends upon the implementation sourcing the data. But it will find MDC codes. So that is really the only requirement placed upon the reader for guaranteed interoperability. Right now the profile does not require any extensions which makes it even more generically interoperable. If there were one and only one coding system the uploaded data would be readable by any reader that can understand elements of the base FHIR specification. I don't see how requiring that ordering be done by the uploader affects interoperability. I can see that using only a certain coding system affects interoperability!

Lloyd McKenzie (Jul 28 2017 at 19:37):

But you're making authoring systems work more. Your code system may be the primary one for your readers, but it's not the primary one for all readers. Therefore, you shouldn't dictate that yours has to come first. Doing so might make things a tiny bit easier for your readers, but it forces the author to create a custom interface just for you. They shouldn't have to do that. They should be able to spit out the codes they know in any order they wish. And all readers then look through the list to see what they care about. The impact on interoperability is that if your reader requires IEEE first and some other profile requires SNOMED first and some other profile requires LOINC first, then the author must write 3 interfaces. That is an interoperability problem - because you just tripled maintenance costs for the authoring system. With FHIR the authoring system should only have to create a single interface that's used by everyone - whether they want IEEE codes, LOINC codes, SNOMED codes or something else.

Brian Nantz (Jul 28 2017 at 19:54):

Is @Paul Schluter still the master owner of Rosetta? @Brian Nantz ?

FYI - @Paul Schluter is retiring from GE come the 31st! But is planning on spending his retired leisure (at least in the near term) on continuing to advance the 11073 nomenclature

@Todd Cooper & @John Moehrke - just got back from Paul's retirement and he is planning on continuing on! Still pondering GE's representation as of now....

Grahame Grieve (Jul 28 2017 at 23:36):

@Brian Reinhold what OID is used for these 11073 codes in CDA?

Brian Reinhold (Jul 28 2017 at 23:42):

@Brian Reinhold what OID is used for these 11073 codes in CDA?

@Grahame Grieve This is what I have in the PHMR:

For convenience the attribute values for some coding systems are provided here:
@codeSystemName @codeSystem
SNOMED CT 2.16.840.1.113883.6.96
LOINC 2.16.840.1.113883.6.1
MDC 2.16.840.1.113883.6.24

Grahame Grieve (Jul 29 2017 at 00:35):

there's lots of invalid UCUM units in the MDC ucum unit mappings

Grahame Grieve (Jul 29 2017 at 00:47):

there's basically 3 sets of errors:
- the unit for day is 'd' not 'day'
- [arb'U] is not a SI unit, so can't be prefixed with SI prefixes
- {delta}Cel - this is gramatically invalid - could be Cel{delta}.

Grahame Grieve (Jul 29 2017 at 00:47):

there's also a single error in it's own category: dB[10.nV] - I don't know what that's meant to be

Grahame Grieve (Jul 29 2017 at 00:53):

142 errors all up

Grahame Grieve (Jul 29 2017 at 01:11):

here's a candidate code system resource (omits the invalid UCUM Codes): http://www.healthintersections.com.au/codesystem-MDC.xml

Grahame Grieve (Jul 29 2017 at 02:54):

and a LOINC / MDC concept map:

Grahame Grieve (Jul 29 2017 at 02:55):

http://www.healthintersections.com.au/conceptmap-loinc-mdc.xml

John Silva (Jul 29 2017 at 23:58):

Do the IHE folks
ow about these MDC UCUM errors (or is it a problem with the HL7 ISO+ UofMs?

Grahame Grieve (Jul 30 2017 at 04:18):

well, who should I tell?

Grahame Grieve (Jul 30 2017 at 04:19):

it's a problem with the UCUM units in rosetta

Paul Schluter (Jul 30 2017 at 17:21):

Grahame and colleagues,

Paul Schluter (Jul 31 2017 at 16:24):

Grahame and colleagues,

Regarding the potential UCUM errors that you have identified in the NIST RTMMS, presumably under the hRTM 'harmonized Rosetta':

the unit for day is 'd' not 'day'
Yes, this is an error, and it will be corrected shortly.

[arb'U] is not a SI unit, so can't bet prefixed with SI prefixes
[arb'U] is defined in the UCUM as an 'arbitrary International Unit', and in ISO/IEEE 11073-10101a-2015 this was clarified with the following footnote:
International (IU) and United States Pharmacopeia (USP) units are defined in terms of comparison to a physical reference preparation; the mass or volume that constitutes one ‘unit’ varies based on which substance is being measured and the variance is based on the biological activity or effect. IU and USP units are used to quantify vitamins, hormones, some medications, vaccines, blood products, and other biologically active substances. Although the meaning of IU and USP units differs from substance to substance, comparisons to the underlying WHO or USP reference preparation can be made, facilitating interoperability across multiple institutions. In contrast, arbitrary units [arb’U] contain an arbitrary scale factor and preclude any meaningful comparison across multiple institutions (although comparability within a given institution may be possible).

{delta}Cel - this is gramatically invalid - could be Cel{delta}
{delta} is a unitless UCUM annotation and several IHE PCD vendors preferred retaining it for human-reader clarity. In general, the observation identifier(s) the use this unit include the concept of a temperature difference.

dB[10.nV]
This was added to UCUM several years ago as a way of expressing the 0dB reference level that was not a simple prefixed power of ten. In this instance, the 0dB level is with respect to 10 nV, and is used as a logarithmic unit of measure for EEG amplitude. The essential idea here is that the square braces [...] enclose a UCUM value that may include an integer scale factor, e.g. '10.' to obtain a 10.nV reference level. This can apply to any measurement that uses a logarithmic representation, e.g. EEG, acoustic, electromagnetic field strength, ionizing radiation, etc.

Also, I recommend that you apply your UCUM validator to the harmonized Rosetta (hRTM) terms on the NIST RTMMS - they have been carefully vetted (with the exception of the 'day' instead of 'd' error that you found). If you have any other questions about the NIST RTMMS and the IEEE 11073-10101* nomenclatures in general, I would be happy to answer them.

Thanks and regards,

Paul Schluter

Grahame Grieve (Jul 31 2017 at 21:57):

dB[10.nV] - this turns out to be a bug in my parser.
{delta}Cel - in spite of what you said, it's still not grammatically valid, and merely wanting it to be ok doesn't make it ok
[arb'U] - same. In UCUM, it's not an SI unit, and can't be prefixed with M k etc. None of what you wrote addressed that

Paul Schluter (Aug 01 2017 at 17:17):

Grahame and colleagues,

dB[10.nV] - this turns out to be a bug in my parser. (okay)

{delta}Cel - in spite of what you said, it's still not grammatically valid, and merely wanting it to be ok doesn't make it ok
We can change this to Cel{delta}, which is grammatically valid. I will check for other {annotation} errors of this type.

[arb'U] - same. In UCUM, it's not an SI unit, and can't be prefixed with M k etc. None of what you wrote addressed that.
I'm not sure I am following you here. From a UCUM grammar perspective, [arb'U] is not different than other lexical elements such as [iU]; in fact, they are listed in the same table in the UCUM specification and they may be prefixed, e.g. m[iU]/mL, as listed in the examples at the end. From a higher level perspective, supporting [arb'U] allows us to express an arbitrary scale factor and strictly reserve the use of [iU] where meaningful comparison across multiple institutions (and algorithms) is required. I believe this is what Gunther and his colleagues had in mind when they originally defined [arb'U] and this view was endorsed by the IHE PCD infusion pump working group and was successfully balloted as part of an ISO/IEEE 11073-10101a standard. If this needs to be discussed further, I would be happy to do so, with participation by Gunther and others from the IHE PCD and IEEE 11073 communities.

Best regards,

Paul Schluter

Grahame Grieve (Aug 01 2017 at 19:49):

with regard to [arb'U], it makes total sense to use prefixes with the unit to me. However, this is what UCUM says:

Grahame Grieve (Aug 01 2017 at 19:49):

§4 prefixes ■1Metric units (cf. §11) may be combinations of a unit symbol with a prefix symbol. ■2The unit symbol to be combined with the prefix must not itself contain a prefix. Such a prefix-less unit symbol is called unit atom. ■3Prefix and atom are connected immediately without any delimiter. Separation of an optional prefix from the atom occurs on the lexical level by finding a matching combination of an optional prefix and a unit atom. ■4 The prefix is the longest leading substring that matches a valid prefix where the remainder is a valid metric unit atom. If no such prefix can be matched, the unit atom is without prefix and may be both metric or non-metric

Grahame Grieve (Aug 01 2017 at 19:49):

and here's the definition of [arb'U]:

Grahame Grieve (Aug 01 2017 at 19:50):

   <unit xmlns="" Code="[arb'U]" CODE="[ARB'U]" isMetric="no" isArbitrary="yes"
         class="chemical">
      <name>arbitary unit</name>
      <printSymbol>arb. U</printSymbol>
      <property>arbitrary</property>
      <value Unit="1" UNIT="1" value="1">1</value>
   </unit>

Grahame Grieve (Aug 01 2017 at 19:50):

isMetric="no".

Grahame Grieve (Aug 01 2017 at 19:51):

I think it makes sense to raise this with Gunther etc. The problem here is that it isn't really a metric unit in all senses of the meaning, but it does make sense to prefix it

Grahame Grieve (Aug 01 2017 at 19:52):

on the subject of Cel{delta}.... maybe it would good for UCUM to have a direct way of saying 'change' in the unit? not sure.

Grahame Grieve (Aug 01 2017 at 19:53):

other examples of this case:

Grahame Grieve (Aug 01 2017 at 19:55):

• {delta}Cel
• {delta}[degF]
• {liquid}mL

Grahame Grieve (Aug 01 2017 at 19:56):

the last looks redundant. I suppose it's possible to measure volume of gas, but that would seem like an edge case to me?

Swapna Abhyankar (Aug 22 2017 at 13:28):

Stefan: thanks for that. there's 590 codes in there - less than I expected. how complete is it?

@Grahame Grieve , the current LOINC-IEEE map covers ~70% of the active concepts in the 11073 10101/10101a standards. It's a work in progress, and unfortunately the Regenstrief LOINC team does not have the resources (people) to devote as much time to this project as it needs. If anybody in the community is willing to contribute to this effort, please let me know.

Daniel Vreeman (Aug 23 2017 at 02:37):

Interesting discussion here...couple of quick points:

1. Regarding Grahame's earlier question re people who might be using LOINC because it's required by HL7. There's no requirement that users "register" or sign anything with RI, since the LOINC license allows redistribution. But regardless, if you are using LOINC, your use is governed by the LOINC license (which permits its free use worldwide in commercial and noncommercial systems).

2. My understanding is that the license for MDC codes is a little less permissive. Specifically, if you get the MDC codes from NIST, this is what you are allowed to do with them:

IEEE, as part of its support of the RTMMS database and on-going, royalty-free agreement with the NIST, makes these terms available for the development of IEEE11073 compliant products and supporting material (e.g. in user documentation, collateral, etc.). Any use of IEEE terms beyond compliant products and support material may require prior approval from IEEE. Please notify IEEE of any request to use, modify, or reproduce these terms in any manner beyond the permitted use described above. To request permission, please submit your request to stds-ipr@ieee.org.

So, loading into a terminology server, an EHR, or downstream analytics engines do not appear to meet the permitted use of "development of IEEE11073 compliant products and supporting material" Probably best to follow-up with IEEE. However...

In our ongoing work with IEEE (via the HL7 HCD group), Regenstrief obtained specific permission to distribute key elements of the 11073 tables in our mapping table. That mapping table is distributed under the main LOINC license.

3. You might expect me to say this, but the idea of having a common coding system for these variables is a laudable goal that we should keep striving for. There are many prevailing use cases for vital signs data across many domains, and having device-produced data identified in a different way that data captured natively in the EHR (or elsewhere) seems less than ideal. Adding the MDC code as an additional code to the LOINC code specified in the profile seems to me the way to go.

Specifically regarding the U.S. mentions...the ISA is not a regulatory document, but more of an "index" of standards. It currently lists both LOINC and IEEE as vocab standards for vitals (https://www.healthit.gov/isa/Representing_Patient_Vital_Signs) with noted differences in the characterizing attributes, such as that LOINC is federally required in some contexts. E.g. LOINC is the required coding system for vitals in the Common Clinical Data Set as specified in the 2015 Certification Criteria. C-CDA vital signs entry templates require LOINC too.

Last updated: Apr 12 2022 at 19:14 UTC