?tablet? ?capsule? and ?box? are all quantities that only make sense when you know the context. mcg and 10^-6/L are measurement units that do not need a context.
That?s not to say that ?tablets? etc. should not be recorded in the eHR, just that their usefulness depends on the context being linkable, or ambiguity will result. Regards, Colin From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of li...@mybirdfamily.com Sent: Monday, 19 March 2012 4:27 PM To: For openEHR technical discussions Subject: RE: Units, Quantities, etc Sorry Michael - I don't follow your reasoning. In clinical practice, a clinician may either order a dose of '2 tablets' or alternatively '500 mg'. I would argue that these are both equally 'computable', given the appropriate knowledge base. Regards, Linda. ___________________________________________________________ Dr Linda Bird Information Architect Ph: 0411 274 870 ____________________________________________________________ -------- Original Message -------- Subject: Re: Units, Quantities, etc From: <Michael.Lawley at csiro.au<mailto:michael.law...@csiro.au>> Date: Mon, March 19, 2012 3:03 pm To: <openehr-technical at lists.openehr.org<mailto:openehr-technical at lists.openehr.org>> Hi Linda, I think your first example demonstrates why "tablet" is not a "Unit" -- I could equally say: "2 Mountains" of "Paracetamol 500 mg + Codeine Phosphate 15mg Mountains" is therapeutically equivalent to "1 Mountain" of "Paracetamol 1g + Codeine Phosphate 30 mg Mountains" Really what I am saying here is: 2 of "Paracetamol 500 mg + Codeine Phosphate 15mg Tablet" is therapeutically equivalent to 1 of "Paracetamol 1g + Codeine Phosphate 30 mg Tablet" In your next example, both orders are for "500mg of Amoxicllin" in "capsule form" but the second case also says "1 capsule" and carries with it a business rule that says you cannot convert this. However, it still doesn't change the "therapeutically equivalent" relation. That is, "therapeutically equivalence" should be treated separately from "can be substituted for when dispensing". michael From: "linda at mybirdfamily.com<mailto:linda at mybirdfamily.com><mailto:linda at mybirdfamily.com>" <linda at mybirdfamily.com<mailto:linda at mybirdfamily.com>><mailto:li...@mybirdfamily.com>> Reply-To: For openEHR technical discussions <openehr-technical at lists.openehr.org<mailto:openehr-technical at lists.openehr.org>><mailto:openehr-technical at lists.openehr.org>> Date: Mon, 19 Mar 2012 14:56:39 +1100 To: For openEHR technical discussions <openehr-technical at lists.openehr.org<mailto:openehr-technical at lists.openehr.org>><mailto:openehr-technical at lists.openehr.org>> Subject: RE: Units, Quantities, etc Ok ... can't resist replying ... Doesn't 'computability' depend on having clearly defined rules on how the UOMs relate to each other? Yes, UCUM provides this - however I don't understand why (in the context of a national program), we would exclude another terminology-based knowledge source (e.g. a SNOMED CT extension) providing these computational rules. If, for example, we referred to "2 tablets" of "Paracetamol 500 mg + Codeine Phosphate 15 mg Tablet", and we have a knowledge base that tells us that each of these tablets has "500 mg" of Paracetamol and "15 mg" of Codeine Phosphate, then we can compute that: "2 tablets" of "Paracetamol 500 mg + Codeine Phosphate 15mg Tablet" is therapeutically equivalent to "1 tablet" of "Paracetamol 1g + Codeine Phosphate 30 mg Tablet" This is just one of many 'computations' which are possible with an additional knowledge base that is very useful for decision-support purposes. Clinicians may order "500 mg" of "Amoxicillin Capsule"s, or "1 capsule" of "Amoxicllin 500 mg Capsule" ... and these actually mean different things (the former could either mean 1 x 500 mg capsule, 2 x 250 mg capsules, etc; while the later specifically means 1 x 500 mg capsule). In the case of simple dosing, clinicians would expect to see only 2 fields - dose_value and dose_units, irrespective of whether the units is "mg" or "capsules" ... with the knowledge base determining the 'computability' rules. Regards, Linda. ___________________________________________________________ Dr Linda Bird Information Architect Ph: 0411 274 870 ____________________________________________________________ -------- Original Message -------- Subject: Re: Units, Quantities, etc From: Grahame Grieve <grahame at healthintersections.com.au<mailto:grahame at healthintersections.com.au>><mailto:grah...@healthintersections.com.au>> Date: Mon, March 19, 2012 12:15 pm To: For openEHR technical discussions <openehr-technical at lists.openehr.org<mailto:openehr-technical at lists.openehr.org>><mailto:openehr-technical at lists.openehr.org>> for me, conversion between different units that are comparable. You should ask Tom what else he thinks it yields up. I'd be interested. Grahame On Mon, Mar 19, 2012 at 11:06 AM, <Michael.Lawley at csiro.au<mailto:Michael.Lawley at csiro.au>><mailto:Michael.Lawley at csiro.au>> wrote: > > Graham, > > I'm trying to make sense of this discussion around "computability" -- what > are the kinds of things that one wants to "compute" with these kinds of > countable things? > > michael > > On 18/03/12 10:57 PM, "Grahame Grieve" > <grahame at healthintersections.com.au<mailto:grahame at > healthintersections.com.au>><mailto:grahame at healthintersections.com.au>> > 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? >> >>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<mailto:thomas.beale at >>oceaninformatics.com>><mailto: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<mailto:openEHR-technical at >>> lists.openehr.org><mailto:openEHR-technical at lists.openehr.org> >>> >>>http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr >>>.org >> >> >> >>-- >>----- >>http://www.healthintersections.com.au / >>grahame at healthintersections.com.au<mailto:grahame at >>healthintersections.com.au><mailto:grahame at healthintersections.com.au> / >>+61 411 867 065 >> >>_______________________________________________ >>openEHR-technical mailing list >>openEHR-technical at lists.openehr.org<mailto:openEHR-technical at >>lists.openehr.org><mailto: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<mailto:openEHR-technical at > lists.openehr.org><mailto:openEHR-technical at lists.openehr.org> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- ----- http://www.healthintersections.com.au / grahame at healthintersections.com.au<mailto:grahame at healthintersections.com.au><mailto:grahame at healthintersections.com.au> / +61 411 867 065 _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org<mailto:openEHR-technical at lists.openehr.org><mailto: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<mailto:openEHR-technical at lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org ##################################################################################### This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal ##################################################################################### #################################################################################################################### IMPORTANT NOTICE: This e-mail and any attachment to it are intended only to be read or used by the named addressee. It is confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistaken transmission to you. The CTC is not responsible for any unauthorised alterations to this e-mail or attachment to it. Views expressed in this message are those of the individual sender, and are not necessarily the views of the CTC. If you receive this e-mail in error, please immediately delete it and notify the sender. You must not disclose, copy or use any part of this e-mail if you are not the intended recipient. ##################################################################################################################### -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/a3051c9a/attachment-0001.html>