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

rstanding). >>2. openEHR uses (implicitly I think, but it may be hidden somewhere >>in the spec), the case-sensitive version of UCUM – therefore the U needs >> to >>be upper case, see e.g. http://unitsofmeasure.org/ucum.html#para-45 >> >> >

RE: Quantities of arbitrary units in openEHR

e U needs to be >upper case, see e.g. http://unitsofmeasure.org/ucum.html#para-45 > > > > Regards > > Sebastian > > > > *Von:* openEHR-technical [mailto:openehr-technical- > boun...@lists.openehr.org <openehr-technical-boun...@lists.openehr.org>] *Im >

RE: Quantities of arbitrary units in openEHR

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

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

[mailto:openehr-technical-boun...@lists.openehr.org<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<mailto:openehr-technical@lists.openehr.org> Betreff: Re: Quantiti

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

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

Re: Quantities of arbitrary units in openEHR

, 25. Januar 2018 10:25 An: openehr-technical@lists.openehr.org<mailto:openehr-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

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