Re: Quantities of arbitrary units in openEHR

But you can't specify terms in DV_COUNT while DV_ORDINAL.symbol can be used to specify the arbitrary units but not as physical property units of measure, but as a terminology concept / term. On Tue, Jan 30, 2018 at 1:30 PM, Thomas Beale wrote: > > On 30/01/2018 16:24,

Re: Quantities of arbitrary units in openEHR

On 30/01/2018 16:24, Pablo Pazos wrote: Hi Silje, My thinking is for your use case, DV_QUANTITY doesn't apply for arbitrary, since those seem not related with physical properties (mass, length, area, concentration, etc.) As I said, "level of X" makes me think of DV_ORDINAL. or even

Re: Quantities of arbitrary units in openEHR

n...@lists.openehr.org] *On Behalf Of *Pablo Pazos > *Sent:* Monday, January 29, 2018 4:34 PM > *To:* For openEHR technical discussions <openehr-technical@lists. > openehr.org> > *Subject:* Re: Quantities of arbitrary units in openEHR > > > > Hi Silje, > >

Re: Quantities of arbitrary units in openEHR

On 29-01-18 15:22, Thomas Beale wrote: Another idea is to change it to a CODE_PHRASE, with terminology_id = UCUM Yes, I understand the decision, but IO regard it as a quick decision which can cause problems on the longer term. For the record, I object against this decision for the last

Re: Quantities of arbitrary units in openEHR

> > > > *From:* openEHR-technical [mailto:openehr-technical- > boun...@lists.openehr.org] *On Behalf Of *Pablo Pazos > *Sent:* Monday, January 29, 2018 12:37 AM > *To:* For openEHR technical discussions <openehr-technical@lists. > openehr.org> > *Subject:* RE: Quantities of

Re: Quantities of arbitrary units in openEHR

:openehr-technical-boun...@lists.openehr.org>] *On Behalf Of *Diego Boscá *Sent:* Friday, January 26, 2018 10:18 AM *To:* For openEHR technical discussions <openehr-technical@lists.openehr.org <mailto:openehr-technical@lists.openehr.org>>

RE: Quantities of arbitrary units in openEHR

technical discussions <openehr-technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>> Emne: 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 terminolog

Re: Quantities of arbitrary units in openEHR

in the next couple of weeks? J >> >> >> >> Regards, >> >> *Silje* >> >> >> >> *From:* openEHR-technical [mailto:openehr-technical-boun >> c...@lists.openehr.org] *On Behalf Of *Diego Boscá >> *Sent:* Friday, January 26, 2018

RE: Quantities of arbitrary units in openEHR

e can have one > Quantity element with the units Cel, m, kg, ml and [arb'U]? > > > > Regards, > > *Silje* > > > > *Fra:* openEHR-technical [mailto:openehr-technical- > boun...@lists.openehr.org] *På vegne av* Diego Boscá > *Sendt:* fredag 26. januar 2018 09:42 >

RE: Quantities of arbitrary units in openEHR

t; >> >> *From:* openEHR-technical [mailto:openehr-technical-boun >> c...@lists.openehr.org] *On Behalf Of *Sebastian Garde >> *Sent:* Thursday, 25 January 2018 7:33 PM >> *To:* For openEHR technical discussions <openehr-technical@lists.opene >> hr.org> >>

RE: Quantities of arbitrary units in openEHR

ical [mailto:openehr-technical- > boun...@lists.openehr.org] *On Behalf Of *Sebastian Garde > *Sent:* Thursday, 25 January 2018 7:33 PM > *To:* For openEHR technical discussions <openehr-technical@lists. > openehr.org> > *Subject:* AW: Quantities of arbitrary units in op

RE: Quantities of arbitrary units in openEHR

: Thursday, 25 January 2018 7:33 PM To: For openEHR technical discussions <openehr-technical@lists.openehr.org> Subject: AW: Quantities of arbitrary units in openEHR This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing <http

Re: Quantities of arbitrary units in openEHR

On 27-01-18 11:16, Thomas Beale wrote: Bert, I don't disagree philosophically, but practically speaking, no SNOMED service is going to be able to answer requests to do with unit properties, unit conversions, or different forms of rendering, which are all things we need to take care of

Re: Quantities of arbitrary units in openEHR

On 27-01-18 11:10, Bert Verhees wrote: If one wants an UCUM term in the DvQuantity and another wants a SNOMED term, it is both legal and possible. What is preferable, that is not to us to decide while thinking about OpenEhr. But having said this Until now, in practice, people use the

Re: Quantities of arbitrary units in openEHR

Bert, I don't disagree philosophically, but practically speaking, no SNOMED service is going to be able to answer requests to do with unit properties, unit conversions, or different forms of rendering, which are all things we need to take care of properly. I actually think units is one of

Re: Quantities of arbitrary units in openEHR

On 26-01-18 10:00, Thomas Beale wrote: 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

Re: Quantities of arbitrary units in openEHR

Semantic Interoperability is possible only when each. distinct domain: has its own model has its own rules and always orthogonal to other models. A terminology can be equated to a Dictionary. A terminology is never an Encyclopedia of everything. We need a terminology of concepts related to the

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

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: Quantities of arbitrary units in openEHR

openehr-technical@lists.openehr.org <mailto:openehr-technical@lists.openehr.org>> *Subject:* 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

Re: Quantities of arbitrary units in openEHR

al-boun > c...@lists.openehr.org] *On Behalf Of *Diego Boscá > *Sent:* Friday, January 26, 2018 10:18 AM > *To:* For openEHR technical discussions <openehr-technical@lists.opene > hr.org> > *Subject:* Re: Quantities of arbitrary units in openEHR > > > > In my

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

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

