Two LOINC codes for one lab-item

Ian McNicoll ian at freshehr.com
Wed Feb 15 08:27:19 EST 2017


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 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
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian at freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation 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> 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>:
>
>> 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>:
>>
>> 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>:
>>
>> 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 <+44%207752%20097859>
>> office +44 (0)1536 414994 <+44%201536%20414994>
>> skype: ianmcnicoll
>> email: ian at freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>> Co-Chair, openEHR Foundation 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> 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>:
>>
>> 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 <+44%207752%20097859>
>> office +44 (0)1536 414994 <+44%201536%20414994>
>> skype: ianmcnicoll
>> email: ian at freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>> Co-Chair, openEHR Foundation 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> 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 ).
>>
>> 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 )
>>
>> 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>:
>>
>> 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 <+44%207752%20097859>
>> office +44 (0)1536 414994 <+44%201536%20414994>
>> skype: ianmcnicoll
>> email: ian at freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>> Co-Chair, openEHR Foundation 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> 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
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> clinical_lists.openehr.org
>>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> clinical_lists.openehr.org
>>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> clinical_lists.openehr.org
>>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> clinical_lists.openehr.org
>>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> clinical_lists.openehr.org
>>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> clinical_lists.openehr.org
>>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> clinical_lists.openehr.org
>>
>>
>>
>>
>> --
>> David Moner Cano
>> Grupo de Informática Biomédica - IBIME
>> Instituto ITACA
>> http://www.ibime.upv.es
>> http://www.linkedin.com/in/davidmoner
>>
>> 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
>> http://lists.openehr.org/mailman/listinfo/openehr-
>> clinical_lists.openehr.org
>
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-
> clinical_lists.openehr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20170215/32ec7d86/attachment-0002.html>


More information about the openEHR-clinical mailing list