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