discussions <openehr-technical@lists.openehr.org> Subject: 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:

Re: Quantities of arbitrary units in openEHR

dag 26. januar 2018 09:42 > *Til:* For openEHR technical discussions <openehr-technical@lists. > openehr.org> > *Emne:* 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

RE: Quantities of arbitrary units in openEHR

ne: 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 wha

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

m Auftrag von Thomas Beale > Gesendet: Freitag, 26. Januar 2018 09:13 > An: openehr-technical@lists.openehr.org > Betreff: 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 expre

AW: Quantities of arbitrary units in openEHR

it be a "Mass". -Ursprüngliche Nachricht- Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im Auftrag von Thomas Beale Gesendet: Freitag, 26. Januar 2018 09:13 An: openehr-technical@lists.openehr.org Betreff: Re: Quantities of arbitrary units in open

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

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: 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: AW: Quantities of arbitrary units in openEHR

Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im Auftrag von Thomas Beale Gesendet: Donnerstag, 25. Januar 2018 17:34 An: openehr-technical@lists.openehr.org Betreff: Re: AW: Quantities of arbitrary units in openEHR On 25/01/2018 16:28, Bert Verhees wrote

Re: Quantities of arbitrary units in openEHR

technical@lists.openehr.org<mailto:openehr-technical@lists.openehr.org>> Emne: AW: Quantities of arbitrary units in openEHR Hi Silje, I think this may ‘just’ be a modelling tooling issue, openEHR itself supports this ok. Speaking for CKM, if you upload an archetype with this to CKM, it shou

RE: Quantities of arbitrary units in openEHR

ehr-technical@lists.openehr.org> Betreff: Re: Quantities of arbitrary units in openEHR Hi Silje, I don't understand how adding an 'Arbitrary' term to the openEHR terminology helps things. DV_QUANTITY.units is a UCUM String field. Won't the strange units just turn up in the String form y

Re: AW: Quantities of arbitrary units in openEHR

On 25-01-18 17:48, Bert Verhees wrote: A UCUM-service is quite simple, it has a simple API. You can extract it from this testfile which you find here: https://github.com/BertVerhees/ucum/blob/master/convey/ucum/UcumEssenceService_test.go I must add a few small remarks, this github-repository is

Re: AW: Quantities of arbitrary units in openEHR

On 25-01-18 17:34, Thomas Beale wrote: On 25/01/2018 16:28, Bert Verhees wrote: On 25-01-18 11:03, Sebastian Garde wrote: Hi Silje, I think this may ‘just’ be a modelling tooling issue, openEHR itself supports this ok. Speaking for CKM, if you upload an archetype with this to CKM, it

Re: AW: Quantities of arbitrary units in openEHR

On 25/01/2018 16:28, Bert Verhees wrote: On 25-01-18 11:03, Sebastian Garde wrote: Hi Silje, I think this may ‘just’ be a modelling tooling issue, openEHR itself supports this ok. Speaking for CKM, if you upload an archetype with this to CKM, it should validate the UCUM unit correctly

Re: AW: Quantities of arbitrary units in openEHR

On 25-01-18 11:03, Sebastian Garde wrote: Hi Silje, I think this may ‘just’ be a modelling tooling issue, openEHR itself supports this ok. Speaking for CKM, if you upload an archetype with this to CKM, it should validate the UCUM unit correctly for [arb'U]{whatever}. However,

AW: Quantities of arbitrary units in openEHR

://unitsofmeasure.org/ucum.html#para-45 Regards Sebastian Von: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] Im Auftrag von Thomas Beale Gesendet: Donnerstag, 25. Januar 2018 10:25 An: openehr-technical@lists.openehr.org Betreff: Re: Quantities of arbitrary units in openEHR Hi

Re: Quantities of arbitrary units in openEHR

Hi Silje, I don't understand how adding an 'Arbitrary' term to the openEHR terminology helps things. DV_QUANTITY.units is a UCUM String field. Won't the strange units just turn up in the String form you quoted for UCUM arbitrary units in that field? (BTW, to ask for a new terminology term,

Re: Quantities of arbitrary units in openEHR

It would be good if OpenEhr RM would support the UCUM-properties fully in the DvQuantity, then all problems regarding units would be over for the next 20 years, and no maintenance on customer or OpenEHR-foundation side is needed. UCUM is, I think, widely regarded as the most important

Quantities of arbitrary units in openEHR

Hi all, I'm working on representing medication strengths in archetypes at the moment. Most medications are thankfully measured in SI units such as mg/ml or mg/{dose unit}, but others use arbitrary units that are not derived from any other physical dimensional units. Examples of these are