Representing a Real value in openEHR

I'm not an UCUM expert, but that's what I believe it should be. Anything with curlies seems to be equivalent to 1, so {1}=1. There is some more information under ?29: http://unitsofmeasure.org/ucum.html#section-Derived-Unit-Atoms and there is a UCUM tracker issue: http://unitsofmeasure.org/trac/ti

Representing a Real value in openEHR

True, UCUM is an obscure standard :D 2015-03-17 12:02 GMT+01:00 David Moner : > That's true Daniel, to be completely compliant with UCUM it seems the unit > should be defined as 1 and not as an empty string. > > http://unitsofmeasure.org/ucum.html#section-Examples-for-some-Non-Units. > > 2015-03-1

Representing a Real value in openEHR

That's true Daniel, to be completely compliant with UCUM it seems the unit should be defined as 1 and not as an empty string. http://unitsofmeasure.org/ucum.html#section-Examples-for-some-Non-Units. 2015-03-17 11:55 GMT+01:00 Daniel Karlsson : > Hi, > what about the unit 1 (uno) for dimensionles

Representing a Real value in openEHR

So it would be stored as {1}? (as they are supposed to be UCUM). Empty units doesn't feel like valid UCUM units either. 2015-03-17 11:55 GMT+01:00 Daniel Karlsson : > Hi, > what about the unit 1 (uno) for dimensionless quantities? > http://goldbook.iupac.org/D01742.html > > /Daniel > > > On tis, 2

Representing a Real value in openEHR

Hi, what about the unit 1 (uno) for dimensionless quantities? http://goldbook.iupac.org/D01742.html /Daniel On tis, 2015-03-17 at 11:43 +0100, Diego Bosc? wrote: > Qualified Real is a property from the domain type, not the type > itself, I thought the idea was to get rid of domain types in the >

Representing a Real value in openEHR

Qualified Real is a property from the domain type, not the type itself, I thought the idea was to get rid of domain types in the future. 2015-03-17 11:23 GMT+01:00 Ian McNicoll : > Hi David, > > Qualified Real is the current preferred option (for me anyway). I think we > have flagged up in the spe

Representing a Real value in openEHR

Well, as the openEHR data types specification document says, think of an archetype representing some statistical values such a covariance. It is clear that the DV_QUANTITY is the most appropriate solution right now, but does not seem safe to rely on setting an empty unit to represent just a Real n

Representing a Real value in openEHR

Hello, It might seem a very basic question, but I couldn't find an appropriate answer anywhere. Which is the best way to model a single Real number in openEHR? For example, a result of a score. I have found two possible options: - Use a DV_QUANTITY, with the "Qualified Real" property, that sets

Representing a Real value in openEHR

On 17/03/2015 10:55, Daniel Karlsson wrote: > Hi, > what about the unit 1 (uno) for dimensionless quantities? > http://goldbook.iupac.org/D01742.html > > /Daniel this view is interesting - what they consider to be the dimensionless quantities.

Representing a Real value in openEHR

On 17/03/2015 10:39, David Moner wrote: > Well, as the openEHR data types specification document says, think of > an archetype representing some statistical values such a covariance. > It is clear that the DV_QUANTITY is the most appropriate solution > right now, but does not seem safe to rely on

Representing a Real value in openEHR

Hi David, until we discovered that a few scores use non Integral values, there was no need for a 'real' type with no units. There is a CR to enable DV_ORDINAL to have real values. Until then, I would suggest using the DV_QUANTITY approach, that's the most frequently used one in the past. Othe

Representing a Real value in openEHR

Hi David, Qualified Real is the current preferred option (for me anyway). I think we have flagged up in the spec CRs that proper support for Real would be helpful as Qualified real is somewhat obscure. So - agree with your request. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)