Electronic prescribing in Australia is not a single feature you bolt onto your software. It's a regulated, multi-agency, multi-system infrastructure with strict conformance requirements, external approval queues, and ongoing compliance obligations. This guide covers every step from HI Service registration to ADHA conformance to state-based monitoring.
Electronic prescribing in Australia isn't simply digitising a paper script. It's a federally regulated system that securely connects prescribing software, a national delivery infrastructure, patients, and dispensing pharmacies through a chain of cryptographically verified transactions.
At the centre of this system is the National Prescription Delivery Service (NPDS), operated by Fred IT Group via the eRx Script Exchange under contract with the Australian Government. The NPDS processes nearly 300 million prescriptions per year and is the sole infrastructure through which electronic prescriptions are legally transmitted in Australia.
The end-to-end flow works as follows:
Every system that touches the prescription (the prescribing software, the delivery service, and the dispensing software) must be independently conformant and listed on the ADHA's register. This isn't optional. An electronic prescription generated by non-conformant software is not legally valid.
For an electronic prescription to be legally valid in Australia, all participating systems must be listed on the ADHA Electronic Prescribing Conformance Register with a current Conformance ID. There are no exceptions. Operating without conformance exposes your organisation to regulatory and legal risk.
One of the most underestimated aspects of eScript compliance is the sheer number of separate government bodies, infrastructure operators, and commercial providers involved. Each has their own processes, timelines, and queues, and you'll need to coordinate across all of them.
| Organisation | Role in ePrescribing |
|---|---|
| Australian Digital Health Agency (ADHA) | The governing authority. Sets conformance standards, publishes the Technical Framework (Solution Architecture, Conformance Profile, Assessment Scheme), manages the conformance assessment process, and maintains the public Conformance Register of approved software. |
| Services Australia | Administers PBS claim-for-payment systems. Issues NASH certificates through PRODA/HPOS. Manages Healthcare Identifier registration (HPI-O, HPI-I, IHI). Processes are bureaucratic and queue-dependent, so factor in wait times. |
| Fred IT Group / eRx Script Exchange | Operates the NPDS under government contract. Conducts the observed conformance assessment sessions. They are the gatekeeper for your software going live, and their assessment capacity directly impacts your timeline. |
| MIMS Australia | Commercial provider of the standard medication database used across Australian healthcare. Not required for ADHA conformance, but widely used for drug information, interaction checking, and dosage validation. Paid subscription with monthly updates. |
| State Health Departments | Each state operates its own Real-Time Prescription Monitoring (RTPM) system with its own compliance requirements and monitored medicine lists. The National Data Exchange (NDE), built by Fred IT, provides a centralised data transport layer, but state-specific regulatory logic still applies. |
You are navigating multiple government bodies, each with independent processes, queues, and timelines. Services Australia may take weeks to issue a NASH certificate. The ADHA conformance queue depends on how many vendors are ahead of you. Fred IT's assessment calendar has limited slots. None of these timelines are within your control, and none of them wait for each other. Plan accordingly.
This is where everything begins, and where many organisations underestimate the complexity involved.
Before you can pursue ePrescribing conformance, your software must first be independently conformant with the Healthcare Identifier (HI) Service. This is a separate conformance process, assessed and managed by the ADHA, and it is a hard prerequisite. There is no way to skip, fast-track, or work around it.
The HI Service is Australia's national infrastructure for uniquely identifying every patient, practitioner, and healthcare organisation in the system. It provides three identifiers that are foundational to electronic prescribing:
A unique 16-digit identifier for every patient in Australia. Your software must validate a patient's IHI using their Medicare number and demographics before any eScript can be created. This is not optional. An eScript without a validated IHI is not valid. This single requirement is the reason HI conformance exists as a prerequisite.
Uniquely identifies each healthcare practitioner. Every prescription must be attributed to a specific prescriber via their HPI-I. Your software needs to look up and validate practitioner identifiers and maintain the linkage throughout the prescribing workflow.
Uniquely identifies your clinic, pharmacy, or healthcare organisation. This is your organisation's identity in the national system. It's required for obtaining your NASH certificate, connecting to the NPDS, and participating in any national digital health service.
This is a multi-step process that involves both organisational registration and technical software development. Both tracks run in parallel, but both must be complete before you can move to ePrescribing.
Apply for an HPI-O through PRODA/HPOS. You'll need to designate a Responsible Officer (RO) (someone with authority to act on behalf of the organisation) and an Organisation Maintenance Officer (OMO) who handles day-to-day administration. This is a bureaucratic process through Services Australia, not a technical one. Allow time for processing and potential back-and-forth on documentation.
The National Authentication Service for Health (NASH) certificate is your organisation's cryptographic credential for accessing national digital health systems. Your OMO requests it through HPOS, receives a Personal Identification Code (PIC) via SMS, and downloads the certificate. The download link expires after 30 days. Your IT team or software vendor then installs it. This certificate must be renewed before expiry. If it lapses, your connection to national systems stops working immediately.
The Healthcare Identifier Service Enquiry Line can assist with registration issues, certificate problems, and general HI Service questions.
This is the development work. Your software must implement real-time lookups against the HI Service API to validate IHIs using patient demographics (name, date of birth, sex, Medicare number), resolve HPI-Is for practitioners, and verify HPI-Os for organisations. You need to handle all response scenarios: successful validation, no match found, deceased or retired flags, multiple matches requiring disambiguation. Edge cases here are common and must be handled gracefully.
Once built, your software goes through the ADHA's conformance process specifically for the HI Service. This includes self-assessment, documentation, and verification by the ADHA. This is a separate conformance process from ePrescribing. You must pass this first before you can even begin ePrescribing conformance.
An electronic prescription cannot be generated without a validated Individual Healthcare Identifier for the patient. If the IHI lookup fails for any reason (incorrect details, no Medicare number, deceased flag, system timeout) the prescription cannot proceed electronically. There is no override, no workaround, and no exception. This is why HI Service conformance is the non-negotiable first step.
Understanding how IHI validation works at a practical level is critical, because this is the single most important integration in the entire ePrescribing chain. Every electronic prescription starts here.
When a practitioner is ready to prescribe electronically, your software must first validate the patient's identity against the national HI Service. This happens in real time during the clinical workflow:
Your software must handle all three possible outcomes from the HI Service:
Patients with name changes, incorrect Medicare details, recently arrived residents, or data entry errors will fail IHI validation. Your software needs a clear workflow for handling these cases: prompting staff to verify details, retrying the lookup, or falling back to paper prescribing. In a high-volume clinic, this happens daily.
With HI Service conformance behind you, you can now build the actual ePrescribing capability and pursue formal ADHA conformance. This is the longest, most complex, and most resource-intensive phase of the entire process.
Your software must integrate with the NPDS via the eRx Script Exchange to create, transmit, and manage electronic prescriptions. This includes prescription creation workflows, secure NPDS communication protocols, token generation and delivery (QR codes, SMS, email), prescription status tracking, and error handling for transmission failures. You must also register your organisation with the eRx Script Exchange and configure Electronic Transfer of Prescriptions (ETP) in your software before any live testing can begin.
The ADHA publishes a detailed Technical Framework (currently v3.3) consisting of three documents: the Solution Architecture (how all components connect), the Conformance Profile (every requirement your software must meet), and the Conformance Assessment Scheme (how you'll be tested). These are your blueprint. Study them thoroughly before writing a line of code.
Download the full ADHA Electronic Prescribing Technical Framework package. Map every requirement in the Conformance Profile to your software architecture. Identify gaps between what your current system provides and what you need to build. Don't underestimate this. The Conformance Profile is dense, and missed requirements surface during assessment, causing costly rework.
This is the major development effort. Prescription creation, NPDS/eRx integration, token generation (QR codes, SMS/email delivery), secure transmission protocols, prescription status management, error handling, retry logic, and the full prescribing workflow within your clinical software. Every interaction must comply with the Conformance Profile. There are no shortcuts here.
The CTS is a detailed self-assessment document published by the ADHA. You work through every test case (and there are many), execute them against your software, record the results with evidence, and compile the full submission. This is meticulous, time-consuming work. Incomplete or poorly documented CTS submissions get rejected and sent back, adding weeks to your timeline.
Your completed CTS is submitted to the NPDS Provider for review. They assess the quality and completeness of your submission before scheduling an observed assessment session. If there are gaps, missing evidence, or failed test cases, they'll return it for remediation before proceeding.
The NPDS Provider has limited assessment capacity. They process submissions from every software vendor in Australia seeking ePrescribing conformance. Depending on demand, there can be a significant wait between submission and your observed assessment session. This is an external timeline you cannot influence. The earlier you submit a clean, complete CTS, the sooner you enter the queue. Submitting a rushed, incomplete CTS that gets bounced back puts you at the end of the line again.
This is the live examination. The NPDS Provider watches you run through test cases in real time, verifies your submitted CTS results, and validates that your software meets every requirement in the Conformance Profile. They will probe edge cases, test failure scenarios, and may request additional evidence or demonstrations not covered in the CTS. If issues are found, you'll need to remediate and potentially retest, which means rebooking an assessment slot.
The conformance assessment process takes a minimum of 20 business days (approximately one calendar month) with the Agency. This is just the assessment and processing time and does not include your development, self-assessment, queue wait, or any rework. In practice, the end-to-end time from CTS submission to Conformance Register listing is typically 2-4 months, and longer if rework is required.
After passing the observed assessment, you complete the Electronic Prescribing - Conformance Vendor Declaration form. The ADHA then notifies Services Australia, the NPDS operator, and other relevant infrastructure operators of your conformance status. Your software is published on the Electronic Prescribing Conformance Register, the public register of all approved prescribing and dispensing software in Australia. Only at this point can your software issue legally valid electronic prescriptions.
On top of national ePrescribing conformance, your software must also integrate with Real-Time Prescription Monitoring (RTPM) systems. These are state-operated databases that track the prescribing and dispensing of high-risk medicines (opioids, benzodiazepines, sedatives, and stimulants) in real time.
This is directly relevant to cannabis clinics. Prescribers must check the relevant RTPM system before writing a prescription for any monitored medicine. In most states, this is now mandatory, and failure to check carries significant financial penalties.
While each state operates its own RTPM system, the Australian Government has funded a National Data Exchange (NDE), built and operated by Fred IT Group (the same organisation behind eRx). The NDE sits underneath all state RTPM systems and provides a centralised data layer. If your software is already integrated with eRx for ePrescribing, RTPM checks can be routed through that same connection to the relevant state system, rather than building separate integrations per state. This significantly reduces development scope compared to integrating with each state individually.
The NDE handles the data transport, but each state still maintains its own regulatory requirements, monitored medicine lists, and compliance obligations. Your software still needs to handle state-specific logic for which medicines trigger RTPM checks and how results are displayed to clinicians. The integration is simpler, but the compliance layer is still per-state.
MIMS (Monthly Index of Medical Specialities) is the standard medication database used across Australian healthcare. While MIMS is not a formal requirement of the ADHA ePrescribing Conformance Profile, most prescribing software integrates with it for clinical safety reasons:
MIMS is a commercial, licensed product with an ongoing subscription fee. The database is updated monthly. You can technically achieve ePrescribing conformance without MIMS, but operating a prescribing platform without a drug reference database would be a significant clinical risk. Most vendors treat it as a practical necessity even though it is not a regulatory one.
Some ePrescribing solution providers include MIMS in their offering at no extra cost to their users. If you're building your own prescribing platform, budget for the licence as a recurring operational cost.
Here is the realistic end-to-end timeline for building eScript compliance into your software from scratch. This assumes a dedicated development team, no major technical blockers, and normal (not expedited) processing times from government agencies.
| Milestone | What's Involved | Duration |
|---|---|---|
| HI Service Conformance | HPI-O registration, NASH certificate, IHI/HPI-I/HPI-O validation build, HI conformance testing with ADHA | 2-4 months |
| Technical Framework Review | Study ADHA Solution Architecture, Conformance Profile, Assessment Scheme | 2-4 weeks |
| Core ePrescribing Build | Prescription creation, NPDS integration, eRx connection, token generation, secure transmission | 4-8 months |
| RTPM Integration | Via eRx/NDE for data transport, plus state-specific compliance logic (can parallel with core build) | 2-4 months |
| MIMS Integration | Licence agreement, medication database integration, interaction checking | 1-2 months |
| Self-Assessment (CTS) | Complete all test cases, document results, compile evidence | 1-2 months |
| CTS Submission + Queue | Submit to NPDS Provider, review, queue for assessment slot | 1-2 months |
| Observed Assessment | Live assessment, ADHA processing, potential rework | 1-2 months |
| Registration & Go-Live | Vendor Declaration, Conformance Register listing, production rollout, stabilisation | 1-2 months |