Two LOINC codes for one lab-item

Colin Sutton Colin.Sutton at ctc.usyd.edu.au
Thu Feb 16 23:39:16 EST 2017


Hi Bert,
Not only different countries. Within Australia different labs use different measuring equipment or different standards for measurements, for which there are different HL7 codes.

Colin

From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] On Behalf Of Bert Verhees




Sent: Thursday, 16 February 2017 12:38 AM
To: For openEHR clinical discussions
Subject: Re: Two LOINC codes for one lab-item

Ian,

2160-0 Creatinine [Mass/volume] in Serum or Plasma        Creatinine      Qn         mg/dL
14682-9 Creatinine [Moles/volume] in Serum or Plasma      Creatinine     Qn         umol/L

In my example, there are different codes for different unit-types. I agree that moles and mass are not easy interchangeable, but there are lab-tests in the use-cases where I work where it is allowed to use both, because we work with different countries having another way of notating lab-results.

Op wo 15 feb. 2017 om 14:28 schreef Ian McNicoll <ian at freshehr.com<mailto:ian at freshehr.com>>:
Hi Bert,

"suggest the underlying DV-QUANTITY uses the UCUM unit which is represented by the LOINC-code"

That is not actually quite correct, any given LOINC code can be associated with a range of different units, and are only examples i.e do not restrict others. LOINC sometimes uses different codes for different classes of unit, not for specific units.
It does also have terms for the base substance e.g. http://r.details.loinc.org/Part/LP14355-9.html<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5pxR2PmQjg&u=http%3a%2f%2fr%2edetails%2eloinc%2eorg%2fPart%2fLP14355-9%2ehtml> but when querying you would then to query on all of the variations of 'creatinine'. Even more messy!

But if you want to clearly associate a specific LOINC code with valid unit(s) then it is possible to do that as I suggested before.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859<tel:+44%207752%20097859>
office +44 (0)1536 414994<tel:+44%201536%20414994>
skype: ianmcnicoll
email: ian at freshehr.com<mailto:ian at freshehr.com>
twitter: @ianmcnicoll

[Image removed by sender.]
Co-Chair, openEHR Foundation ian.mcnicoll at openehr.org<mailto:ian.mcnicoll at openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 15 February 2017 at 12:56, Bert Verhees <bert.verhees at rosa.nl<mailto:bert.verhees at rosa.nl>> wrote:
Thanks David for your reply,

Just for the discussion, adding the LOINC-code to the element would suggest the underlying DV-QUANTITY uses the UCUM unit which is represented by the LOINC-code. That could cause a semantic error-situation.

The problem is that LOINC uses (sometimes) different codes for different units, especially when the units are not easy interchangable, like mol and g (gram)

Op wo 15 feb. 2017 om 13:49 schreef David Moner <damoca at gmail.com<mailto:damoca at gmail.com>>:
I agree with Ian, at least for your case those those LOINC codes could be used to bind the container Element, but not the unit itself. Units are coded using UCUM standard, so they are already semantically queryable/interpretable.

2017-02-15 13:25 GMT+01:00 Bert Verhees <bert.verhees at rosa.nl<mailto:bert.verhees at rosa.nl>>:
That is indeed a way to do it. But I believe the feeling here is to not do it that way, and add no LOINC-term-binding to dv_quantity if this is the situation

Thanks for your attention and solution
Bert
Op wo 15 feb. 2017 om 13:17 schreef Ian McNicoll <ian at freshehr.com<mailto:ian at freshehr.com>>:
Hi Bert,

Then I am not understanding your use-case.

You can use the template to constrain the lab units and/or code to be whatever you want. If there is actually a choice of possible units/codes, then I suggest that you create 2 contraints in the template one for each combination of code + unit.

As far as I can see that will do what you need.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859<tel:+44%207752%20097859>
office +44 (0)1536 414994<tel:+44%201536%20414994>
skype: ianmcnicoll
email: ian at freshehr.com<mailto:ian at freshehr.com>
twitter: @ianmcnicoll

[Image removed by sender.]
Co-Chair, openEHR Foundation ian.mcnicoll at openehr.org<mailto:ian.mcnicoll at openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 15 February 2017 at 12:06, Bert Verhees <bert.verhees at rosa.nl<mailto:bert.verhees at rosa.nl>> wrote:
Ian,

The problem is that we want to constrain the user in units which .
And the purpose of the coding would be to make the data which are stored, queryable/interpretable/interchangeable over the coding (if every unit-use in dv_quantity would have a coding)

Bert

Op wo 15 feb. 2017 om 12:53 schreef Ian McNicoll <ian at freshehr.com<mailto:ian at freshehr.com>>:
Hi Bert,

I don't understand the use-case here.

1. if the lab result is being imported from a lab message, you import whtaever units are being recorded in the message.

2. If this is a situation where the lab test is being recorded via a data entry screen, and there is a potential for there to be more than one unit required. I would either just handle the association between loinc code and unit in the application, or clone the lab-test panel result-value to support two different values each constrained to the correct loinc code / unit combination.


Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859<tel:+44%207752%20097859>
office +44 (0)1536 414994<tel:+44%201536%20414994>
skype: ianmcnicoll
email: ian at freshehr.com<mailto:ian at freshehr.com>
twitter: @ianmcnicoll

[Image removed by sender.]
Co-Chair, openEHR Foundation ian.mcnicoll at openehr.org<mailto:ian.mcnicoll at openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 15 February 2017 at 11:42, Bert Verhees <bert.verhees at rosa.nl<mailto:bert.verhees at rosa.nl>> wrote:
Thanks Ian for the quick response.
From practical point of view you are right.
I think we need follow this advice.

