Andrew,

I think its time we called a halt to the polemics, or we'll get
ourselves biffed off this list.  BTW For the record, HealthLink does
have AHML accreditation for our AS4700.2 - HL7 v2.3 (lab messaging)
validation system and we are currently upgrading that accreditation to
accommodate changes to the lab standard with the move to HL7 v2.4.  We
are also working with them on the REF messaging. It needs to be
understood that we do not create messages, we just check them for
structure. So can we let that whole argument drop for now please??

I have given some thought as to how we might debate what I still think
is quite a serious issue in a more dignified manner.  I am starting the
ball rolling by outlining the issue a bit more objectively.  Please do
feel free to modify what I have written below if you believe it is
factually incorrect or incomplete or if you'd like to add anything.


We have two messaging models in play, 

Model 1.  Messages are created to a defined
specification/standard/implementation by the originating practice
management system.  They are then sent by a messaging system that (prior
to signing and sending them), checks them (for structural conformance
only) against the published standard. Messages are not changed by the
intermediate system.  The  proponent of this system argues that the task
of ensuring that the message structure is correct and complete belongs
to the originating system and that most of the originating systems are
now capable of sending appropriately structured messages and thus are
capable of being used for this purpose.

Model 2.  The second option includes a messaging system that
incorporates an interface engine capable of transforming messages.   The
proponent argues that end point systems are not capable of sending or
receiving standardised messages and therefore a message transformation
service is needed in the middle.  Due to perceived deficiencies in the
end-point-systems the original messages are transformed by the
intermediate system to remedy the perceived deficiencies.

Andrew, is this a satisfactory representation of the facts?

Kind regards,

Tom Bowden





  Tom Bowden <mailto:[EMAIL PROTECTED]> 
Chief Executive
Tel: +64 9 638 0670
Mobile: +64 21 874 154
Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 
Web: www.healthlink.net <http://www.healthlink.net/> 

 <http://www.healthlink.net/> 
Connecting The Health Sector 
 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrew McIntyre
Sent: Tuesday, 8 May 2007 2:08 p.m.
To: General Practice Computing Group Talk
Subject: Re: [GPCG_TALK] Making Messaging Work

Tom Bowden wrote:


> 
>>>>>>> And there is an increasing volume of real, standards adherent
> messaging getting done in every state. There is nothing that should 
> hold you up, although I'd urge putting in sufficient effort to do it 
> properly.

You must mean Medical-Objects messaging then Tom as thats the only
standards compliant messaging that is out there. The errors in the
current crop of REF messages are so serious that they are quite unsafe.
The RTF/Free Text is not escaped and provider numbers are in wrong
fields etc etc.


>>>>>>>  I think we have to agree to disagree here Chris.  To really do
> scaleable messaging, crystal clear demarcation is really important, 
> besides, as our table now shows, there is really no need to pursue 
> work-arounds.
> 
> 3. We don't live in perfect world and have to get on with it.
> 
>>>>>>  Yes , but not at the risk of harming patients by taking needless
> shortcuts.

The ability to do Digital signatures and have interface engine
functionality are added features. It seems strange that you are proud of
a lack of features. I think if people are really honest then all
interoperability requires some fiddling at the margins to really work.
This is especially so with the lack of ahml compliance. This is the real
world experience rather than the "Ivory tour" propaganda.

> 
> 4. This country needs standardisation and is well behind.
> 
>>>>>>>> I agree with you and I am proud that we are in the forefront of
> getting standardisation happening.  Again, take a look at the matrix 
> in the URL above.  We have as you know, been working diligently on 
> that for years. And we are getting there. What we now really need is 
> to have influential user groups such as Divisions at the forefront 
> demanding both stringent format standardisation and high quality
standards...

Well you have been talking a lot but there is a long way to go and you
are not carrying standards compliant messages at the moment, but
Medical-Objects is. There are a lot of errors in the current messages
and while we attempt to get these fixed at the source the large PMS
vendors are not very good at fixing errors of listening to external
parties comments or reading standards. We are happy to help them but
they have to be willing to listen. We have had AHML compliance for 2
years.


> While I think it is now about time that we knocked this debate on the 
> head for now, I have to say that I have yet to read one convincing 
> argument against maintaining a standards-based messaging system that 
> is free of short-cuts and work-around.
> 

I agree, just as you would not deliver messages in the HIC
interoperability demo unless they were AHML compliant (and in the end
you did not deliver any), you should not deliver any messages until
everyone else has AHML compliance as I can assure you that your message
checking is deficient and the ones you transport now are not
interoperable and are unsafe.

Once we have perfect AHML compliant messages then we can use the simple
healthlink transport safely.


By the way Medical-Objects now supports Application ACKs and provides
ACKs for Transport, File consumption, Application Acks and have support
for View ACKs already.

Andrew McIntyre
Medical-Objects
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk

Reply via email to