Re: UCUM code in body temperature archetype

I agree with Thomas. Speaking as someone who has had to help with quality control of large amounts of user entered concomitant medication data for clinical trials, ‘tablet’ , ‘capsule’, and similar are not ‘units’ unless they are associated with other reference data. ‘Tablet' is a description

Re: UCUM code in body temperature archetype

On 19/05/2016 08:26, Ian McNicoll wrote: Hi Thomas, I appreciate that the Quantity classes add computability such as the +,-,=, diff operators etc but computability (or at least safe/sensible computability) is not a given even when the two operands share the same unit. it might not be

Re: UCUM code in body temperature archetype

Here in Spain there is an official terminology for medication dispensation. It is partially mapped to snomed (and the remaining ones will be part of snomed national extension) In my opinion, it makes perfect sense to allow the specification of 'units' from other (non-ucum) terminologies, such as

Re: UCUM code in body temperature archetype

Hi Gerard, "The consequence is that SNOMED must be a complete Medicinal Product Formulary. I have doubts whether this is a good idea.' dm+d is a UK health-service managed dictionary based on SNOMED CT and using the UK national namespace i.e. it is not managed internationally. It is a complete

Re: UCUM code in body temperature archetype

In 2012 a number of ISO standards were published on the “Identification of medicinal products” When I recall correctly there is one that deals with the representation of dose forms, units of presentation and route of administration. Jan Talmon > On 19 mei 2016, at 10:19, Gerard Freriks

Re: UCUM code in body temperature archetype

An alternative for dealing with semantic in archetypes is dealing with semantics in coding systems like SNOMED. The consequence is that SNOMED must be a complete Medicinal Product Formulary. I have doubts whether this is a good idea. Many countries have different specific formularies. I like to

Re: UCUM code in body temperature archetype

Hi Thomas, In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for dose units because the latter are expressed as SNOMED terms, and are used in conjunction with the SNOMED-based dm+d (or AMT) drug dictionary to compute actual doses/amounts where possible. e.g. 318421004 |

Re: UCUM code in body temperature archetype

Two reactions: 1- There is a difference between the world of semantic interpretability in system interfaces and the real word of users looking at screens, and typing on keyboards In one world we can/must use as much as possible SI units via UCUM and strife for as detailed as possible reducing

Re: UCUM code in body temperature archetype

Hi Thomas, I appreciate that the Quantity classes add computability such as the +,-,=, diff operators etc but computability (or at least safe/sensible computability) is not a given even when the two operands share the same unit. Nor does the fact that a unit is non-scientific invalidate the use

Re: UCUM code in body temperature archetype

Hi Gerard, they actually could be, but whenever this discussion comes up, no-one proposes it. I'm not sure if I would either, because these arbitrary units are still not computable in general, but 'dose units' can be made computable but only with some extra data fields, i.e. you need both the

Re: UCUM code in body temperature archetype

Thomas, All are Units of a different kind. SI defines: Units of Measure, and Units of Quantity in the scientific domain. There are also Units of Time: minute, hour, etc. When I think of tablets, capsule, etc. we will call these Units of Medicinal Product Dose. Isn’t in UCUM this an example of

Re: UCUM code in body temperature archetype

well, it's a question of where you keep your complexity and uncertainty. Sure, you can exclude the uncertainty from the data type, and retain clear and simple operations associated with the type. But that doesn't mean that uncertainty goes away. You've just pushed it somewhere else. I agree that

Re: UCUM code in body temperature archetype

Grahame, I think you are saying that you can implement the /semantics /of dose units with just a DvQantity / FHIR Quantity. If 'dose units' includes the knowledge of the discrete unit of delivery, i.e. table, drop etc, as well as total amount, you can't. You need at least the elements here,

Re: UCUM code in body temperature archetype

Hi You missed my point. I assume that the content model will differentiate between ucum code and some other code, so as to enable all the behaviour you describe. But you don't need to force the use of a different element in a different place of the model. Merely differentiating the terminology

Re: UCUM code in body temperature archetype

Hi Peter, I think I did manage to identify and fix that particular problem locally but was stumped by this wider issue of whether how/if we display code / human version or both.

RE: UCUM code in body temperature archetype

: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Eric Browne Sent: Wednesday, May 18, 2016 4:30 PM To: For openEHR technical discussions <openehr-technical@lists.openehr.org> Subject: Re: UCUM code in body temperature archetype Hi Silje, 'U' i

Re: UCUM code in body temperature archetype

gards, > Silje > > -Original Message- > From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] > On Behalf Of Eric Browne > Sent: Wednesday, May 18, 2016 3:49 PM > To: For openEHR technical discussions <openehr-technical@lists.o

Re: UCUM code in body temperature archetype

