My answer maybe out of scope - forgive me if it makes things more
complicated.
In Odyssee, we do it that way :
In the Lexique, you find the concepts as "Weight", "Patient's size", "mitral
leak surface", "kg", "cm2", "m/s"....
In the semantic network, you find relations such as "Weight" -has unit->
"kg" or "mitral leak surface" -has unit-> "cm2"
Now, when you want to describe something, using a tree, since in odyssee
everything can be described with a tree, the system can instanciate
something like :
Weight
|
------ 70 kg
but if can also be
Weight
|
------- normal
When it is a genuine numerical value (not "normal"), it is ALWAYS
instanciated as two twin tree nodes : one with the numerical value and the
value format as the label, and the other with the unit as the label.
You can guess that, in the Lexique, we have a special term "no unit" for
value with no unit.
----- Original Message -----
From: "Thomas Beale" <[EMAIL PROTECTED]>
To: "OSHCA List" <[EMAIL PROTECTED]>;
"gehr-architecture" <[EMAIL PROTECTED]>
Sent: Monday, September 24, 2001 3:28 AM
Subject: openEHR/GEHR modelling question
>
> Another modelling question, as part of our development of the openEHR
> "convergence model" for EHRs:
>
> In GEHR there is a DATA_VALUE subtype called QUANTITY, which models
> physical quantities. See bottom for abstract semantics.
>
> HL7 has a type called QTY also, with similar semantics.
>
> The question is: do we really need two types, to model discrete and
> continuous quantities? For example, DISCRETE_QUANTITY and
> CONTINUOUS_QUANTITY. Currently, the type of value in QUANTITY is REAL,
> which theoretically accommodates INTEGER, i.e.
> the possible values of discrete measurements, but it hides the true
> nature of discrete v continuous thing being measured; in particular, we
> have to add semantics to the class to allow it to be specified as
> discrete or continuous.
>
> Are there circumstances where discrete quantities could become
> continuous, or is it better to have disjoint types? I am favouring
> disjoint types, since it both discrete and continuous quantitative data
> are extremely common in medicine, and it seems better to model that
> explicitly. In modellig terms, one type will have value:INTEGER, the
> other value:REAL.
>
> As an aside, consider another differentiator in quantities - dimensioned
> v dimensionless. Typically, discrete measurements are also dimensionless
> (in the strict sense of the term); is this always true? I don't believe
> we really want to have more subtyping on the basis of being dimensioned
> or not, however.
>
> Another thought: some discrete quantities may be recorded as REAL
> anyway, typically in E format, if the numbers are so large that the
> precision is larger than 1.
>
> Thoughts?
>
>
> --------------------------------------------------------------------------
---------------
> indexing
> component: "openEHR Reference Object Model"
> description: "[
> Models a quantity with value and optional units. Units
> are represented as a string,
> whose format is based the Unified Code for Units of
> Measure (UCUM) proposal,
> developed by Gunther Schadow and Clement J. McDonald of
> The Regenstrief Institute
> For Health Care, Indianapolis. Published at
> http://aurora.rg.iupui.edu/UCUM.
> ]"
> keywords: "quantity, data"
> requirements:"clin:data-qty-num"
>
> cen_ref: ""
> hl7_ref: "QTY (Quantity)"
>
> author: "Thomas Beale <[EMAIL PROTECTED]>"
> support: "GEHR support <[EMAIL PROTECTED]>"
> copyright: "Copyright (c) 2000 The openEHR Foundation, Australasia"
> licence: "The openEHR Open Source Licence"
>
> -- file: "%M%"
> -- version: "%I%"
> -- last_change: "%E% %U%"
>
> deferred class QUANTITY
>
> inherit
> DATA_VALUE
>
> COMPARABLE
> undefine
> is_equal
> end
>
> feature -- Content
>
> value: REAL is
> -- FIXME: need to accommodate discrete and continuous
> quantities;
> -- do we need two subtypes?
> deferred
> end
>
> precision: INTEGER is
> -- Precision to which the value of the quantity is
> -- expressed, in terms of number of significant figures.
> -- 0 implies no precision.
> deferred
> end
>
> property: STRING is
> -- property being measured, e.g. "pressure", "flow rate"
> deferred
> end
>
> units: STRING is
> -- stringified units, following the HL7 UCUM proposal.
> Examples:
> -- "kg/m^2", "mm[Hg]", "ms^-1", "km/h"
> deferred
> end
>
> feature -- Status
>
> is_dimensionless:BOOLEAN is
> -- True if no units or property
> deferred
> end
>
> feature -- Comparison
>
> infix "<" (other: like Current): BOOLEAN is
> do
> Result := other.value < value
> end
>
> end
>
> --
> ..............................................................
> Deep Thought Informatics Pty Ltd
> Information and Knowledge Systems Engineering
> phone: +61 7 5439 9405
> mailto:[EMAIL PROTECTED]
> Electronic Health Record - http://www.gehr.org/
> Knowledge Methodology - http://www.deepthought.com.au/it/archetypes.html
> Community Informatics -
http://www.deepthought.com.au/ci/rii/Output/mainTOC.html
> ..............................................................
>
