We don't use relational databases in the orthodox way as Grahame does,
but his explanation really shows that CD (and most other 21090 DTs) are
conflations of multiple concepts. The 'core' that I want to dig out is
essentially the semantics we put into openEHR. The modelling methodology
is as follows:
* you have a *core data type *definition, e.g. CD, or DV_CODED_TEXT
or whatever, that provides a computational model of the data type
concept, in this case 'coded text', in its simplest form that
supports expressing an instance of that type. The essential in
this case is the code + code system, and in openEHR, we include
the code term, i.e. the text for that code in the language of the
locale in which the data were created (this allows the data to be
human-readable even when a terminology service is not available).
So far, no context- or environment-related inclusions in the model.
* further *contextless semantics *could be included, especially if
they are very common, e.g. in openEHR we have 'mappings' on
DV_TEXT, inherited into DV_CODED_TEXT. This defines a standard
data structure for connecting 1 or more mapped terms, e.g. ICD
codes, LOINC codes or whatever to the original text or coded text.
o another very common addition in openEHR is that of reference
ranges to the Quantity types; these support the
representation of lab data. It could be argued that this
addition is context-related, and should be dealt with in the
next category below.
* then, any *real world (i.e. clinical) context-related *items, such
as the following list should only be added to the model in
'client' classes, i.e. wrapper classes...
o *nullflavour*: this only relates to situations in which the
data were captured from the outside world in some way. But a
lot of values are not captured at all, they may have been
extracted from a terminology service, generated by a
decision support algorithm, or used in some related
application that has no interest in any data whose null
flavour was non-Void
o *clinical statement structure*: what we call an Entry in
openEHR and CEN, and also in CDA, is a larger structure
within which multiple atomic data points might occur. Within
this structure in openEHR and CEN, you have ELEMENTs holding
the data values, then CLUSTERs, EVENT, HISTORY, ACTIVITY,
INSTRUCTION, etc etc. Each of these may add some contextual
items germane to its semantics, e.g. HISTORY & EVENT contain
observation timing info, ENTRY has protocol and
other_participants, as well as subject (who is the data
about) and information_provider (who wrote it).
o *health event context*: at higher levels, data relating to
the visit, or lab test etc, such as date, time, location,
and participants are typically attached to the top level
structure, e.g. COMPOSITION, or Document in CDA.
* now any *system-related context* is added, also in outer classes:
o version control information
o message control information (HL7 HXIT stuff)
o anything specific to storage or GUI rendering.
If this kind of approach, based on *additive inheritance and
encapsulation*, is not followed, we end up with leaf level data type
definitions that are a soup of items from these other contexts and
levels. This prevents us writing a clear model of what a CD or a
Quantity actually is, and then deploying it in all the different
contexts where it may be used. It also *prevents anyone knowing*, when
such data are passed around *which items represent the data value*, and
which are context-related items from some other context, now of no
interest to the present computing context (e.g. HXIT attributes turning
up inside the EHR). It is not always possible to follow modelling
principles 100% and sometimes compromises seem to make sense. For
example, the Quantity reference range one noted above. However, if the
model does not by and large follow good practices, it won't do what is
needed.
This is the problem of ISO 21090, and as well, the HL7 RIM, and is why
in their current form they are so hard to use, and why they in fact
worsen interoperability: each implementer is forced to *subtract* some
subset of items from the basic classes to suit their purposes, and each
implementer does this differently, resulting in a custom variant of the
model (in HL7v3 this is called an RMIM). Not only that, but no-one can
write a definitive set of classes in the common programming languages
that can be widely used, because each of these implementation sites has
a different variant of the same classes in the model.
Let me make one thing clear: the above is not a matter of taste or
subjectivity. If we agree that we are in fact using object modelling to
express these standards, then we need to stick to good object-oriented
methodology. Not doing so has bad downstream consequences.
Now, doing 21090 properly means doing the above. It is probably too late
to do that. So the official standard will be like the HL7v3 messages -
capturing a huge amount of useful learning and semantics yet modelled in
just such a way as to prevent reusability or interoperability.
However, this is not the situation we are in. I don't know if the
relevant ISO people (including relevant national representatives) can be
alerted and made to understand in time that what they are doing is going
to have more or less the opposite effect to what they think. If it is
possible we should do it. If not, as Grahame says, a few of us could try
to create a 21090-stripped-down. Assuming a technical agreement could be
reached, then we still have the problem as Stef mentioned, of making it
official.
I don't know how to solve this situation. Hence my near total loss of
faith in the international standards process, in e-health for some years
now.
- thomas
On 25/11/2010 01:43, Grahame Grieve wrote:
>> This is really great news.
> I'm glad you think so. Cause the more I think about it, the
> more pessimistic I get.
>
>> important technical agreed standards should still become
>> formal standards because, at least here in Europe, they
>> can be incorporated in laws.
> y. but is that what we have here? How can we have more than
> a systems implementation guide for ISO 21090?
>
> I'll illustrate by talking about our favourite bugbear, CD
>
> For me, CD conflates 3 different notions in it's properties
> (and that's ignoring the things it gets from ANY and HXIT):
> * a definitional concept
> * a context of use of the concept
> * descriptional stuff to help foreigners work with the thing
> when they don't know the definitional concept
>
> In my systems, I split the first 2 up and struggle with the last.
> I'll explain.
>
> The definitional concept itself is code + codeSystem. This
> pairing provides the actual meaning. So the first thing I do
> is normalise this out of CD into a separate table (note, then,
> that my focus here is relational databases, and working with
> them). I keep a table of every discrete concept encountered
> in the system. And I also maintain tables that keep track of
> implies relationships between these concepts. This means
> that I can write fast SQL joins that can use subsumption.
> Again, note the implementation focus I have here. And actually,
> I maintain a separate table for code systems to help with
> system maintenance, so I break code+code system up too,
> and there's a slew of infrastructural things hanging off them.
>
> My CD datatype therefore devolves into originalText + primary
> key for the concept. I ignore the valueset set stuff at the moment,
> on the basis that it's not in my product's requirements space.
>
> The descriptional stuff, I populate from my infrastructure -
> codeSystemVersion and CodeSystemName. DisplayName, that's
> a problem. Because in theory I can (and should) generate that
> from my code system definition tables themselves whenever I need
> it. (well, I don't actually maintain a table for snomed - I have
> a cache structure instead). But there's no algorithmic way to
> turn a snomed expression into a display name. For me, this is
> ok right now, we're not in the snomed expressions space.
> Yet. But soon. I'm kind of hoping that the nascent work in that
> space will start offering something solid about when I need it.
>
> And what are translations? I don't think they are any of those
> other things. I keep track of them as a series of postulates
> that the underlying concepts may be related. (and who
> postulated it, cause I'm never sure who's going to believe who)
>
> So CD is a cascade of tables for me. Cecil Lynch from Ontoreason
> does a different cascade, reflecting his different tooling, architecture,
> and requirements.
>
> OpenEHR doesn't split that stuff out - just compresses what it has
> into a single de-normalised type. I'd never do that. But Gunther, on
> the other hand, would never normalise it - he just uses the fully
> denormalised RIM + data types and wouldn't bother understanding
> why we'd have this discussion at all.
>
> (I do use the fully denormalised type in my object models at my
> exchange points (CDA, HL7 v2, etc), where it makes prefect
> sense, btw)
>
> Anyway, the problem I have is that my tooling, architecture and
> requirements all change the way that I *implement* the notional
> ISO 21090 types inside my system. Out of that, we are supposed
> to be able to write a single specification which is the one correct
> model for implementing these types in a system?
>
> So I don't feel as though we can produce a standard, just an
> implementation guide.
>
> Grahame
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
--
Ocean Informatics *Thomas Beale
Chief Technology Officer, Ocean Informatics
<http://www.oceaninformatics.com/>*
Chair Architectural Review Board, /open/EHR Foundation
<http://www.openehr.org/>
Honorary Research Fellow, University College London
<http://www.chime.ucl.ac.uk/>
Chartered IT Professional Fellow, BCS, British Computer Society
<http://www.bcs.org.uk/>
Health IT blog <http://www.wolandscat.net/>
*
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101125/24a76ad8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101125/24a76ad8/attachment.jpg>