Unfortunately Silje, not quite correct. The eye deceiveth. The construct [H20] is not valid UCUM. In none of the CKM archetypes did I find the correct UCUM code [H2O]. A zero has been substituted for the letter ‘O’. An easy mistake for a human to make. H20 even mistakenly appears 4 times in

Re: UCUM code in body temperature archetype

Hi Silje, Yes, it was at the end of October that I was trying to get it to work. A DataGrid in AE was throwing exceptions, complaining about duplicates because the property_id and text fields have to form a unique key. I did manage to find and remove one pair of duplicates from the file that

Re: UCUM code in body temperature archetype

Eric, One thing I had better do is re-instate my UCUM string checker in the ADL Workbench... thanks for the timely warning. - thomas On 18/05/2016 12:59, Eric Browne wrote: Dear All, There are many, many, many archetypes in the various openEHR CKMs that DO NOT, I repeat DO NOT, I repeat

Re: UCUM code in body temperature archetype

s to be represented using curly braces, like > {puff} or {tablet} as symbols for the default unit '1'. > > Regards, > Silje > > > -Original Message- > From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] > On Behalf Of Eric Browne > Sent: Wed

RE: UCUM code in body temperature archetype

hnical-boun...@lists.openehr.org] Im Auftrag von Eric Browne Gesendet: Mittwoch, 18. Mai 2016 14:00 An: For openEHR technical discussions <openehr-technical@lists.openehr.org> Betreff: Re: UCUM code in body temperature archetype Dear All, There are many, many, many archetypes in the various

RE: UCUM code in body temperature archetype

or openEHR technical discussions <openehr-technical@lists.openehr.org> Subject: Re: UCUM code in body temperature archetype I just did a bulk download of 133 Observation archetypes from ckm.openehr.org and extracted the following list of units:- /d, /h, /min, /mo, /wk, 1/min, 10*12/l, 10*6/l

Re: UCUM code in body temperature archetype

On Wed, May 18, 2016 at 02:12:39PM +0200, Diego Boscá wrote: > You are right, but not my main point ;) Actually, it sort of is. It shows that the same symbol can mean different things to different people :-) Karsten > 2016-05-18 14:10 GMT+02:00 Karsten Hilbert : > > On

Re: UCUM code in body temperature archetype

When we register a coded value, we store the terminology and the code. The display or rubric of it can be used for example to communicate data to a system that may not have access to the complete terminology, so that a human user can understand it. This behavior should not be different for units.

Re: UCUM code in body temperature archetype

You are right, but not my main point ;) 2016-05-18 14:10 GMT+02:00 Karsten Hilbert : > On Wed, May 18, 2016 at 01:56:00PM +0200, Diego Boscá wrote: > >> If you have a human-readable form for 'º' as "degree" > > That's the "o" in "numero", as in Nº, not degree (which is

Re: UCUM code in body temperature archetype

On Wed, May 18, 2016 at 01:56:00PM +0200, Diego Boscá wrote: > If you have a human-readable form for 'º' as "degree" That's the "o" in "numero", as in Nº, not degree (which is °). https://en.wikipedia.org/wiki/Numero_sign Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net

Re: UCUM code in body temperature archetype

Dear All, There are many, many, many archetypes in the various openEHR CKMs that DO NOT, I repeat DO NOT, I repeat DO NOT use valid UCUM codes for units in various DV_QUANTITY elements. I would guess up to 30% of Observation archetypes have some ‘invalid' UCUM unit. I spent some time trying

Re: UCUM code in body temperature archetype

very interesting, seems like a few archetypes need to be changed 2016-05-18 14:03 GMT+02:00 Eric Browne : > I just did a bulk download of 133 Observation archetypes from ckm.openehr.org > and extracted the following list of units:- > > /d, /h, /min, /mo, /wk,

Re: UCUM code in body temperature archetype

I knew someone would say that;-) But it's not for some principle of ontological purity. It's for the most basic practical reasons. Consider a quantity / units library designed based on a rigorous model of units, like UCUM (which is a very good and rigorous piece of work), and also other

Re: UCUM code in body temperature archetype

I just did a bulk download of 133 Observation archetypes from ckm.openehr.org and extracted the following list of units:- /d, /h, /min, /mo, /wk, 1/min, 10*12/l, 10*6/l, 10*6/mm3, 10*9/l, Ashman units, Hz, Hz/s, IU, U, U/l, [pH], cc, cm, cm2, cm[H20], d, dB, daPa, daPa/s, deg, fl, fl oz, ft,

Re: UCUM code in body temperature archetype

If you have a human-readable form for 'º' as "degree" you probably want that non-english speaking countries can put "grado" 2016-05-18 13:52 GMT+02:00 Grahame Grieve : > Really? No one has ever brought that to us as an requirement > > Grahame > >> On 18 May 2016, at 9:48 PM,

Re: UCUM code in body temperature archetype

