Hi Daniel No one is talking about abandoning what we have. The only question is about the way that the casual measurements of countable discrete things where the ucum unit is "1" are handled. I think that we're agreed that openEHR and, for that matter, HL7 v2 and v3 haven't go this right yet. In the openEHR context, the question is, how should this be done?
> tablets 500 mg paracetamol" is not just a point of reference for > representing the number quantity but part if of the quantity being > observed (or stated). I don't think this is true. Mostly, we look for codes for what is measured, and the codes don't include that part. So if you, as v3/CDA do, say that that is part of the thing that is measured, you are asking people to do an impossible feat of post-coordination. Grahame On 19/03/2012, at 9:26 PM, Daniel Karlsson <daniel.karlsson at liu.se> wrote: > Dear all, > > On s?n, 2012-03-18 at 13:57 +0100, Grahame Grieve wrote: >> Are discrete units only encountered in administrative directives? Do >> you prohibit people from making observations or measurements that >> include discrete units such as puffs, tablets, patches, vials, strips etc? > > There are examples of counting observables in both the laboratory and > clinical domains like "number of erythrocytes in urine", "number of > complement C3b receptors on thrombocytes", "number of petechiae of skin > per cm^2". > > If for example assuming the SI system base quantities, the kind of > quantity is "number" with "N" as symbol and "1" or "one" as the unit. > > Comparing to another commonly known kind of quantity, length, and the > unit "meter", "1.83 m" means 1.83 times the length of the Paris meter. > Further, my body height quantity inheres in my body and the unit "meter" > may be used to represent the length on a ratio scale, i.e. my body > height = 1.83 m or 1.83 times the Paris meter. However, this quantity > may be represented using other units such as the International foot. > > Going back to tablets, in "2 tablets 500 mg paracetamol" the part > "tablets 500 mg paracetamol" is not just a point of reference for > representing the number quantity but part if of the quantity being > observed (or stated). This part cannot be exchanged and thus cannot be a > unit. > > The DV_QUANTITY class has no attribute for specifying the kind of > quantity of which the magnitude field is a result of observation (or > decision). Previously, this has been managed within archetypes, e.g. the > systolic blood pressure quantity is referred to by binding the at0004 > code to the term "Systolic" and through this node's context within the > archetype. In instances, there is no reference to any kind of quantity > apart from units, which do not fully describe the kind of quantity, and > any reference to the archetype on which the instance is based. > > Thus, my 2-cent suggestion is to stay on the path, keep DV_QUANTITY > clean, and manage any issues around representation of doses in > archetypes. > > Finally, there is the whole science of metrology backing this up. Please > refrain from giving this solid ground up. > > Regards, > Daniel > >> >> why? >> >> HL7 does because we claim that you have to have UCUM codes >> so the data can be computable. If people simply want to exchange >> it in a structured but non-computable fashion... they can go to hell. >> And as for computable: we insist on a ucum code, and then say >> that for these discrete unit kind of things, well, you just put "1" for >> countable units, and then put the effective unit somewhere else - >> somewhere that no one can actually pull off in practice - because >> this is more "computable". Huh? We do not make sense on this. >> >> So much for HL7... what's openEHR's excuse? >> >> Grahame >> >> >> On Sun, Mar 18, 2012 at 11:18 PM, Thomas Beale >> <thomas.beale at oceaninformatics.com> wrote: >>> >>> As Grahame mentioned on an earlier post, the question of units is thorny. >>> Although we technical people would like to mandate UCUM or some other >>> well-designed computable syntax, on its own, it won't work. There seem to be >>> two reasons for this: >>> >>> it doesn't take care of the need for a displayable form of units, e.g. the >>> computable form 'mcg' or 'ug', where as the displayable is '?g' (Greek mu >>> followed by 'g') >>> it doesn't take care of 'units' like puffs, tablets, patches, vials, strips, >>> and other discrete delivery units >>> it doesn't take care of discrete delivery units per time, e.g. '2 puffs / >>> hour' >>> >>> Grahame and others have already done a lot of thinking on this here - there >>> are a lot of excellent examples from Linda Bird on the Singapore programme. >>> >>> The more I think about the last two above, the more I think it is not about >>> quantities per se but about an administration directive (how the patient >>> should take something). Trying to make Quantity do that kind of stuff >>> doesn't make sense to me - there is obviously a Quantity to indicate the >>> dose in scientific form, but another data element may be needed to indicate >>> how (in what discrete measures) to take the medication. >>> >>> I would therefore expect a distinct data element in the Medication Cluster >>> archetype rather than a re-engineered Quantity type to deal with these last >>> two. For the first one - displayable v computable, we will need a CR to >>> change DV_QUANTITY, and make it work like the FHIR Quantity - i.e. have a >>> second units field. >>> >>> Some of my earlier thoughts are actually on the above wiki page - the >>> concept of a DiscretisedQuantity type inheriting from Quantity, which I >>> think is also a reasonable alternative. >>> >>> what do others think? >>> >>> - thomas >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> openEHR-technical at lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
