Future of Secure Messaging in Australia
Jun 19, 2019The Australian Digital Health Agency is working hard on a secure messaging project. This is a project to build out a working eco-system so that any clinician can send documents and messages to any other clinician in a secure fashion.
There’s multiple uses of the this kind of messaging:
- Sending Diagnostic Reports to the requesting physician, along with anyone else the physician asked to be notified
- Sending Discharge Summaries
- Referrals from GP to specialist, and letters back to Specialists
- Submission of forms to hospitals (usually a form of referral)
- Requests for further information from other clinicians
Some of these are well in production and have been for many years. Yet clinicians still report being overwhelmed by paper from their faxes, and that’s generated an “Axe the Fax” campaign (that phrase, btw, appears to have come from UK).
About Healthcare and Faxing
Note that the healthcare system is effectively responsible for keeping the fax industry alive (here and overseas). By some estimates I’ve heard, healthcare buys 80% of new faxes (but I can’t find any reference that says that).
Why is faxing so enduring in healthcare in particular?
Most of the commentary focuses in bad incentives around sharing information. I’m not sure that makes sense – ‘we are sharing information by massive volumes of fax because we have no incentive to share information’? I feel like that sentence doesn’t hang together.
The first and proximal reason that faxing is ubiquitous in healthcare is because email is not regarded as secure, and so all the work that’s moved to email in other industries hasn’t moved for health care.
“You can’t send sensitive healthcare information by email” (Nathan Pinskier)
And the work to get email secure is really signfiicant - no other industry has done it to my knowledge (except the military on closed networks that they build at considerable expense - maybe we should build a healthnet?)
Not that faxing is actually that secure – it’s only as secure as the telco network (not much more secure than email these days - now that email has improved a lot, mainly by reducing the hop count) and the sender’s ability to get the destination fax number correct (see case in the Nathan Pinskier article). I once was part of an investigation into a Queensland premier’s diagnostic report accidently being faxed to a news agent because a GP didn’t notify the diagnostic service when his number changed.
What we need is a secure alternative to email – some alternative protocol that allows for messages to be sent reliably and securely between healthcare providers.
Sending Messages Securely
Of course, here in Australia, we have one of those. SMD “Secure Message Delivery” is an Australian Standards (AS 5552) finalised back in 2010 that specifies how software acting on behalf of any healthcare provider can send a message to any other provider.
But in practice, providers can’t actually do that. They can easily deliver to some participants, but not to others. The government has focused quite some attention on digital health initiatives over the last decade, but none of them have focused on this very day to day operational problem in healthcare, and things haven’t been getting better.
The reason it isn’t just working as desired is not related to the protocol, but to the surrounding support – certificate management, registry administration, and implementation issues. It’s a really simple question – can you find the address of the person you want to send it to, and then encrypt it for them, and send it, knowing that your messaging provider will actually be able to send it? – and that the cost of getting all this to just work will be paid somehow).
Readers should be clear, btw, that whatever else is a problem here, a real part of the problem is the healthcare system’s very conservative approach to technology. There’s no reason at all for GP practices to be buried in paper – just use a fax server that turns faxes into incoming digital documents (email etc.) internally – it’s cheaper and more convenient, and you can just do it – so why not?
Secure Message Project
Nevertheless, there are real adoption barriers here, many that are really linked to lack of incentives. As a result of stakeholder feedback, the Digital Health Agency initiated a collaborative program with the relevant clinical record software and message delivery vendors, along with some stake holder representatives, with the mission to identify and any reasons that were blocking progress.
That program is still working. (Btw – I consult to the Digital Health Agency on this program a little).
The program is still going ahead, slowly (well, more slowly than the stake holders desire, but not more slowly, so far as I can see, than these programs usually take). It’s generating press recently (see here, and here).
In the last few months, I’ve had a few people express to me the opinion that this program is not making a good investment. The source of this concern comes from architectural and protocol concerns.
Secure Message Delivery Protocol
The SMD protocol is a SOAP based protocol that is designed to do reliable and secure store and forward where the ultimate destination may be unavailable – on the basis that the end point – the clinical desktop – is not available for direct delivery.
That’s yesterday’s technology – why, they ask, are we investing in it?
It’s true that industry has largely moved on from SOAP. We certainly would not use SOAP if we were starting on that specification now. In USA, starting at about the same time, they chose to use a secure email based approach, called Direct, now looked after by Direct Trust). We would certainly chose some approach like that now, unless we choose an even more direct delivery approach.
The other major factor that is changing is the “not available for delivery” characteristic – the store and forward mechanism that the SMD design is based on is increasingly unnecessary as more and more processing moves to the cloud, where the recipient end points are always available.
In the Cloud
When the Secure Message Program started, industry trends suggested that adoption of the cloud would be very slow – over a decade, if not longer (partly because of the extreme conservatism of healthcare cited above, but also due to security concerns).
However during the time of the program, cloud adoption has accelerated dramatically, and many vendors have already deployed or are in the process of deploying cloud agents that act on behalf of the clinical system, irrespective on whether the system lives in the cloud or on the desktop). Given that environment, it seems as though investing in a store and forward based technology is investing in the past.
A direct delivery protocol – where clinical systems delivered directly to each other by some web service mechanism (there are several obvious candidates) is not only simpler, but can also be more reliable since the receiver can respond directly to the sender with regard to any business issues with the content.
So should we abandon SMD and work on a newer protocol instead?
Tomorrow vs the future
The first issue with this question is that, as I said above, the protocol is not the problem – it’s the certificates, the registries, and the business models around the message delivery that are the problem. So merely changing the protocol… how does that help?
Well, it might make a difference, inasmuch as it could change the business realities and the considerations around certificates and registries etc. Though those are still the hard problems that need to be solved, and that the Secure Message Program is currently working on solving. So any work done now will at least be empowering and useful for any new protocol in the future.
The real question, though, is whether we should be aiming low, with lower risk, or aiming high, and taking on more risk. That’s a value question, really. Though I think that most people will say that the we should demonstrate that we can walk before we run.
Still I have some sympathy for the idea that we should invest in the future. It’s not rocket science to realise that in the future, everything will be based on web protocols, and that we’ll be running mix of
· Pull (providers access information when they want it)
· Push (providers send information or notifications to other providers when they need to know about it)
· Subscription (providers ask to be notified about specific events as they happen)
Nor is it much of a stretch to think that you should use one common exchange framework for all 3 of those, and that our best current choise for that is FHIR.
I’m not sure how we should consider this question – I’m sure there’s some out there who want to make the transition now, and not invest in SMD anymore. And I’m sure that there’s some out there who think we should just get SMD right and stick with that. I hope that there’s more who think that we will have to make the transition eventually, but aren’t sure when.