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 <dam...@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.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
_______________________________________________ openEHR-clinical mailing list openEHR-clinical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
