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.verh...@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 <i...@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: i...@freshehr.com >> twitter: @ianmcnicoll >> >> >> Co-Chair, openEHR Foundation ian.mcnic...@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.verh...@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 <i...@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: i...@freshehr.com >> twitter: @ianmcnicoll >> >> >> Co-Chair, openEHR Foundation ian.mcnic...@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.verh...@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 <i...@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: i...@freshehr.com >> twitter: @ianmcnicoll >> >> >> Co-Chair, openEHR Foundation ian.mcnic...@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.verh...@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@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr- >> clinical_lists.openehr.org >> >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr- >> clinical_lists.openehr.org >> >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr- >> clinical_lists.openehr.org >> >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr- >> clinical_lists.openehr.org >> >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr- >> clinical_lists.openehr.org >> >> >> _______________________________________________ >> openEHR-clinical mailing list >> openEHR-clinical@lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr- >> clinical_lists.openehr.org > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical@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@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
