ePrescribing Integration in Australia: A Vendor Guide

How Australian ePrescribing works

An electronic prescription in Australia is a legal prescription created by conformant prescribing software and lodged with a prescription delivery service (PDS) — an exchange that sits between prescribers and dispensers. The patient controls access to it in one of two ways:

• The token model — the patient receives a token (a QR code, delivered by SMS, email, or in an app). Whoever presents the token at a pharmacy lets the dispensing system retrieve the prescription from the exchange. A new token is issued for each repeat.
• The Active Script List (ASL) — a consent-based list of the patient's active prescriptions that a pharmacy can access without individual tokens. It solves the 'lost token' problem, at the cost of a registration and consent workflow.

eRx, MediSecure, and how we got one exchange

For most of the 2010s Australia had two prescription exchanges: eRx Script Exchange (Fred IT Group) and MediSecure. Both predated token-based electronic prescriptions — their original business was carrying the data behind barcoded paper scripts (ePrescription 'v1'), and both were uplifted for the legal electronic prescription model rolled out nationally from 2020.

The two-exchange era ended with a Commonwealth tender: from late 2023, electronic prescriptions ceased to be available through MediSecure, and the national prescription delivery infrastructure consolidated onto eRx, operated by Fred IT under contract to the Australian Government — sometimes referred to as the national prescription delivery service. MediSecure itself then suffered a major, widely publicised data breach in 2024, an event worth knowing about mainly for what it signals: prescription exchange data is nationally sensitive, and the handling obligations on anything you build in this space are taken seriously.

The practical consequence for vendors today: there is one exchange that matters, integration with it is arranged commercially with the operator, and the Department of Health's electronic prescribing pages plus the Agency's developer portal are the authoritative sources on how the arrangements currently stand.

Where My Health Record fits (and where it doesn't)

A confusion worth killing early: the Active Script List is not My Health Record. The ASL lives with the prescription delivery service and governs dispensing access to active prescriptions; My Health Record separately receives prescription and dispense records as documents in the patient's national record, under My Health Record's own consent model. A patient can have an ASL and opt out of My Health Record, or the reverse.

For a vendor this means two distinct outbound obligations with different failure modes: the exchange interaction that makes supply legally workable, and the My Health Record flows that keep the national record complete. Conformance treats them separately, and so should your architecture — a My Health Record outage must never block a dispense.

The ePrescribing conformance process

Conformance is Agency-run and product-type specific. The Electronic Prescribing Conformance Assessment Scheme defines the process; under it sit conformance profiles and test specifications for each class of software — prescribing systems, dispensing systems, medication chart prescribing systems, and intermediaries such as token-handling apps. You conform against the profile for what your product actually is, and the requirements differ meaningfully between them.

The general shape: register your product with the Agency, build against the specifications and the exchange's integration environment, execute the conformance test specifications, and submit a Declaration of Conformance for your product version. Alongside Agency conformance you'll need the commercial and technical onboarding with the exchange operator, and your customers remain subject to state and territory prescribing law — electronic prescriptions are legal nationally, but controlled-drug rules and real-time monitoring obligations vary by jurisdiction.

Versions of the scheme, profiles, and test specifications are updated on the Agency's schedule — check the electronic prescribing conformance pages for the current set rather than trusting any summary, including this one.

Common failure modes and gotchas

• Conforming against the wrong profile. A medication chart product that assumes the standard prescribing profile, or an app that touches tokens without treating itself as an intermediary, discovers late that a different (sometimes stricter) profile applies. Classify your product against the current profiles before building, not after.
• Evidence of Prescription requirements surfacing late. The rules around what constitutes the legal record of a prescription — and what must be reproducible from your system — are precise, and they shape data models. Teams that treat them as a documentation afterthought end up reworking storage and audit design.
• Under-building token lifecycle handling. Lost tokens, cancelled prescriptions, re-issued tokens, and repeats each have defined flows. The unhappy paths are conformance test cases, and in production they're daily events at pharmacy counters — a prescriber-side product that can't cleanly cancel and reissue generates real-world phone calls.
• Treating ASL as a checkbox. The Active Script List has its own consent and registration workflows, and its own conformance requirements. Bolting it on after the token model is working is harder than designing for both from the start.
• Ignoring the paper hybrid. Australia still runs paper prescriptions alongside electronic ones, including barcoded paper carrying exchange data. Prescribing workflows need to handle the patient who wants paper, and dispensing workflows the paper script that is also in the exchange — without double-supply.
• Forgetting the adjacent integrations. A dispense event may need to hit the exchange, My Health Record, PBS claiming, and a state real-time monitoring system — each with different identifiers, credentials, and failure modes. Design the outbound pipeline so one failing leg doesn't block supply or silently drop another.
• Scheduling around the exchange's test environment. Integration testing happens in the exchange operator's environments on their calendar, with conformance observation to arrange as well. Vendors who assume all testing is self-serve, on-demand tend to discover the critical path late.

Sequencing an ePrescribing integration

The dependencies are the usual national-infrastructure stack: HI Service integration and NASH credentials come first, then exchange onboarding and the conformance profile for your product type, then My Health Record flows if in scope. If several of these are new to your team, the ADHA conformance checklist lays out how the testing processes interlock and where the calendar time actually goes.