Two LOINC codes for one lab-item

Bert Verhees bert.verhees at rosa.nl
Wed Feb 15 07:25:56 EST 2017


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


More information about the openEHR-clinical mailing list