Opinion: Secure messaging interoperability is more than a slogan

The work of the secure messaging vendors on the FHIR-based proof of concept trials is to be congratulated and is a key step in improving existing interoperability for delivery of point to point electronic communication.

As every GP knows, millions of secure messages such as discharge summaries and test results are being successfully exchanged daily, using the services of a small number of secure messaging vendors and direct sending of orders and results between some pathology providers to their referrers.

The issue with current messaging systems is not that secure communication is unobtainable, difficult to implement, costly and insecure. The FHIR initiative enables messaging vendors to network their services in the same way as phone companies or banks so that messages sent via one can be delivered by another. Not all customers are signed up to the same service.

So far so good. However, there are are a few major hurdles to be jumped. A collaborative effort to achieve networking by messaging vendors some eight years ago was run in a process facilitated by IHE Australia, HL7 Australia and the MSIA.

The technical issue of how to connect vendors was rapidly achieved (before FHIR existed) however goodwill to collaborate fell over when commercial issues in the free market of competitive messaging vendors surfaced. Identifying and addressing these business issues will be essential for success this time.

Firstly, who is going to pay who for the delivery of messages originally sent by another messaging service, and will this grow or shrink the size of the market and business?

The second barrier to successful cross-transfer of messages is that the messages sent by almost all health services do not comply with Australian messaging or vocabulary standards.

Likewise the major clinical system vendors are not capable of processing a standard HL7 message, if one were to be delivered to them. Senders and receivers have each interpreted the international HL7 messaging standard independently of the agreed Australian standard and associated implementation guidelines.

There were at one time over 15 variants of the HL7 pathology result message being sent daily. Currently this barrier is overcome by messaging services keeping a close track of the formats sent and accepted by their customers' IT systems and "fixing" the message format "on the wire" as it passes through their messaging hubs.

This is less than ideal as we don't expect the post office to open, read and fix grammatical errors on letters as they past through the system. Computers being basically "stupid" (unless endowed with complex machine learning) means that where such errors are not fixed the receiving system can not read the message. GPs could not receive reports electronically.

This service of fixing messages and ensuring end to end quality of service is one of the key functions of messaging vendors that can easily be overlooked by simplistic processes to achieve interoperability.

One of the unanticipated outcomes of the Secure Message Delivery (SMD) standard developed by NEHTA (now ADHA) is that enhanced encryption of messages means that messaging services can not open the message in order to customise it to be acceptable to clinical software like Best Practice, Medical Director, Zedmed and the others.

If SMD were mandated and implemented tomorrow, messaging as we know it would just stop happening.

This issue of conformance with standards has been known for over 20 years, but while a workable solution to fixing messages has been available, there has been no real incentive for labs or GP vendors to address the message standards compliance problem. From their perspective, why spend money and effort fixing something that is "working" and flexible for end users, and which is part of the messaging service they pay for?

No authority has been prepared to mandate or regulate that standard messages are used. No funder has been prepared to throw sufficient financial rewards at health services or vendors to get them to implement the standards.

Time will tell if ADHA paying health IT vendors $30,000 to implement SMD is enough. Private pathology providers have proven to be resolutely resistant to implementation of standard pathology messaging and vocabularies.

Effective messaging depends on the content of the message (the "payload") just as much as getting the transport "messaging" format correct. In addition to paying GP system vendors to implement the SMD standard, it is necessary to implement and test the Australian standard HL7 message 4700.2 for lab, radiology and referral messaging.

International efforts in implementation of standards and systems have found that collaboration and testing events called connectathons help with troubleshooting and testing of implementations. IHE Connectathons are a key part of creating system-wide interoperability and trying to tackle interoperability without provable implementation of standards is sure to fail.

If this makes sense to the readers of Pulse+IT, then it should becoming increasing clear that achieving interoperability is not as simple as "changing to SMD", "adopting secure messaging", "opt in or opt out" – it is a complex socio-technical undertaking.

Fixing all of this is not just a task for ADHA; it needs all of us.

Peter MacIsaac is a GP and health informatician who has been involved with development and implementation of standards for interoperability for over 20 years. He is secretary of the Australian committee of Integrating the Healthcare Enterprise - IHE (Australia).

Posted in Australian eHealth

Tags: secure messaging

Comments  

