Two LOINC codes for one lab-item

Ian McNicoll ian at freshehr.com
Wed Feb 15 07:15:46 EST 2017


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


More information about the openEHR-clinical mailing list