Tom Bowden wrote:
>
>
> Dear Colleagues,
>
> At HealthLink we have been watching the discussion on messaging
> responsibilities with great interest. It was timely that David More
> provided an excellent link to a video on use of messaging etc in the
> Dutch health system. The key point we think should be noted is that you
> cannot get to this level of automation without all involved having
> complete trust in the system, especially trust in the fact that it is
> safe and 100% reliable
>
> As readers are probably aware, HealthLink is a messaging and security
> system provider active in Australia, New Zealand and Canada and
> therefore we have a number of environments upon which to draw upon for
> examples and comparisons.
>
Thanks Tom,
I printed out your document and left it on my Desk overnight, but there
is now Tojan Horse Poo all over my desk.....
I am all for application acks, and correct ones at that, but this would
achieved if PMS applications were AHML accredited and a standard
interface to the PMS was adopted. Your proposal turns standards based
interoperability into interoperability based on contracts. Surely this
would lead to kickbacks where the messaging provider pays the PMS
provider for the (?exclusive) ability to interface with it. Please
assure everyone that this is not part of your plan! "Plug and Pay" is
perhaps the best term.
This may well be Healthlink's Business model and the PMS vendors might
appreciate another income stream but It would be at the expense of the
users, as someone has to pay for that access. We have already seen
pathology companies forced to pay PMS providers for the privilege of
getting non standards based electronic orders and this proposal adds a
new toll both in the other direction.
You need to reread the HL7 standard as your interpretation of it is
incorrect. "Pathology Messages" as you describe them, are in fact for
any clinical data, this is directly lifted from Chapter seven (ORU Messages)
"These transaction sets permit the transmission of any kind of clinical
observations including (but not limited to)
clinical laboratory results, the results of imaging studies (excluding
the image), EKG pulmonary function studies,
measures of patient status and condition, vital signs, intake and
output, severity and/or frequency of symptoms, drug
allergies, problem lists, diagnostic lists, physician and nursing
history, physicals, progress notes, operative notes and
so on. These transaction sets carry information that is reported as
text, numeric or categorical values"
On the question of the correct use of ACKS: This is from chapter 2
"The HL7 Standard makes no functional interpretation of the requirement
that a system commit the data in a
message to its database before acknowledging it. All that is required is
that the receiving system accept responsibility
for the data, providing the same integrity test that it would apply to
data from any source. To
continue the prior example, the ancillary system may acknowledge the
order after placing it in an input
queue, expecting to fully process the order into its database at a
future time. The only assumption is that
the input queue is maintained at the same level of integrity as the
database."
Now I support application ACKs, but deleting the input queue before
committing it to the database is quite poor practice, Only a small
number of applications generate ACKs and many do not yet support HL7 at
all.
Healthlink also uses Non-Standard "RSD" messages for clinical data.
Thats not a message type I can find in the HL7 Manual?
We have tested the available REF messages in The Hunter trial and found
that while 2 PMS's could import them, they were not brought to the
attention of the target doctor, and were not felt safe to use because of
this.
wrt The discussions at the HL7 Meeting next week I would suggest:
1. A common interface for PMS data import be created which allows
for application ACKs to be reliably checked. This could be eg:
1. Directory Based
or
2. A SOAP interface into the PMS
2. A commitment made by PMS vendors to achieve AHML accreditation
for created messages within 12 months.
3. A test set of Compliant messages be developed that test
(and stress) the import capabilities of PMS systems. Ideally
this testing should be done by a third party eg: AHML
4. A common SOAP interface be developed for encrypted HL7 data transfer
so that PMS vendors can implement their own interfaces and
message transport in the future.
5. A common SOAP/HL7 interface be developed for Provider lookup and PKI
key management to allow for 4. to be implemented
6. A commitment by messaging providers to implement 4. and 5. within
12 months and publish a per/kb fee for message delivery to allow
for open competition based on standards.
This would open the market and make interoperability a technical issue
rather than a contractual one. Compliance with existing standards would
do more to improve patient safety than a bonus load of contracts ever would.
The long term aim is to be able to turn up at a connectathon and
inter-operate with multiple vendors without having to speak to their CEO
to negotiate terms first.
This level of interoperability is not easily possible at the moment
because of compliance issues rather than a lack of signed contracts.
Medical-Objects has participated at both HIC Connectathons in Australia
and made it happen, Argus has participated in the first, I note
Healthlink did not deliver any messages in either event, despite showing
just enough interest to get your logo in place for both.
Andrew McIntyre
Medical-Objects.
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
