I would think that we need some examples here. I also think that the
question is in some sense an artifact of "typing" of values in programming
languages. As such, it is likely that the more typing the better. It's
just that clinicians may not think in terms of typing.
I'm not exactly sure what dimensioning means. If it means the ability to
assign a unit to a measurement, it would be helpful to have examples of
quantities that do *not* have units associated with them.
John
At 09:28 PM 9/23/01, you wrote:
>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
>..............................................................
>
