Re: AW: AW: Quantities of arbitrary units in openEHR

We should fix this documentation - can you create a PR for this? thanks - thomas On 26/01/2018 07:53, Sebastian Garde wrote: it certainly specifies it . If there are tools and implementations

Re: Quantities of arbitrary units in openEHR

On 26-01-18 10:40, Bakke, Silje Ljosland wrote: (We are literally talking about a 'public available UCUM service') I don't think that is necessary, UCUM is a very small service, which can also be in software as a library or small external service in microservice architecture.

Re: Quantities of arbitrary units in openEHR

maybe something like this ELEMENT[at0004] occurrences matches {0..1} matches { -- One element value existence matches {0..1} matches { DV_QUANTITY occurrences matches {0..1} matches { -- DV_QUANTITY

Re: Quantities of arbitrary units in openEHR

Ia gree with Diago. UCUM basicly is a terminological system. GF Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 26 Jan 2018, at 09:41, Diego Boscá wrote: > > I think there are several potential problems with this, and

Re: Quantities of arbitrary units in openEHR

I think there are several potential problems with this, and IMHO we are stepping too much on what should be done in a terminology service (We are literally talking about a 'public available UCUM service'). You can also ask the terminology service what kind of unit code you have. Your

RE: Quantities of arbitrary units in openEHR

Deriving the properties from the codes makes sense when you actually specify the codes, but what do you do when you want to specify “this is a concentration, but I don’t care about the exact units”? “Arbitrary unit” has a quite specific meaning, it’s not just a catch-all for “new units for

RE: Quantities of arbitrary units in openEHR

This sounds good in theory, but I don’t think it’ll help me with my modelling in the next couple of weeks? ☺ Regards, Silje From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Diego Boscá Sent: Friday, January 26, 2018 10:18 AM To: For openEHR technical

Re: Quantities of arbitrary units in openEHR

The thing I am not a fan of is that units themselves become part of terminology. This is a SNOMED direction but I think a wrong one. The reason is that the ontology of units isn't the same as the ontology of findings, medications and so on. In fact they all have different ontologies, and

Re: Quantities of arbitrary units in openEHR

In my mind, this should be done not by fixing a property but by defining a constraint reference pointing to the service/set of codes that can provide you with all mass units 2018-01-26 10:00 GMT+01:00 Bakke, Silje Ljosland < silje.ljosland.ba...@nasjonalikt.no>: > Deriving the properties from

Re: Quantities of arbitrary units in openEHR

Ah I was being dense, I thought you were talking about the units field, not the property field. In that case, what would it mean if property were set to 'Arbitrary' - does that mean the units has to be from the current list of arbitrary units, which is not-length, not-pressure, not-everything

AW: Quantities of arbitrary units in openEHR

While I agree with the SPEC-95 rationale (once you have a unit, you should be able to know what its property is), it is still convenient to have the property for constraining. Otherwise you don't have a way to say in an archetype: I don't care about the exact unit here, but please let it be a

Re: Quantities of arbitrary units in openEHR

Right - at the moment, it is a 'fake' field in archetypes, enabled by being in the BMM or other expression of the RM. It's convenient to do this occasionally, since we don't think 'property' needs to be a field of DV_QUANTITY - but maybe it should be, since for some of the more esoteric units,

Re: AW: AW: Quantities of arbitrary units in openEHR

On 26-01-18 08:53, Sebastian Garde wrote: This is where I think that not only it is stated that openEHR uses UCUM (and not some part or “inspiration” of it), but also implies that the case sensitive version of it is used (which in my view is important to know at least for some of the units). I

Re: AW: AW: Quantities of arbitrary units in openEHR

On 26-01-18 14:27, Thomas Beale wrote: yes I agree with this. We should do something about it. I am glad you think so too. Thanks to Silje for bringing it u initially. I think, there is already much possible with only few changes, the ideas expressed by Diego help a lot. On the

Re: Quantities of arbitrary units in openEHR

that's not a bad idea, but that requires a change to the reference model, since DV_QUANTITY.units is currently a String. I sometimes wonder if we need to allow for some sort of automatic conversions in cases like this, i.e. where the 'code' is self-defining - as we already accept via the

Re: AW: AW: Quantities of arbitrary units in openEHR

yes I agree with this. We should do something about it. - thomas On 26/01/2018 13:23, Bert Verhees wrote: On 26-01-18 08:53, Sebastian Garde wrote: This is where I think that not only it is stated that openEHR uses UCUM (and not some part or “inspiration” of it), but also implies that the

openEHR REST APIs - Release 0.9.0 / invitation for comments

The REST API Team (Bostjan Lah, Erik Sundvall, Sebastian Iancu, Heath Frankel, Pablo Pazos, and others on the SEC and elsewhere) have made a 0.9.0 Release of the ITS (Implementation Technology Specifications) component, in