Two LOINC codes for one lab-item

Bert Verhees bert.verhees at rosa.nl
Wed Feb 15 09:01:13 EST 2017


Thanks David,

I will suggest this to my employer.

Best regards
Bert Verhees

Op wo 15 feb. 2017 om 14:58 schreef David Moner <damoca at gmail.com>:

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


More information about the openEHR-clinical mailing list