# Oliver Frank 2019-03-29 08:45
Interoperabilit y is only one of four problems that need to be solved before GPs and other health professionals adopt secure messaging as their default and preferred means of clinical communication.

The other three problems are:

1. It is not known whether referrals that have been generated electronically (in clinical software) without the use of an individual digital certificate and sent via a secure messaging provider are valid for Medicare benefits purposes. Four months of correspondence with Medicare has not led to an answer to this question.

2. Many or most clinical images sent via secure messaging become too large after encryption to be able to be received successfully. GPs and others need to be able to send images of ECGs, clinical photographs and other complex images.

3. Clinical software used by GPs and others does not alert the user as soon as it known from a ‘failed’ ACK from the secure messaging provider that a message could not be delivered. This exposes patient to possible adverse outcomes and senders to legal claims for those adverse outcomes.
# Paul Campbell 2019-03-29 09:28
Thank you Peter MacI for a clear description of the obstacles to the comprehensive implementation across the mixed bag of systems and business targets. As you point out, it has been solved by the mobile phone companies. Regards, Paul Campbell
# Peter Adkins 2019-03-29 11:02
Thanks Peter for your summary on the state of play. Seems like life is just one huge “Z” segment!
There is tremendous potential for the way we communicate in health care which is constrained by the issues you have outlined. The focus to date has been on secure point to point messaging with minimal attention to “smart” messaging which is where significant additional gains can be made in business efficiency (e.g. less re-keying information) and improved decision support (alerts, recalls, reminders).
The business models and financial incentives to date have promoted a non-standardise d, fragmented and patchy ‘discipline specific’ take-up. There is no universal secure messaging directory of health providers, health providers are using multiple SMD services to communicate (with multiple digital certificates), there are limitations in the type of clinical information that can be sent in file type and size, patient matching cannot be done due to different messaging standard implementation, plus the clinical software cannot intelligently process the messages (apart from some limited header labelling and pathology data information).
I also agree that terminology is a major issue and consistency in messaging labelling is another problem. It’s not much point sending a message via SMD if the labelling is so obscure that one would ever find it again in the patient’s record.
When most health professionals are using fax over secure messaging, we have to reevaluate the current offerings in this digital space.
# J-C Meunier 2019-03-30 14:11
Great write up Peter. This piece outlines many of the important hurdles on the journey that large-scale, national secure eHealth messaging has had to take, in order for it now to hopefully achieve its (dare I say "mandated") adoption across Australia.
We should all remain optimistic that the failures of the past should bring Australian Healthcare the future success it demands in this space.
There are some critical aspects of your piece which highlight that:
i) there is a path the industry is now taking,
ii) adherence to technical standards is key,
iii) "fixing" of messages is very risky,
iv) this interoperable messaging solution requires the support, dedication and unwavering commitment from all those that wish to share in its benefits - which should in turn positively impact healthcare businesses and most importantly all of their patients.
We shouldn't be too critical yet, or even worried if the first phase of Australia's interoperable eHealth messaging system isn't as polished as it could be. The efforts we're now taking to help solve this puzzle will be continually worked onvand progressed, and as you state, it will need all your (the users) support in tow.
As one famous kiwi once said - "it won't happen overnight, but it will happen".
# Best Practice Software Staffer 2019-04-01 08:28
Great article Peter. As you have said, the technical issue of one company receiving messages for another is a commercial issue. Not a technical issue. This can be likened (as a previous comment has said, as one phone company (not just mobile), connecting to another. To take the analogy even further, once they connect, if one person is speaking German and the other only understands English, the connection is still useless. This is exactly the situation we have with the messaging standards as they stand today. We have information from one vendor put into different segments of the message, or data within a segment called RTF (for example, but is actually a proprietary standard to that vendor. These are the problems that exist now and going to FHIR is not going to change that.
Paul Symons
# Thinus van Rensburg 2019-04-02 07:37
Gret article and very salient points made by Oliver in his comment

You need to log in to post comments. If you don't have a Pulse+IT website account, click here to subscribe.

Sign up for Pulse+IT eNewsletters

Sign up for Pulse+IT website access

For more information, click here.

Copyright © 2019 Pulse+IT Magazine
No content published on this website can be reproduced by any person for any reason without the prior written permission of the publisher.