Secure Message Delivery in Australia: How SMD Works

What Secure Message Delivery is

SMD is the standards-based approach to point-to-point clinical messaging in Australia, specified in the Australian Technical Specification ATS 5822-2010 and its companion specifications. Mechanically it's store-and-forward: the sender's messaging service accepts a payload, encrypts and signs it, resolves the recipient's endpoint, and delivers it to the recipient's messaging service, with delivery reports flowing back. Unlike My Health Record — a shared repository — SMD is directed correspondence: one sender, one intended clinical recipient.

The payload inside the SMD envelope is a separate concern from the transport, and in practice it's overwhelmingly HL7 v2 (referral and result message types), with CDA used for some structured documents. That layering matters: getting a message delivered and getting it rendered correctly at the far end are different problems, and both are yours.

The payloads: HL7 v2, PIT and CDA

What travels inside the envelope determines most of your engineering effort:

• HL7 v2 messages, localised for Australia. Referrals and specialist letters typically move as v2 referral messages, results as ORU result messages, per the Standards Australia AS 4700 series localisations. Every network and every receiving system has dialect quirks on top of the standard — field usage, escaping, formatted-text conventions.
• Application-level acknowledgements. Beyond transport delivery reports, receiving systems return v2 acknowledgement messages indicating the application accepted (or rejected) the content. A conformant sender tracks these separately from delivery — a message can be delivered and still rejected on parsing.
• PIT, the survivor. The Pathology Information Transfer format — plain-text narrative reports — predates all of this and still flows from some feeds. Consuming systems encounter it whether they plan to or not.
• CDA for structured documents. Some eReferral and document exchange uses CDA payloads over SMD; if that's your pathway, the authoring discipline from the FHIR vs CDA guide applies here too.

The vendor landscape

Almost nobody implements ATS 5822 from scratch. Clinical correspondence moves over commercial messaging networks, each conformance-tested against the SMD specifications historically via NATA-accredited assessment. The names that matter: HealthLink — which acquired Telstra Health's Argus and eReferrals messaging businesses, consolidating two of the largest networks — Medical-Objects, and Global Health's ReferralNet, alongside some regional and specialty players. Market share varies sharply by state and by segment: the network that dominates GP-to-specialist traffic in one state may be marginal in another.

For a CIS or practice software vendor, the realistic integration is with one or more of these networks — via their agents or APIs — rather than standing up your own SMD endpoint. Which networks you integrate first is a market question, not a technical one: find out what the receivers in your customers' referral pathways actually run.

Addressing and directories: the hard part

Delivering a message is easy once you know exactly where it goes. Knowing is the hard part, and it's the part the standards least resolve in practice:

• Identifier soup. SMD anticipated national identifier addressing (HPI-I and HPI-O, from the Healthcare Identifiers Service), but the installed base also runs on network-specific mailbox identifiers — historically called EDIs — and Medicare provider numbers. Real-world routing means holding and mapping several identifier types per recipient.
• Directories are per-network, and data quality is mixed. Each network maintains its own provider directory; entries go stale as clinicians move, and the same specialist can appear multiple times with different endpoints. Federated directory lookup has improved through industry and Agency interoperability work, but treat the recipient directory as data to be curated, not as ground truth.
• Provider Connect Australia helps upstream. The Agency's Provider Connect Australia service lets practices publish their business and practitioner details once, to flow through to partner directories — worth knowing about because it attacks the stale-directory problem at its source.

Interoperability: the reality

Within a single network, delivery is reliable and mature. Across networks is where expectations need calibrating. Cross-network delivery between the major vendors exists — the Agency's secure messaging program pushed interoperability trials, standardised payloads and federated addressing — but in operational practice it still depends on inter-vendor arrangements and per-site configuration, and plenty of clinical traffic simply travels 'wrong network → fax' to this day.

The upshot for product planning: never promise a customer that being on network A means reaching a recipient on network B. Verify actual reachability per referral pathway during implementation, and design workflows to make undeliverable-electronically explicit rather than silently falling back.

What building this actually looks like

The transport integration — the messaging vendor's agent or API — is usually the small half of the work. The larger half is clinical workflow correctness: composing payloads receivers can render, tracking acknowledgements, and building the inbox/outbox semantics clinicians rely on. HL7 v2 rendering deserves particular respect: receiving systems differ in how they display formatted text, embedded PDFs and attachments, and a referral that renders perfectly in one receiving CIS can lose its formatting — or its attachment — in another. Test with the actual receiving systems in your customers' pathways; the FHIR vs CDA guide covers why v2 competence remains non-negotiable for this traffic.

Common failure modes and gotchas

• Transport acknowledgement mistaken for clinical receipt. SMD delivery reports say the recipient's messaging service accepted the message — not that a clinician saw it. The layers above (application-level acknowledgement, and a human actually actioning the message) need their own tracking. Referrals lost in acknowledged-but-unread limbo are a recurring clinical incident pattern.
• No management of the unacknowledged. The defining safety feature of good messaging software is the exception queue: what happens to messages not delivered, not acknowledged, or rejected at the far end. If your product doesn't surface these for follow-up, the fallback is a patient not receiving care and nobody noticing.
• Directory rot. A recipient endpoint that worked at go-live silently stops being current when the specialist changes rooms or networks. Deliverability needs re-verification over time, and your directory data needs a maintenance workflow, not a one-time import.
• Rendering assumptions. Composing rich formatted letters that only render in the sending system's viewer. Test payloads against the receiving systems that dominate your referral pathways — plural.
• Certificate management forgotten. SMD payload encryption and signing ride on PKI — in the national scheme, NASH organisation certificates. Sites with expired certificates stop sending, and the error surfaces in the messaging agent's logs where nobody looks.
• The silent fax fallback. Practices keep faxing when electronic delivery is uncertain, and staff route around your product without telling anyone. If you can't make electronic delivery visibly trustworthy — status, receipts, exceptions — adoption quietly reverts.