Hi Grahame, Wed 2012-03-21 klockan 10:26 +0100 skrev Grahame Grieve:
> 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? Why not just treat numbers (or counts) as any other quantity? There might be a case for providing a field for specifying the kind of quantity in the DV_QUANTITY class, but as in the example below, this is often includes more complex terminology-information model constructs than a single field. > > > 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. Well, I still think it's true! What's in a code and what's not is a matter of the terminology binding assumptions made in the specific situation. This kind of "post-coordination" (depending on what is meant by this term) is happening constantly with e.g. laboratory medicine where the kind of property observed is stated using a code from a terminology like LOINC or, even better, NPU ;). This code does however in most cases not specify the procedure to a sufficient degree so this information is added in the message thereby adding to the meaning of the code. The same is done for sample material and sample location. I would prefer this solution to overloading the unit with things that break the assumptions of metrology. /Daniel > > 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 > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/7f557f8b/attachment.html>
