I appreciate all of the remarks that have been make thus far. I am
responding because I think we might have some shot at being better. I
think many of you tak pot-shots at HL7, and that's OK. An elephant is
easier to hit than an ant. In the early years, HL7 had only a few members
who were very focused on what we wanted to do. Most were vendors and
providers. We create standards that were simple and did precisely what we
wanted. As HL7 grew, so did the complexity. David makes the comment about
defence of one's lifes work. That is multiplied in spades in HL7. Not
only from companies but now increasingly from countries. Hoe can a
standard be global unless it addresses global issues. As a result
complexity and compromise. The world is political; life is political. We
exist in a competitive environmment. We just finished a frustrating
political election in the U.S., Most the the political adds told be how
basd the oposition was, rather than telling me what they can do for me.
Governmnets make decision. Governments fund efforts. To ignore
governments would be foolish. Every country has an official government
body that is responsible for standards - ANSI, BSI, DEN, AFNOR, others.
Complexity causes collapse. Organizations and societies grow in complexity
until they finally collapse.
IN my opinion, many of the criticisms of HL7 are simple disagreements, not
right or wrongs. What group doesn't have acronyms - it's part of today's
society - military, government, healthcare - you name it.
I would like to see a process in which we fully and completely define the
requirements for the standards we need. We debate, discuss and compromise.
A small group of technical expeerts create the standard and then everyone
evaluates if the requirements are met. HL7 has established a huge presence
in the world. It would seem to me to be foolish to ignore HL7 when
creating a datatype standard. As long as you have your standard and I have
my standard, we have no standard.
I think it is important to examine our motivations - what drives us in our
work with standards. Is it a life-time work, or is it simple a detail that
must be accomplished before we can do what we really want to do. Is our
work with standards our claim to fame. There are times when I think HL7
has so many groups because we want a tribe of chiefs. Even that is driven
by real requirements - my boss won't pay for my participation unless I have
a titled job.
You claim that ISO is flawed. Ballot is by standard, a only a few
countries dominate. That obviously is not restricted to standards. Again,
that's life.But what is a better solution? Shall we live with a decision
making prosess in which a relative few people decide what is correct?
While I like that approach, if I am a decsion making, I don't like that
approach if I'm not.
How to we change? What is the solution? HL& has honestly tried to find
solutions. We recognize flaws and problems and try to solve them. I have
issues with archetypes as storage components, I have issues with content
and structure. I have the same issues with DCM. I don't like components
and folders. Wjy? Debates seem not to solve the problem for many reasons.
Can we create an open society that leaves some of the history and biases
behind and find the best possible solution? Can we bring together the SDO
organizations. I also have a problem that openEHR refuses to be an SDO.
Perhaps because they have no rules to follow - while HL7 is bound by ANSI
and ISO rules.
By the way CEN also votes on the data types.
I would like to see some real proposals to try to provide simpler, workable
global solutions. It's like World Peace - a great idea but probably not
achievable.
W. Ed Hammond, Ph.D.
Director, Duke Center for Health Informatics
David
<dneilsen at bigpond
.net.au> To
Sent by: For openEHR technical discussions
openehr-technical <openehr-technical at openehr.org>
-bounces at openehr. cc
org
Subject
Re: ISO 21090 data types too
11/07/2010 10:48 complex?
PM
Please respond to
For openEHR
technical
discussions
<openehr-technica
l at openehr.org>
HL7, ISO and CEN standards all bear the hallmarks of design by committee -
-? compromise which in my opinion is the result of allowing for legacy
systems and attempting to be everything for everyone
-? compromise leads to complexity
-? complexity results in misunderstandings (trying to work through the HL7
acronym alphabet soup) and sanctioned non-conformance (if you can just
"profile it out" how can it be a standard)
-? the biggest players have the vast majority of resources that can be
applied to development and committee work which results in an unbalanced
outcome (market forces).
The vehemence with which some have replied to Thomas' initial comments
might be indicative of attachments to and defence of ones life work. This
is understandable but also tends to get in the way of learning, innovation
and progress.
There is no way around implementing standards without spending copious
amounts of money. Certainly more than what could be achieved without
implementing standards. Compromise because of legacy systems saves money
(read competitive advantage) but won't achieve universal implementation of
standards. Not everybody has a vested interest in the same legacy system.
Complexity is never helpful and leads to true non-conformance.
Some have said that market forces should determine the outcomes of
standards development. I think that standards, per se, are anti-competitive
in that their use reduces differences that can be marketed as "new and
improved". Perhaps irrelevantly (or is that irreverently) market forces led
to ENRON and the GFC.
I think it's unfortunate that an idea as simple and robust as openEHR can't
make any headway because of market forces. Politics plays too big a role in
global standards development. Also unfortunately I can't see that changing.
I'll shut up now and leave you all in peace
regards
David Neilsen
On 8/11/2010 12:07 AM, Dra Carola Hullin Lucay Cossio wrote:
I? second that!!
Carol
Dra Carola Hullin Lucay Cossio
Presidente of IMIA-LAC
PhD Health Informatics
www.imia-lac.net
+5628979701 Chile
From: stef at vivici.nl
Subject: Re: ISO 21090 data types too complex?
Date: Sun, 7 Nov 2010 14:53:04 +0100
To: openehr-technical at openehr.org
It looks like we're getting to the heart of the matter here.....
What I really ?would like to know from the others what their
opinion's on these subjects are?
If it indeed turns out to be true that Tom don't understand how
datatypes, RIM or data types are working, we, as the openEHR
community, should ask him to shut up. If not we should find better
ways to get the message across...
Cheers,
Stef
Op 7 nov 2010, om 12:12 heeft Grahame Grieve het volgende geschreven:
hi Tom
.....
The context specific stuff is specific to HL7 only. It
just doesn't apply elsewhere.
not at all. And I'm surprised you still think this. HXIT is to
do with capturing
and managing foreign data. As is some of the II stuff. It
doesn't and won't
arise in an EHR system for internal data, but it will for
imported data. So
where it does arise is not HL7 specific.
Flavors are a ISO 21090 thing. And optional - they aren't in
the schema,
for instance.
Update mode is transactional. Almost everybody will profile it
out.
......
There is not a close correspondence between the 21090
idea of
?ANY? and the typical Any/Object or other root class of
most
object-oriented type systems ? this name clash would have
to be resolved in some way;
It appears I will have to keep repeating this until I am blue
in the face.
It is not a name clash, nor does it (or should it) correspond
to a root class
in any other system - it is it's own class. The fact you think
this indicates
that you are totally confused as to what ISO 21090 is. (Hint:
look at how you
modeled your own data types...)
.......
The modelling style seems to follow the strange HL7
obsession
with non-object orientation, popularised in the RIM.
which indicates that you don't understand the RIM or the data
types,
and how they differ.
Grahame
_______________________________________________
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
_______________________________________________
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