But now let's look at it from the Reference Model or LOINC point of view, maybe there some change would be welcome.

The problem is that different used units in measurements which are exact the same for the rest (method, substance, purpose), sometimes translate to a different LOINC-code.

In openEHR-archetypes (mostly used to build software) we want to constrain the sender in the units he can choose. We don' t want our software to translate every possible unit to the unit we want to process. So that is why we offer some units for the sender to choose from. This constraining is done in DV-QUANTITY, following the openEHR-specs it is in UCUM syntax (it does not say UCUM-unit http://www.openehr.org/releases/RM/Release-1.0.3/docs/data_types/data_types.html#_dv_quantity_class<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5ppX0vmQ3g&u=http%3a%2f%2fwww%2eopenehr%2eorg%2freleases%2fRM%2fRelease-1%2e0%2e3%2fdocs%2fdata%5ftypes%2fdata%5ftypes%2ehtml%23%5fdv%5fquantity%5fclass> ).

To be sure that the sender is using the constrained units and measuring the constrained item we need some coding. I was worried because of some discussion on an OpenEHR list in 2014, which discussed a similar problem. ( http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/2014-November/003393.html<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5pkE1fqViA&u=http%3a%2f%2flists%2eopenehr%2eorg%2fpipermail%2fopenehr-clinical%5flists%2eopenehr%2eorg%2f2014-November%2f003393%2ehtml> )

So, imho, the possibility to add LOINC-coding (or coding in general) to different unit-kinds in the dv_quantity-class to tell us what we are looking at, would be a good feature to support interoperability.

Bert Verhees

Op wo 15 feb. 2017 om 11:53 schreef Ian McNicoll <ian at freshehr.com<mailto:ian at freshehr.com>>:
Hi Bert,

I don't think this is helpful. The source of truth in dv_quantity should always be the unit. I would not trust the LOINC code. It should be the responsibility of the original sender/documenter to make sure the correct LOINC code was used to match the SI unit. I would think this advice would apply whether one was using hl7v2, FHIR, CDA or openEHR.

Ian



Dr Ian McNicoll
mobile +44 (0)775 209 7859<tel:+44%207752%20097859>
office +44 (0)1536 414994<tel:+44%201536%20414994>
skype: ianmcnicoll
email: ian at freshehr.com<mailto:ian at freshehr.com>
twitter: @ianmcnicoll

[Image removed by sender.]
Co-Chair, openEHR Foundation ian.mcnicoll at openehr.org<mailto:ian.mcnicoll at openehr.org>
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL

On 15 February 2017 at 10:37, Bert Verhees <bert.verhees at rosa.nl<mailto:bert.verhees at rosa.nl>> wrote:
Hi all,

When you work with quantities it is possbile to add more units, sometimes, the use of different units have other LOINC-coding, this is for example with

LOINC:
LOINC LongName                                                          Component    Scale      exUCUMunits
2160-0 Creatinine [Mass/volume] in Serum or Plasma        Creatinine      Qn         mg/dL
14682-9 Creatinine [Moles/volume] in Serum or Plasma      Creatinine     Qn         umol/L

Would it be good if it was possible to add code per unit-kind in dv_quantity?
Or are there other suggestions

Thanks
Bert Verhees

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5pRXhv2Q3g&u=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-clinical%5flists%2eopenehr%2eorg>

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5pRXhv2Q3g&u=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-clinical%5flists%2eopenehr%2eorg>

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5pRXhv2Q3g&u=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-clinical%5flists%2eopenehr%2eorg>

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5pRXhv2Q3g&u=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-clinical%5flists%2eopenehr%2eorg>

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5pRXhv2Q3g&u=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-clinical%5flists%2eopenehr%2eorg>

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5pRXhv2Q3g&u=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-clinical%5flists%2eopenehr%2eorg>

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5pRXhv2Q3g&u=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-clinical%5flists%2eopenehr%2eorg>



--
David Moner Cano
Grupo de Informática Biomédica - IBIME
Instituto ITACA
http://www.ibime.upv.es<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5sgA0fyW2w&u=http%3a%2f%2fwww%2eibime%2eupv%2ees>
http://www.linkedin.com/in/davidmoner<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5p4M0vmc2w&u=http%3a%2f%2fwww%2elinkedin%2ecom%2fin%2fdavidmoner>

Universidad Politécnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3ª planta
Valencia – 46022 (España)
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5pRXhv2Q3g&u=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-clinical%5flists%2eopenehr%2eorg>

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5pRXhv2Q3g&u=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-clinical%5flists%2eopenehr%2eorg>

_______________________________________________
openEHR-clinical mailing list
openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org>
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org<http://scanmail.trustwave.com/?c=1688&d=_tmk2O2nyUPlNyRyZb7udMoypRGSrSMn5pRXhv2Q3g&u=http%3a%2f%2flists%2eopenehr%2eorg%2fmailman%2flistinfo%2fopenehr-clinical%5flists%2eopenehr%2eorg>
</div

#####################################################################################
Scanned by MailMarshal - M86 Security's comprehensive email content security solution. 
#####################################################################################

________________________________________
IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The CTC is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the CTC. If you receive this e-mail in error, please immediately delete it and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient.
________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20170217/d31dccec/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 368 bytes
Desc: image001.jpg
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20170217/d31dccec/attachment.jpg>


More information about the openEHR-clinical mailing list