Units, Quantities, etc
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
Units, Quantities, etc
Hi All, I think the units database that we have as part of openEHR tooling allows for the addition of equivalent and language dependent expressions, as well as conversion where that is possible. How about we make that available somewhere to get this going. It does mean we are not beholden to others and can know when we have UCUM compatible expressions (convert if necessary). Cheers, Sam -Original Message- From: openehr-technical-bounces at lists.openehr.org [mailto:openehr- technical-bounces at lists.openehr.org] On Behalf Of Thomas Beale Sent: Wednesday, 21 March 2012 11:15 PM To: openehr-technical at lists.openehr.org Subject: Re: Units, Quantities, etc On 21/03/2012 09:28, Grahame Grieve wrote: But the question around can you trust the data is, can you recognize properly when the units are ucum or not? For some reason I haven't put my finger on, you are linking the knowing of this with the boundary of the type. It's not clear to me why you're making that link. Grahame well... good question. So in other words: if there is a units field specifically for 'formal' units, is it UCUM only or not? I would have said it should be except for annoying problems like the one Heath mentioned - UCUM uses '*' for exponent instead of '^' which almost everyone else uses We could use the same approach as an openEHR DV_PARSABLE, where the name of the syntax is stored as well, but this is IMO inviting a different kind of pain... My answer would be: let's get UCUM doing everything we need (for the formal units field I mean, not the informal one); if we can't, we need a new UCUM. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr- technical_lists.openehr.org
Units, Quantities, etc
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
Units, Quantities, etc
But the question around can you trust the data is, can you recognize properly when the units are ucum or not? For some reason I haven't put my finger on, you are linking the knowing of this with the boundary of the type. It's not clear to me why you're making that link. Grahame On 19/03/2012, at 9:25 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 19/03/2012 02:15, Grahame Grieve wrote: 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 well any mathematical operation working on quantities - e.g. averages, max, min, variance, standard deviation etc etc. These kind of operations are ubiquitous in research queries, and will become increasingly so in personal health records. Just consider what is needed to determine the actual amount of tobacco consumed by each of 10,000 patients in a cohort - each of whom report their usage in terms of 'tailor-made cigarettes', 'hand-rolled cigarettes', 'cigars', 'chewing tobacco' (okay not popular, but still in use in some places!), 'grams a week (of pipe tobacco)', etc etc. Some patients have a mixture of these. Same argument for amounts of drugs taken by patients in a cancer study, amounts of sugar, salt, cholesterol computed from food recorded in patient diet and so on. How about a query that finds all patients with blood sugar over 7? What if they input the data (at home) in different unit systems due to different equipment? We simply can't do any useful computing if we can't trust the data. We don't do that much computing now with it because of the unreliability of the available data, but the only interesting future really is being able to do intelligent computing with the data. To get there we have to be able to compute reliably with quantities. I have no problem with data that records only 'puffs', 'patches', 'pessaries', 'pills', 'pellets' or 'powder' but we don't want to compromise data that record normal scientific quantities. Therefore I think we should be treating these kind of amounts as a separate type. This is distinct from the problem of Quantities that do have scientific units, but there is a conflict with the displayable form. I think we should accommodate that in the current data type - a small modification would take care of that. - thomas ___ 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/20120321/d6bf1d82/attachment.html
Units, Quantities, etc
On 21/03/2012 09:28, Grahame Grieve wrote: But the question around can you trust the data is, can you recognize properly when the units are ucum or not? For some reason I haven't put my finger on, you are linking the knowing of this with the boundary of the type. It's not clear to me why you're making that link. Grahame well... good question. So in other words: if there is a units field specifically for 'formal' units, is it UCUM only or not? I would have said it should be except for annoying problems like the one Heath mentioned - UCUM uses '*' for exponent instead of '^' which almost everyone else uses We could use the same approach as an openEHR DV_PARSABLE, where the name of the syntax is stored as well, but this is IMO inviting a different kind of pain... My answer would be: let's get UCUM doing everything we need (for the formal units field I mean, not the informal one); if we can't, we need a new UCUM. - thomas
Units, Quantities, etc
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 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 -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065
Units, Quantities, etc
well it's not prevented from being expressed; it's just expressed using a Quantity field (e.g. a DV_COUNT) and another field saying what you are counting (there are a reasonable number of examples of this already in the archetypes - number of cigarettes a day, number of previous pregnancies, number of steps taken in physiotherapy etc). If we made this a Quantity, we could in theory then use an instance to say '3 puffs'. But this is not an amount of substance, it's a count of 'delivery' units or 'grains' of substance. I still think Quantities should be computable as such - if we don't know how many mcg of substance 3 puffs is, we can't compute with it. ok, so you say it should be computable, but then allow a fixed unit of one, and some other code as well. And this in a subclass of Quantity, so you could always use it or encounter it in place of quantity. So if that's the case, why not simply make it a property of Quantity? What's really important is not that all Quantities are computable, but that you know whether you can compute with it. And in fact, making it a property of Quantity makes it easier to manage and/or constrain Grahame
Units, Quantities, etc
Hi Thomas, I had an issue recently were I was receiving HL7 V2 Lab messages with units such as x10^6/L, the equivalent in UCUM is 10*6/l, which was used in the archetype constraint for an RBC element. I translated the HL7 unit into the archetype constrained unit as required to be valid. However, when we displayed this in our application that was going through a conformance process for this particular Lab?s interface to allowed to retrieve messages within the enterprise, the Lab said that we *must* display the unit as x10^6/L as provided in the HL7 message. Therefore we had to translate it back again in our app? sigh. This scenario demonstrates this exact conversation. Personally I don?t like the idea of another attribute for displayable units. I am thinking that we need to have a means to lookup a particular set of ?displayable? units and get the computable unit for when we need to do any conversion, which I have yet to come across any need to do so in current implementations (not that this will not be required at some point but it will certainly be in very limited set of cases). I am thinking the units attribute should be our ?displayable?, and tat in cases where we need to convert to other units we provide a similar concept to mappings in DV_TEXT. Perhaps this should be the reverse, but because the displayable unit is the 99.99% use case I think we should make this the easiest representation with minimal change to RM. In archetypes, if the units attribute is allowed to any value, we can then specify a conversion mapping for each unit, which may allow multiple ?displayable? units to be defined and mapped to the same UCUM unit. So this conversion mapping is represented as knowledge in the archetype, but we also start getting some consistent representation of ?displayable? units without the weirdness of UCUM syntax. Hope this triggers further thoughts. Heath From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Thomas Beale Sent: Sunday, 18 March 2012 10:49 PM To: Openehr-Technical Subject: Units, Quantities, etc 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 http://www.healthintersections.com.au/wiki/index.php?title=Non-ucum_units_in_Quantity - 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/ce91de2c/attachment.html
Units, Quantities, etc
Hi Heath yes, this the problem. I don't know if your solution works. I've considered putting a service up in the cloud that provides a service to take represented units and convert them to ucum units. But it's a many to many mapping unless the conversion is actually done in the context of a specific LOINC code, in which case there's a huge amount of duplication of mapping work. Grahame On Mon, Mar 19, 2012 at 8:51 AM, Heath Frankel heath.frankel at oceaninformatics.com wrote: Hi Thomas, I had an issue recently were I was receiving HL7 V2 Lab messages with units such as x10^6/L, the equivalent in UCUM is 10*6/l, which was used in the archetype constraint for an RBC element. I translated the HL7 unit into the archetype constrained unit as required to be valid. However, when we displayed this in our application that was going through a conformance process for this particular Lab?s interface to allowed to retrieve messages within the enterprise, the Lab said that we *must* display the unit as x10^6/L as provided in the HL7 message. Therefore we had to translate it back again in our app? sigh. This scenario demonstrates this exact conversation. Personally I don?t like the idea of another attribute for displayable units.? I am thinking that we need to have a means to lookup a particular set of ?displayable? units and get the computable unit for when we need to do any conversion, which I have yet to come across any need to do so in current implementations (not that this will not be required at some point but it will certainly be in very limited set of cases). I am thinking the units attribute should be our ?displayable?, and tat in cases where we need to convert to other units we provide a similar concept to mappings in DV_TEXT. Perhaps this should be the reverse, but because the displayable unit is the 99.99% use case I think we should make this the easiest representation with minimal change to RM. In archetypes, if the units attribute is allowed to any value, we can then specify a conversion mapping for each unit, which may allow multiple ?displayable? units to be defined and mapped to the same UCUM unit.? So this conversion mapping is represented as knowledge in the archetype, but we also start getting some consistent representation of ?displayable? units without the weirdness of UCUM syntax. Hope this triggers further thoughts. Heath From: openehr-technical-bounces at lists.openehr.org [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of Thomas Beale Sent: Sunday, 18 March 2012 10:49 PM To: Openehr-Technical Subject: Units, Quantities, etc 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 -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065
Units, Quantities, etc
Verstuurd vanaf mijn iPhone Op 18 mrt. 2012 om 15:15 heeft Thomas Beale thomas.beale at oceaninformatics.com het volgende geschreven: I still think Quantities should be computable as such - if we don't know how many mcg of substance 3 puffs is, we can't compute with it. Although i tend to agree with you, this won't work because then you assume that we're talking about the absolute truth. The absolute truth only exist when you're talking, for instance, about astronomics. In medicine you can't say 25 ml of alcohol is lethal. You can only say something like: 25 ml of alcohol is lethal in an adult man of 80 kg. And only when he doesn't drink more than 15 unit alcohol ? week. When he drinks more then The lethal dose is higher. For ? roman of the same weight who drinks 15 units ? week, the lethal dose is lower. My point is that an absolute quantity alone doesn't meander much. At The other hand, we know empirically that if someone has smoked 15 pack years he's at serious risk. Then about puffs. I' m almost sure that you can translate ? puff info a volume. If i remember it correctly 40 drops is 1 ml. So the same should go for puffs. Cheers, Stef
Units, Quantities, etc
On 18/03/2012 21:45, Grahame Grieve wrote: ok, so you say it should be computable, but then allow a fixed unit of one, and some other code as well. And this in a subclass of Quantity, so you could always use it or encounter it in place of quantity. So if that's the case, why not simply make it a property of Quantity? because it only applies in a small number of cases. Most Quantity instances will never have this because they don't represent this kind of information. - thomas
Units, Quantities, etc
you'll still have to look, even though it's not many cases. Grahame On Mon, Mar 19, 2012 at 10:57 AM, Thomas Beale thomas.beale at oceaninformatics.com wrote: On 18/03/2012 21:45, Grahame Grieve wrote: ok, so you say it should be computable, but then allow a fixed unit of one, and some other code as well. And this in a subclass of Quantity, so you could always use it or encounter it in place of quantity. So if that's the case, why not simply make it a property of Quantity? because it only applies in a small number of cases. Most Quantity instances will never have this because they don't represent this kind of information. - thomas ___ openEHR-technical mailing list 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 / +61 411 867 065
Units, Quantities, etc
On 18/03/2012 21:51, Heath Frankel wrote: Hi Thomas, I had an issue recently were I was receiving HL7 V2 Lab messages with units such as x10^6/L, the equivalent in UCUM is 10*6/l, which was used in the archetype constraint for an RBC element. I translated the HL7 unit into the archetype constrained unit as required to be valid. However, when we displayed this in our application that was going through a conformance process for this particular Lab's interface to allowed to retrieve messages within the enterprise, the Lab said that we **must** display the unit as x10^6/L as provided in the HL7 message. Therefore we had to translate it back again in our app... sigh. This scenario demonstrates this exact conversation. Personally I don't like the idea of another attribute for displayable units. I am thinking that we need to have a means to lookup a particular set of displayable units and get the computable unit for when we need to do any conversion, which I have yet to come across any need to do so in current implementations (not that this will not be required at some point but it will certainly be in very limited set of cases). I think that might work theoretically, but it means establishing yet another terminology (or piece of SCT) that is going to take time to agree, and then has to be deployed and in every computing environment. I also don't think we can predict how much it will be used in the future - the future is all about computing with data, unlike today, where we are still just moving it around. I could be wrong - maybe the units work in SCT is further ahead than I think. The other problem is the problem of synonyms - there is not always a 1:1 mapping between display and computable forms. I am thinking the units attribute should be our displayable, and tat in cases where we need to convert to other units we provide a similar concept to mappings in DV_TEXT. Perhaps this should be the reverse, but because the displayable unit is the 99.99% use case I think we should make this the easiest representation with minimal change to RM. Well, that is only true if we think the data are only being used for display. But if the data need to be computed with - even if large research projects only start using openEHR data in a few years time - imagine the frustration when researchers discover non-computable units all over the place. In archetypes, if the units attribute is allowed to any value, we can then specify a conversion mapping for each unit, which may allow multiple displayable units to be defined and mapped to the same UCUM unit. So this conversion mapping is represented as knowledge in the archetype, but we also start getting some consistent representation of displayable units without the weirdness of UCUM syntax. we could do it that way we would need to look at some actual data examples and see if that would work. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/887557f7/attachment-0001.html
Units, Quantities, etc
On 18/03/2012 22:21, Stef Verlinden wrote: Verstuurd vanaf mijn iPhone Op 18 mrt. 2012 om 15:15 heeft Thomas Bealethomas.beale at oceaninformatics.com het volgende geschreven: I still think Quantities should be computable as such - if we don't know how many mcg of substance 3 puffs is, we can't compute with it. Although i tend to agree with you, this won't work because then you assume that we're talking about the absolute truth. The absolute truth only exist when you're talking, for instance, about astronomics. In medicine you can't say 25 ml of alcohol is lethal. You can only say something like: 25 ml of alcohol is lethal in an adult man of 80 kg. And only when he doesn't drink more than 15 unit alcohol ? week. When he drinks more then The lethal dose is higher. For ? roman of the same weight who drinks 15 units ? week, the lethal dose is lower. My point is that an absolute quantity alone doesn't meander much. At The other hand, we know empirically that if someone has smoked 15 pack years he's at serious risk. Then about puffs. I' m almost sure that you can translate ? puff info a volume. If i remember it correctly 40 drops is 1 ml. So the same should go for puffs. ok but you are still talking about making it computable somehow - by assuming 1ml = 40 drops or whatever. If we want a kind of quantity that accommodates only representation in non-systematic units, we should not mix this type up with a proper Quantity that can be used with 90% (or maybe its only 75%) of all clinical data. - thomas * * * * -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/a33f3164/attachment.html
Units, Quantities, etc
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 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 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 -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065 ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr. org
Units, Quantities, etc
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 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 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 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 -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065 ___ 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 -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065
Units, Quantities, etc
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.commailto:linda at mybirdfamily.com linda at mybirdfamily.commailto:li...@mybirdfamily.com Reply-To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto: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.orgmailto: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 Capsules, 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.aumailto:grah...@healthintersections.com.au Date: Mon, March 19, 2012 12:15 pm To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto: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.aumailto: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.aumailto: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.commailto: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
Units, Quantities, etc
On Mar 18, 2012 9:15 PM, Grahame Grieve grahame at healthintersections.com.au wrote: 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 wrote: Graham, I'm trying to ... -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/b7a7a778/attachment.html
Units, Quantities, etc
Well I'm still stuck trying to understand what you mean by 'computable'. And, no, a clinician cannot prescribe (just) 2 tablets -- I cannot compare that with 500 mg unless I know how much is in each tablet. Once you've told me how much is in each tablet, then (from a computability perspective), I may as well have just said 2 units. michael From: linda at mybirdfamily.commailto:linda at mybirdfamily.com linda at mybirdfamily.commailto:li...@mybirdfamily.com Reply-To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Date: Mon, 19 Mar 2012 16:26:31 +1100 To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org 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.aumailto:michael.law...@csiro.au Date: Mon, March 19, 2012 3:03 pm To: openehr-technical at lists.openehr.orgmailto: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.commailto:linda at mybirdfamily.commailto:linda at mybirdfamily.com linda at mybirdfamily.commailto:linda at mybirdfamily.commailto:li...@mybirdfamily.com Reply-To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.orgmailto: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.orgmailto:openehr-technical at lists.openehr.orgmailto: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 Capsules, 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.aumailto:grahame at healthintersections.com.aumailto:grah...@healthintersections.com.au Date: Mon, March 19, 2012 12:15 pm To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org for me, conversion between
Units, Quantities, etc
?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.aumailto:michael.law...@csiro.au Date: Mon, March 19, 2012 3:03 pm To: openehr-technical at lists.openehr.orgmailto: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.commailto:linda at mybirdfamily.commailto:linda at mybirdfamily.com linda at mybirdfamily.commailto:linda at mybirdfamily.commailto:li...@mybirdfamily.com Reply-To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.orgmailto: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.orgmailto:openehr-technical at lists.openehr.orgmailto: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 Capsules, 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.aumailto:grahame at healthintersections.com.aumailto:grah...@healthintersections.com.au Date: Mon, March 19, 2012 12:15 pm To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.orgmailto: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
Units, Quantities, etc
On 19/03/2012 02:15, Grahame Grieve wrote: 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 * * well any mathematical operation working on quantities - e.g. averages, max, min, variance, standard deviation etc etc. These kind of operations are ubiquitous in research queries, and will become increasingly so in personal health records. Just consider what is needed to determine the actual amount of tobacco consumed by each of 10,000 patients in a cohort - each of whom report their usage in terms of 'tailor-made cigarettes', 'hand-rolled cigarettes', 'cigars', 'chewing tobacco' (okay not popular, but still in use in some places!), 'grams a week (of pipe tobacco)', etc etc. Some patients have a mixture of these. Same argument for amounts of drugs taken by patients in a cancer study, amounts of sugar, salt, cholesterol computed from food recorded in patient diet and so on. How about a query that finds all patients with blood sugar over 7? What if they input the data (at home) in different unit systems due to different equipment? We simply can't do any useful /computing /if we can't trust the data. We don't do that much computing now with it because of the unreliability of the available data, but the only interesting future really is being able to do intelligent computing with the data. To get there we have to be able to compute reliably with quantities. I have no problem with data that records only 'puffs', 'patches', 'pessaries', 'pills', 'pellets' or 'powder' but we don't want to compromise data that record normal scientific quantities. Therefore I think we should be treating these kind of amounts as a separate type. This is distinct from the problem of Quantities that do have scientific units, but there is a conflict with the displayable form. I think we should accommodate that in the current data type - a small modification would take care of that. - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120319/d866d2e2/attachment.html
Units, Quantities, etc
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
Units, Quantities, etc
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 http://www.healthintersections.com.au/wiki/index.php?title=Non-ucum_units_in_Quantity - 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120318/ead04269/attachment.html
Units, Quantities, etc
On 18/03/2012 12:57, 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? I don't think so; a physician could obviously ask a patient how many ventolin puffs they take a day. 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? well it's not prevented from being expressed; it's just expressed using a Quantity field (e.g. a DV_COUNT) and another field saying what you are counting (there are a reasonable number of examples of this already in the archetypes - number of cigarettes a day, number of previous pregnancies, number of steps taken in physiotherapy etc). If we made this a Quantity, we could in theory then use an instance to say '3 puffs'. But this is not an amount of substance, it's a count of 'delivery' units or 'grains' of substance. I still think Quantities should be computable as such - if we don't know how many mcg of substance 3 puffs is, we can't compute with it. That's why it seemed to me that if we are going to try and bind this counting concept with a Quantity concept, then we need a dedicated subtype like DiscretisedQuantity that adds in the info of '3 puffs' to a Quantity that can represent '30 mcg'. - thomas
Units, Quantities, etc
An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120318/0409f490/attachment.html
Units, Quantities, etc
An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120318/0c499a6d/attachment.html
