Two LOINC codes for one lab-item

Ian McNicoll ian at freshehr.com
Wed Feb 15 06:52:15 EST 2017


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


More information about the openEHR-clinical mailing list