Two LOINC codes for one lab-item

David Moner damoca at gmail.com
Wed Feb 15 08:57:17 EST 2017


Bert, I think you have a misconception there.

In your example there are not codes for different units. There are codes
for different complex concepts: "Creatinine [Mass/volume] in Serum or
Plasma"  and "Creatinine [Moles/volume] in Serum or Plasma". You cannot use
those codes to code just the units of measurement. The unit codes are pure
UCUM: mg/dL and umol/L.

In the openEHR archetype you don't need to add a particular binding at the
unit level of the dv_quantity. The unit value is already a standard and
interoperable code. And as I said before, the LOINC codes are bindings for
the container Element that will contain that specific measurement. You only
have to model the archetype to match the two possible configurations:

choice {
  ELEMENT   {     --> Bind to: 2160-0 Creatinine [Mass/volume] in Serum or
Plasma
     DVQuantity {
          unit { "mg/dL}
     }
  }
  ELEMENT   {     --> Bind to: 14682-9 Creatinine [Moles/volume] in Serum
or Plasma
     DVQuantity {
          unit { "umol/L}
     }
  }
}

2017-02-15 14:38 GMT+01:00 Bert Verhees <bert.verhees at rosa.nl>:

> 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>:
>
>> 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 <+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: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
>>
>>
>> _______________________________________________
>> 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/89a32e87/attachment-0002.html>


More information about the openEHR-clinical mailing list