So what does he win?
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
Randolph Neall
<randy.neall at veri
quant.com> To
Sent by: For openEHR technical discussions
openehr-technical <openehr-technical at openehr.org>
-bounces at openehr. cc
org
Subject
Re: More on ISO 21090 complexity
11/19/2010 01:08
PM
Please respond to
For openEHR
technical
discussions
<openehr-technica
l at openehr.org>
Following this debate is for me more interesting than a tennis match, and,
in my opinion, it is advantage-Beale.
Randy Neall
On Fri, Nov 19, 2010 at 5:44 AM, Thomas Beale <
thomas.beale at oceaninformatics.com> wrote:
On 19/11/2010 05:49, Williamtfgoossen at cs.com wrote:
Hi all,
Given this discussion on ISO 21090 I would like to bring forward
the following:
1. Every international standard is and has to be based on political
decisions: all member countries have to be accepting it and hence
will want to get something specific out of it, or block too
difficult parts.
That is the way of standards making, in contrary to what a group of
friends like in OpenEHR foundation can do.? This has nothing to do
with committees working in the implementation space or sitting at a
table. It is how formal democratic voting goes. Not a perfect
system we know, but apparently chosen above totalitarian
approaches.
I do hate to bring this up, but in the entire rest of existence, all
engineering (i.e. all creation of technical artefacts) is done by
'totalitarian' approaches. If you know the person who would travel on a
plane built by 'democracy' rather than engineering, please introduce
us...
This democratic development (inclusive of all parties concerned,
and voting by members) has been and is still the case for ISO
21090.
The same democratic and transparant voting procedure by members is
used in HL7 international (of course the membership is organised
different from ISO).
2. The use cases for ISO 21090 do come from different sources: an
older basic data type standard from ISO, clinical use cases, CEN
standards, in particular the one on archetypes (13606-2), AND HL7
among others. The resulting set is accepted by the ISO membership,
and indeed the HL7 membership, referring to it as datatypes R2 (and
facing an enourmous piece of effort and work to redo a lot of the
models and messages due to the harmonisation). And under the JIC,
also the CDISC organisation deals with this since ISO 21090 is part
of the joint harmonisation work. I think the willingness of the
different JIC partners to step beyond their traditional route and
harmonise this formidable and fundamental work is the most
important achievement in the last 25 years of international
standards work. I would like to compliment Grahame in particular
that he managed to get a useful, albeit say 96% "perfect" standard
out of this.
I don't have a problem with the fact that use cases have been researched,
indeed that is an excellent achievement. I have a problem with the way
the standard has been created on that basis; it tries to do way to much,
incorporating all kinds of special cases that should not be included in
the core generic data types standard. Such use cases can be accommodated
in one or more separate 'packages' that show how to use the core classes
for the specific purpose, and what extra classes are needed to formalise
other data specific to the use case.
3. No standard or specification can be perfect. In particular,
Tom's work might be closer to perfection than the ISO 21090, but
that is hypothetically a matter of a percentage between 96% and
97.5% on a VAS of 0 - 100%. I personally are pragmatic, I need in
Detailed Clinical Models and in HL7 v3 Care Provision message
implementations about 20 - 30% of the ISO 21090, so do not bother
about the rare use cases addressed.
no, no, no... wrong argument William! It is not about being on a sliding
scale of good / better / perfect! This standard is in a different place
altogether, 'designed' according to different permises, specifically that
it should try and cover all known use cases in one standard. It is trying
to do way too much, has numerous formal attributes and natural language
guidelines not applicable to most use cases. It is built according to the
wrong-headed HL7 notion of modelling which is: put everything in at the
top/centre and profile it out later. Firstly this breaks basic rules of
maintainability, encapsulation, etc, secondly, it is going to really
damage the uptake and usefulness of this standard! Just like software and
models based on the HL7v3 RIM, where NO TWO IMPLEMENTATIONS CAN
COMMUNICATE, this will be the same.
4.? Core principle behind the standard is that you create a profile
around it that allows you to implement it in your system, or your
message, or your datawarehouse or whatever. There is usually no way
to have it 100% ready for use. The example from the blog that Tom
talks about, where ISO 21090 is mapped into their own CDISC models
is almost perfect. That is the way to go. Yes it will include
mappings from ISO time format to XML time format. But if that works
well on implementation, at the exchange level you are compliant.
mappings are unavoidable with standards. But having to do this
'profiling' with every HL7 standard is nonsense - having to decide which
attributes I don't need, which ones I can set to 0 or Nil, or False, or
some other special value.... just think about the combinatorial
complexity of all those decisions over an object with 10 data fields! ANd
then multiply that by the number of organisations having to make those
decisions.
5. If you adhere to ISO 21090 / conform to it / there is always the
option to limit your implementation set. E.g. refer to particular
chapters or codes in ISO 21090.
particular chapters, particular classes, particular attributes, but only
in specific circumstances.... the 'profiling' work has to be done all
over the place, so even when the standard is fully accepted, noone except
HL7v3 message people can directly use it! It doesn't even make sense in
its current form for CDA! (And I forgot to mention it is full of CDA
specific stuff which also makes no sense being in a supposedly generic
standard).
6. It looks from Tom's objections that OpenEHR cannot adhere to
data type standard ISO 21090. Is that a problem in the OpenEHR
specifications, or is that a problem on political level: we do want
to invent our own because it is closer to perfection? What I mean
here is: if I create archetypes in OpenEHR spaces (there are about
25 in Dutch available pending other issues to be solved before
releasing). And from this system I need to exchange HL7 v3 messages
in the Dutch national switshboard space, will I be in trouble
because the OpenEHR archetypes cannot handle even the basic ISO
21090 datatypes?
openEHR can handle all of the data types conceptually, that isn't the
problem. The mapping, just like for everyone else with a normal kind of
object model, will be painful because of the irrelevant stuff in ISO
21090, and annoyances like TS.DATE, and numerous other details. But, much
more importantly, which profile should openEHR map to? Some core profile?
A 13606 profile? A CDA profile? A v2 profile? an NHS profile? The Sweden
profile? How many mappings will we need? Remember, archetype designers
don't care about which specific way the archetypes might be deployed - in
messages, on a screen etc, so any attributes specific to those uses won't
make sense. Do we need an 'archetype' profile of 21090?
Please have a look at this specification: openEHR Support Information
Model - the section on 'Assumed types' shows how little openEHR assumes
about underlying basic types. On top of that, it builds a core set of
data types that have no attributes relating to messaging, null flavours,
or obscure use cases. All of that latter is handled in contextually
sensible places. Normal object models created according to normal design
principles always end up like this. ISO 21090 doesn't, because it follows
the HL7 include-everything-then-profile approach.
- thomas
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
