I see a kind of cooperation emerging here, which is fine and what I like
most.
Eric points at one are that has my particular interest since I started to
represent such assessment scales in HL7 v3 space in 2002. We where using the
existing HL7 R1 datatypes then and found that for the calculation of the
sumscore the INT could do all counting, but, the specification of each single
score needed to be done with a CO that at that time did not "allow" for the
calculation. It dit allow Eric's example for Barthel to be expressed.
[ { 0 , "unable"},
{ 5, "needs help (verbal, physical, carrying aid" },
{10, "independent"}]
However, the CO in science is a number and in statistics it is used
differently, namely it has an order, a code and can be calculated upon.
(Although
of course there is discussion again on the yes and no's of calculating
averages, there is no science without debate, but that is for me out of scope
for
what I am asked to discuss).
Eric is very right that we do need more than just data types. We need
vocabulary, we need units, we need relationships and we need the clinical
knowledge around it, and proof that the persons doing the work can be trusted.
How I see it from a clinical point of view with in mind the many reuses of
clinical data is the following:
bottom line are the atoms of data elements.
This is the minimum level of information that can bring semantics.
the number 38 does not say anything. However, if we define the data type as
being a PQ, more or less equivalent with interval / ratio in statistics),
it becomes more understandable. but we need a unit to go with it, e.g. UCUM
that can specify 38 degrees Celcius. The moment we want to refer to this
number as a value of body temperature, we can assign a code from any kind of
terminology, classification, vocabulary, codings system.
This is universal between UML, XML, CEN, ISO, (13606 in particular) HL7v2,
HL7 CDA, HL7 V3, OpenEHR
Example: http://icnp.clinicaltemplates.org/icnp/10003507/?t= Body
Temperature description: Temperature: Internal body heat related to body
metabolism.
type: focus code: 10003507
Hence the atomic node does need some particles, like a name, a unique code,
a value, a datatype for the value.
Barthels differs in three ways from this basic principle of one data
element.
1. it has more than one data element, related to each other, making it a
molecular "thing" which essentially is an artifact of something seen in the
real world, but with hundreds of scientific studies supporting that the
validity and reliability of this instrument is good for individual use (changes
in
time) and pupulation use (outcome measure).
2. each data element has a set of allowed values. This set must be
enumerated, and the code assigned to each value. In fact this creates a mini
vocabulary. In the ISO 21090, ISO 13972 and HL7 space, we can use OIDs (unique
object identifier) to mark such a vocabulary.
Barthel data elements have different value sets, hence creating roughly one
vocab per data element.
This is universal between UML, XML, CEN, ISO, (13606 in particular) HL7v2,
HL7 CDA, HL7 V3, OpenEHR
3. such assessments / score systems / scales, allow for computations based
on the individual scores.
The computations can be simple count up, a but difficult like the
calculation for the body mass index, or complex following decision rules.
As long as we stay on these levels, I see no differences in the standards.
Hence, the detailed clinical models, that basically use these patterns.
If we add clinical / scientific knowledge on what is the purpose of the
data elements (collection), literature, method to get reliable data in the EHR
and out of the EHR (clinically speaking), references and
If we add meta information on who created this specification, we deal with
the detailed clinical modelling as it is intended and proven feasible to be
used in HL7 space and in archetype space.
See: Bridging the HL7 template - 13606 archetype gap with detailed
clinical models.Goossen WT, Goossen-Baremans A.Stud Health Technol Inform.
2010;160(Pt 2):932-6. (Medinfo 2010 paper).
There might be ten to hundred thousand of clinical relevant elements that
we need to standardize. But how do you eat the elephant? OK.
We (us and others, so the health informatics community with interest in
this space) are currently working on a set of about 3000 - 5000 that are
clinically, research, quality relevant. They are in different spaces. How many
archetypes in the CKM would be ready for use at the moment? validated by
clinicians and in practice?
Intermountain has about 3000 clinically driven, decision support, exchange,
system etc.
Korea has about 500
NHS has about 300??
Netherlands has about 250 Use cases for this work have only been clinically
driven, based on about a 10 clinical domains, and research driven.
OpenEHR has about XXXX
If we break these down to the core, we do see some differences in coding,
in datatyping, etc. However, this is the level we talk about and it is indeed
beyond the datatype.
The only hope I have is in cooperation and sharing and not blocking such
work with copyright matters.
And, the hope that from this fine grained level of dcm creation we can move
up into the larger modeling efforts e.g. in OpenEHR to represent an entry,
in HL7 to represent a clinical statement and in UML to represent a small
logical model in a larger architectural picture.
William
In a message dated 8-11-2010 4:05:33 W. Europe Standard Time,
eric.browne at montagesystems.com.au writes:
> This leads on to one of William Goosen's favourite topics - that of Coded
> Ordinals. These have been introduced in ISO 21090 to meet the needs, often
> encountered in patient assessment forms, whereby weights are given to
> descriptive phrases to indicate the scope of functionality a patient has to
> perform, say, activities of daily living (e.g. Barthel Index). The weights
> can be used to derive an accumulated score for a collection of individual
> activities. Unfortunately, ISO 21090 can't actually provide for this use
> case via the CO ( that's code for Coded Ordinal ) datatype, because it has no
> way of denoting the set of allowed values. Such a set might look like
>
> [ { 0 , "unable"}, { 5, "needs help (verbal, physical, carrying aid" },
> {10, "independent"}]
>
> i.e. a set of pairs of weights and phrases. A coded ordinal only describes
> one value, not the set of permissable values! Now, of course it would be
> possible to specify these sorts of sets, and to publish them for use in
> clinical systems and information exchange. My point is that ISO 21090 doesn't
> support such a type and there currently is not a mechanism for this within
> HL7 - the primary standard for communicating clinical information. Even
> after all these years! I'd like to know how William, for one, hopes to solve
> this problem? Perhaps Ed Hammond has a solution in mind?
Met vriendelijke groet,
Results 4 Care b.v.
dr. William TF Goossen
directeur
De Stinse 15
3823 VM Amersfoort
email: wgoossen at results4care.nl
telefoon +31 (0)654614458
fax +31 (0)33 2570169
Kamer van Koophandel nummer: 32133713
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101108/3d0f3f12/attachment.html>
