Re: openEHR-technical Digest, Vol 51, Issue 17

nd < >>>> silje.ljosland.ba...@nasjonalikt.no> wrote: >>>> >>>> They usually are, though the units file in the Archetype Editor has had >>> (still has?) a lot of errors in it, which means the correct units had to be >>> edited into the ADL by hand. I ma

Re: openEHR-technical Digest, Vol 51, Issue 17

n of the units file for >> the AE a while ago, but there were some issues with it that I'm not sure if >> have been solved or if it's made its way into a release. >>> >>> Regards, >>> Silje >> >> >> __

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 th

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, or

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 u

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. https://openehr.atlassian.net/browse/AEPR-44?focusedCommentId=14127&page=com.atlassian.jira.plugin.system.issuetabpanel

AW: Archie version 0.1.0 released

My congratulations too, Pieter! To add to Thomas, a perfectly redundant wheel-reinvention based on the specs also validates the specs nicely and highlights potential problems/inaccuracies/underspecified things in the underlying specs as we have seen previously with the various 1.4 implementatio

Re: Archie version 0.1.0 released

Thomas, I couldn't agree more. Not only on license but also on technical architectural approach this is not just another library, but a library with unique possibilities, some will maybe be discovered later, when someone needs them. It is nicely programmed, easy to understand and walk through

Re: Archie version 0.1.0 released

I'm sure something can be worked out. Not my call personally of course. But just a thought for everyone who instantly thinks 'oh no, not another wheel re-invention'... the work described here probably is slightly re-inventing something, but as Pieter has said, there are overlaps and also uniqu

RE: UCUM code in body temperature archetype

Ah yes, that's definitely not right. There are actually two blood glucose archetypes, and the other one has 'IU' (which should be [iU]). Probably all of the current OBSERVATION.lab_test* and OBSERVATION.pathology_test* archetypes should be deprecated and (some of them) redone as either cluster

Re: UCUM code in body temperature archetype

Hi Silje, ‘U’ is used in the lab_test-blood_glucose archetype. I also think that 10*12/l, 10*6/l, 10*6/mm3, 10*9/l are all valid UCUM codes. In fact UCUM’s table 26 Example Unit Terms by Term lists 10*6/mm3 as legal with a preferred alternative of /pL . It also lists the following alternatives:

RE: UCUM code in body temperature archetype

Hah, thanks for that correction, I completely missed the '0' instead of 'O' and the 'mho'. :) 'U' is certainly wrong if used for international units, as you say, but for the liver tests ALP, ALT, AST, GGT and LD the test is actually measuring catalytic activity, so U/L should be correct. Not

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 Ap

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 yo

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

I believe that anything between brackets can be considered a correct UCUM 2016-05-18 14:35 GMT+02:00 Bakke, Silje Ljosland : > Awesome! These can be classified into UCUM, non-UCUM and just plain wrong: > > UCUM: > 1/min, Hz, Hz/s, U, U/l, cm2, cm[H20], d, daPa, daPa/s, deg, h, kHz, kPa, kg, > kg/

RE: UCUM code in body temperature archetype

They usually are, though the units file in the Archetype Editor has had (still has?) a lot of errors in it, which means the correct units had to be edited into the ADL by hand. I made a better version of the units file for the AE a while ago, but there were some issues with it that I'm not sure

RE: UCUM code in body temperature archetype

Awesome! These can be classified into UCUM, non-UCUM and just plain wrong: UCUM: 1/min, Hz, Hz/s, U, U/l, cm2, cm[H20], d, daPa, daPa/s, deg, h, kHz, kPa, kg, kg/m2, l, l/min, l/s, m, m2, mV, mg, mg/dl, mg/l, min, ml, ml/d, ml/ml, ml/s, ml/wk, mm, mm/h, mm2, mm[H20], mm[H20]/s, mm[Hg], mmol/l, p

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 Wed, May 18, 2016 at 01:5

AW: UCUM code in body temperature archetype

Yes, unfortunately. I have even implemented a Validation Check named VUI for this in CKM after these discussion, so that this is not forgotten, because I too think it is important to get this right... This check is available for each archetype (or for all archetypes from Reports/Validation Repo

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. W

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 °). > > https://en.w

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 E167

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 to

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, 1/min, 10*12/l, 10*6/l, 10*6/mm3, 10*

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 basic

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, gm

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, Diego Boscá wrote: >>

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 s

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 differentia

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 : >> >> On 18/05/2016 12:21, Grahame Grieve wro

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 ago was to use the UCUM strin

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 contex

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 seco

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 better

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 b

Re: Archie version 0.1.0 released

Hello Diego, That is possibly, but has some complications: To make a dual licensing approach work in this case it would requires us to release Archie under the AGPL, combine it with adl2-core and get a license from Marand to use their contributions to the resulting library in our products comb

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, > > For the use case rais

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 offi

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: ianmcnicoll

Re: UCUM code in body temperature archetype

In DV_CODED_TEXT there are three mandatory attributes: DV_TEXT.value, DV_CODE_PHRASE.terminology_id, DV_CODE_PHRASE.code_string, i.e. 50 % overkill only ;) /Daniel On 2016-05-18 11:11, Grahame Grieve wrote: That's overkill - just have two fields, human and computable units. Grahame On 18 Ma

Re: Archie version 0.1.0 released

Nice wok Piter! I've seen quite a lot of open source projects with dual licensing. Maybe this is the way to go so we can please everyone Regards 2016-05-18 11:06 GMT+02:00 Pieter Bos : > Hi Ian, > > Good to hear this work is being appreciated. > > It could certainly be possible to merge Archie w

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, Silje Ljosland wrote: >> Th

Re: Archie version 0.1.0 released

Hi Ian, Good to hear this work is being appreciated. It could certainly be possible to merge Archie with the existing adl2-core library. I think the adl2-core library looks like it has good quality code and decent API. It could be interesting because although there is quite a bit of overlap in

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 th

Re: Archie version 0.1.0 released

Hi Pieter, This looks a really interesting and valuable piece of work. Many thanks for your efforts - hopefully others will want to contribute. It would be nice if we could somehow bring this work and the existing AOM2/ADL2 work together (or at least not duplicate work). I appreciate there is a di

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 (w

UCUM code in body temperature archetype

Dear All, it seems the UCUM code for the temperature units in the Body temperature archetype is wrong. It uses the UCUM print symbol, e.g. "°C", rather than the UCUM code "Cel". http://www.openehr.org/ckm/#showArchetype_1013.1.49 Regards, Daniel -- Daniel Karlsson, PhD, sr lecturer Departme