Two LOINC codes for one lab-item

David Moner damoca at gmail.com
Wed Feb 15 07:48:12 EST 2017


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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20170215/fb2f1471/attachment-0002.html>


More information about the openEHR-clinical mailing list