Quoting Grahame Grieve <grahame@kestral.com.au>:
> No. A good standard should ensure that all implementations that satisfy it
are
> mutually interoperable (see, for example, the Whitworth stanard for nuts
and
> bolts!).
should it? I'm not so sure that this is the correct definition of a good
standard.
While I certainly see it's appeal, it seems to me that there's a tension
between
interoperable and flexible, and the business managers - the people that
actually
spend money on systems - do not wish to have systems that are fully locked
down.
In this sense, standards that lock things down are not what is desired, and
the
standards need to search for a happy medium.
If compliance to a standard does not guarantee interoperabilty with everything
alse that complies to the standard, then what exactly is being standardised?
> This requires that:
> 1. the standard include the the tests that supposdly conformant
implementation
> must pass;
> 2. that test be necessary and sufficent to guarantee compliance; and
> 3. Proven compliance to the standard be necessary and sufficient to
guarantee
> interoperability.
Out of idle interest, would you care to nominate an IT interoperability
standard
that actually meets your criteria?
That's not an idle question. Merely asking it reveals serious problems that have
plagued the IT industry for over half a century, re programming languages,
operating systems, comms protocols, office applications, databases, etc. etc.
These problems arise mainly through the industry's failure to address these
three criteria, which necessarily introduce concepts of formal definition and
proof that have been beyond the capability, and even comprehension, of most IT
systems suppliers and their customers.
> One way to do this is to for the standard to overdetermine implementation
to
> such an extent that exactly one implementation satisfy it. This is how 'de
> facto standards' work.
I don't agree with that either. In fact, if only one implementation can
satisfy
it, it's not an interoperability standard.
On the contrary. A standard that's defined by an implementation guarantees
interoperability among the users of that implementation. That's how MS won its
market share.
As for Barry Smith. Ho hum. I wish such HL7 naysayers would actually move
things along, and contribute to the overall picture, instead of whining
about such trivia as version management. Of course the problem he describes
is painful, but this problem is not new, nor specific to HL7.
Other HL7 naysayers have gone and done something useful at least; that's why
we're on this list. (though, strictly, the doing something useful came first.
That's why I've stopped bothering to read Barry Smith)
> But I was of the impression that that was not the intention of the
international
> health care community.
in as much as such a diverse group can be said to have an intention, it
wanders
somewhere between cheap, flexible, and interoperable. But you can only have
two
of those three.
Can you demonstrate that these three properties are necessarily mutually
incompatible? And, if it is indeed so, which of them would you advocate
prioritising in the domain of healthcare?