On 18/05/2016 12:24, Ian McNicoll wrote: Hi thomas, See https://openehr.atlassian.net/browse/SPECPR-96 for discussion on this. Medication dose and quantities need both SI units and otherwise. The current restrictions make the modelling much clunkier than is necessary IMO. I'm not clear why

Re: UCUM code in body temperature archetype

The arbitrary units are something different, but why does that matter at the data type level? If you understand the unit, you can work with it, if you don't you can't. Separating them because of ... Ontological ... Purity: just creates make -work for all the users who otherwise don't

Re: UCUM code in body temperature archetype

Really? No one has ever brought that to us as an requirement Grahame > On 18 May 2016, at 9:48 PM, Diego Boscá wrote: > > And we probably want that the human-readable form can be multilingual as well. > > 2016-05-18 13:41 GMT+02:00 Thomas Beale :

Re: UCUM code in body temperature archetype

And we probably want that the human-readable form can be multilingual as well. 2016-05-18 13:41 GMT+02:00 Thomas Beale : > > On 18/05/2016 12:21, Grahame Grieve wrote: > > The main problem is that ucum units are not human readable units, > > > right - my idea 13 years

Re: UCUM code in body temperature archetype

On 18/05/2016 12:21, Grahame Grieve wrote: The main problem is that ucum units are not human readable units, right - my idea 13 years ago was to use the UCUM string as a key into something that generated a human-readable form. For reasons that became clearer since, I think we all agree that

Re: UCUM code in body temperature archetype

Hi thomas, See https://openehr.atlassian.net/browse/SPECPR-96 for discussion on this. Medication dose and quantities need both SI units and otherwise. The current restrictions make the modelling much clunkier than is necessary IMO. I'm not clear why strict adherence to SI is helpful in this

Re: UCUM code in body temperature archetype

The main problem is that ucum units are not human readable units, and trying to force them to be will generate substantial pushback from end users. In USA, this is an open problem for CDA adoption. In Australia, I solved it by declaring that we would never retire valid ucum units in CDA. A

Re: UCUM code in body temperature archetype

Hi Ian As far as I know, 'dose units' are not scientific units as such; they're measures of discrete objects (including 'puffs' etc), which don't fit into a clean grammar of scientific units, and trying to do so will just ruin the former. We do of course need dose units, but we need a

Re: UCUM code in body temperature archetype

It's not out of the question, although my view was always that the units string should be parsed and then rendered using one of the other columns of UCUM, or even something else. But this does as Silje says, put more work on to implementers, so we probably should consider a CR on the RM to add

Re: UCUM code in body temperature archetype

Hi Daniel, the reason it is a String is because we have always treated UCUM units as parseable strings. E.g. kg.m^-2 and kg/m^2 are parseable according to UCUM's grammar into an expression that has a single meaning, and can also

Re: UCUM code in body temperature archetype

Yes you're right. We need to allow snomed units there etc. but we use quantity for more than openehr does, so I thought you might be able to just have ucum. So you might as well copy FHIR then Grahame > On 18 May 2016, at 7:22 PM, Ian McNicoll wrote: > > Hi Grahame, > >

Re: UCUM code in body temperature archetype

One option might be simply to do a per FHIR and 'hardwire' code + code system, alongside units. This would retain backward compatibility. It would prevent us using DV_TEXT features like mapping but in many respects that might not be a bad thing. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859

Re: UCUM code in body temperature archetype

Hi Grahame, For the use case raised, I agree, but there other considerations e.g. Dose units and other non-UCUM code use - in the UK there is a desire to use SNOMED terms for dose units. FHIR has human + code + system for quantity units, I think? Ian Dr Ian McNicoll mobile +44 (0)775 209 7859

Re: UCUM code in body temperature archetype

Hi Daniel, This is being discussed by the Specs group as part of a different CR around use of 'dose units' but would mean a breaking change, so is tricky. https://openehr.atlassian.net/browse/SPECPR-96 Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype:

Re: UCUM code in body temperature archetype

That's overkill - just have two fields, human and computable units. Grahame > On 18 May 2016, at 7:05 PM, Daniel Karlsson wrote: > > So, right now the DV_QUANTITY.units is a String, perhaps it should be > DV_CODED_TEXT? > > /Daniel > >> On 2016-05-18 10:25, Bakke,

Re: UCUM code in body temperature archetype

So, right now the DV_QUANTITY.units is a String, perhaps it should be DV_CODED_TEXT? /Daniel On 2016-05-18 10:25, Bakke, Silje Ljosland wrote: This imposes a larger implementation burden on the systems who will have to be able to read UCUM codes and show the corresponding symbol instead of

RE: UCUM code in body temperature archetype

Hi Daniel, You’re 100% correct. This error is corrected in the branch I uploaded after the Norwegian body temp archetype was published, but this hasn’t been taken into the trunk yet as it contains some other major changes. As a general observation, an issue with using UCUM units in archetype