In the Web services hype there is a tendency to try and reinvent the
wheel. We have a messaging specification that supports Orders and
results and medications with atomic data. It is responsible for the
majority of Data transmission that occurs today - and it occurs
millions of times a day now and seems to work. That is of course HL7
V2, and we already have international and local standards that are
published and actually available for free. HL7 is not a document
structure it is a full blown messaging specification that has survived
20 years... and will continue to survive because it works. If you want
XML documents, no problem, HL7 V2 has well defined XML encoding specs.
All we lack is the transport layer to move this around and the
terminology and standards on how to use the terminology to achieve
more semantic interoperability.
Andrew, if I can make an observation about HL7 as an outsider
to health informatics, but as someone who has seen standards
work in more technical areas - I'm interested in the lack of
'definitiveness' about hl7, which to me seems at odds with
successfully using it as a message standard in completely
distributed environments i.e. between a GP and a path lab
that have never talked to each other before..
I can recount a tale of a recent software development - when
a path lab was asked for an electronic feed of hl7 results, its
reply was "how do you want the HL7 done", to which the
reply was "the standard way", at which point they laughed
hysterically.. is this the wonderful 20 year old message
specification that we are banking on - one where a three
week negotiation period is needed between two vendors
in order to align their "standards". Where interoperability
demos need to be planned 3 months in advance so that
the systems can actually handle the data of either side.
Technical standards work because the _goal_ is to
remove ambiguity - so whilst they aren't always perfect,
the end game is to have a standard where all parties
know that this bit goes in that spot.. but I don't need to
have a week long interoperability chat before my
RFC822 emails can be parsed..
HL7 seems not to have that as a goal - I don't know
if that's because medical
data modelling is inherently complex (which I believe
it is) or whether it's just not even seen as a goal given that
its mainly used between large hospital systems etc where
there is always that time to have an interoperability
discussion. I have seen various sites describe HL7
as a "framework for negotiation" - if we want to avoid
centralised infrastructure in australian health messaging
(where the central server can 'fix' things up for us)
surely we need a standard that definitively tells us
how things are done, not 'heres a starting point
for negotiation'.
Obviously as a company that has invested heavily
in HL7v2, you guys are keen to push Hl7 (as is
your right). I don't want to put you in the position of
having to defend the whole of HL7 by yourself, but I
was wondering if you had any thoughts on this
issue and whether you think its a problem, or whether
I've completely misunderstood HL7 as a standard??
Andrew
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
