Skip to main content
Guide
DG-3118
Status
Approved
Updated date

(Updated 15 March 2024) 

General Questions

Who is eligible for developer support?    
The Agency provides dedicated support to all software developers participating in Electronic Prescribing. Guides and other reference material are also published on this website for anyone interested in Electronic Prescribing to view, and general enquiries are welcome at any time.  

Do GP clinics and community pharmacies need to connect to the Healthcare Identifiers (HI) Service?      
Yes.  The ability to unambiguously identify the consumer is an essential element of the Electronic Prescribing process.  For Electronic Prescribing, the validation of the consumer's identity using the HI Service is a mandatory requirement. 

This does not apply to development of the Transitional electronic National Residential Medication Chart (eNRMC) arrangement, which does not require a consumer's Healthcare Identifier to be verified. For more information, please visit https://www.health.gov.au/resources/collections/enrmc-transitional-arrangements-collection 

Which certificates and security arrangements are required to connect with the National Prescription Delivery Service (NPDS)?
The NPDS establishes its own certificate and connection security approach that meet the conformance requirements. You will need to contact the NPDS for specifications.

Is the prescription Token sent to the patient from the Prescribing Software, or, from the NPDS?       
A token can be sent from the prescribing system or the NPDS. The solution architecture is deliberately agnostic to allow the market to innovate. The Agency has intentionally not mandated any constraints in the solution architecture.  

What safeguards are planned for information security to ensure that there is end-to-end security by design? Will there be security testing to safeguard data?      
The Agency has provided testing material as part of the software conformance process. During conformance testing, software systems must demonstrate that they meet the relevant conformance requirements for information to be encrypted both in transit and at rest.  

How are Schedule 8 medications prescribed through electronic prescribing?
Electronic prescribing accommodates the prescribing of Schedule 8 medicines. Prescribers should prescribe these medicines in accordance with their relevant state and territory drugs and poisons (or equivalent) legislation. Please refer to the Schedule 8 quick reference guide for electronic prescriptions here. Prescriber re-authentication is required prior to submitting a Schedule 8 Medicine (see PRES-7).

How are Schedule 8 medications dispensed through electronic prescribing? 
Electronic prescribing accommodates the supply of Schedule 8 medicines. Pharmacists should dispense these medicines in accordance with their relevant state and territory drugs and poisons (or equivalent) legislation. Prescriber re-authentication is required prior to submitting a Schedule 8 Medicine (see PRES-7).  

Will there be any changes to how Complex Authority Prescriptions are authorised and provided to a patient?      
Complex Authority Prescriptions (CAPs) can be authorised where an additional written approval is required. A gradual transition of CAPs to electronic prescribing format is being progressed by governments.    

Will electronic prescribing be available to non-PBS registered/approved pharmacies?      
Electronic prescriptions can be used for PBS, RPBS and private medicines, and they can be dispensed via non-PBS registered pharmacies, provided they are using dispensing software products that are conformant for Electronic Prescribing. The legislative changes at a Commonwealth level only apply to the PBS. However, states and territories recognise electronic prescriptions regardless of whether it is a PBS prescription or a private prescription. Please, refer to section 2.3 of DH-3542:2021 Electronic Prescribing – Solution Architecture v3.0 

Is it possible for a pharmacist to annotate an electronic prescription?      
The solution design allows for a pharmacist to annotate a prescription electronically as part of a dispensing activity so that any subsequent dispensing pharmacist will see the annotation.   

Are there any specific considerations for public or private hospital discharge scripts or expectations to follow the same process as clinics? 
For medicines on a hospital prescription that are intended to be dispensed outside of the hospital’s supply process, the hospital will upload the prescription to the NPDS in the same way as a prescriber would in a community setting.  The patient can take their prescription tokens to the pharmacy of their choice to have their medicines dispensed when required.  

What state and territory regulations apply to my product?      
All developers need to consider the state or territory where their software will be used and ensure their products comply with the relevant requirements. Developers are responsible for understanding their legal obligations for operating in each state and territory. A summary of the state and territory requirements is listed on the Department of Health and Aged Care electronic prescribing information page – this resource is developed as information only and should not replace independent legal advice.  

Where can I find the wording for the Privacy Notice?     
Approved Privacy Notice wording is available from the Services Australia Health Systems Developer Portal. Only registered users can access the portal. The Department of Health and Aged Care publishes the Electronic Prescriptions Privacy Policy.  

What should a printed Evidence of Electronic Prescription look like?      
The Agency has included an example of a printed Evidence of Prescription in Appendix A of the Conformance Profile. This is an example only and developers may implement their own design if it meets the associated conformance requirements.  

Are there standard API schemas defined by the Agency for Open Prescription Delivery Service APIs?      
The Agency isn’t developing new standard API schemas.  The Agency is responsible for developing the Conformance Profile.   

What is considered “companion software”?      
Companion software is any software that is used to fully or partly satisfy conformance requirements.  

Our product uses companion software (e.g. a workflow engine) to process or manage electronic prescriptions, how should we include this in our conformance testing?      
If your product uses companion software such as a PDS adaptor, a workflow engine, or other to process or manage electronic prescriptions, this should be documented in your conformance test evidence on the Test Summary Report (TSR) worksheet of the conformance test specifications file, and displayed during your observed testing session. Additionally, you are required to include the details (product and version) of any companion software your product uses as part of your declaration of conformance to the Agency. For reference, see conformance requirements DISP-95 and PRES-95 in the Conformance Profile.  

Is it mandatory for our system to connect to the NPDS and the ASLR?
The connection requirements for each software system type are:  

  • Dispensing systems must connect to both the NPDS and ASLR.   
  • Prescribing systems must connect to the NPDS. It is optional for prescribing systems to connect directly to ASLR.   
  • Mobile Intermediaries can connect to either the NPDS, ASLR or both.   
  • Mobile Applications must only connect to a Mobile Intermediary.

Is it mandatory for my Electronic Prescribing software to provide electronic prescriptions to DVA card holders?      
Yes.  Department of Veterans’ Affairs (DVA) card holders are consumers of electronic prescriptions. The HI Service supports the discovery of IHI's via DVA card numbers. For more details regarding DVA requirements, refer to the applicable Electronic Prescribing Conformance Profile for your software system type.

Can a medication be dispensed when the HI Service is unavailable? 
When the HI Service is unavailable and the IHI number cannot be verified, an electronic prescription can still be retrieved from the NPDS (using a token) and a dispense record can be sent to the NPDS.

Prescribing Systems

(For more information on Conformance Requirements (PRES-#, DISP-# and MA-#) refer to the Electronic prescription conformance test specifications(CTS))

PRES-6 What is meant by ‘healthcare organisation’?      
The 'healthcare organisation' is the entity that owns and operates the healthcare service that uses the prescribing system.  

PRES-7 Do the two passwords need to be different for each user account?      
The re-authentication password can be the same as the 'first' password.  

PRES-12 Must this requirement be implemented in the CIS?      
Pres-12 is a recommended (SHOULD) requirement. When appearing in a conformance requirement, the verb SHOULD indicates a recommendation.  

PRES-18A What is an Authorisation Reference Number?      
The Authorisation Reference number is a state or territory-issued number required for some medicines. Each state or territory may define an alternative name for this number (e.g. Warrant Number in Victoria or Permit Number in South Australia).  

PRES-18B Is it acceptable to require the user to input the selected treatment information by typing the information into the Prescription notes field?      
It is acceptable for a user to input the information by typing into the Prescription notes field, provided that the information is not limited or truncated in the electronic prescription.   

PRES-21 Must the software support SNOMED-CT AU for requirement PRES-21?
The need for software to support SNOMED CT-AU is optional for prescribing systems at this stage. The NPDS supports CIS products to include SNOMED CT-AU codeable values.  The Australian Digital Health Agency distributes SNOMED CT-AU to the Australian community via the website https://www.healthterminologies.gov.au/. If you require further support implementing SNOMED-CT AU in your system, please contact the Agency at [email protected].

PRES-21 What is the rationale for providing a ‘Reason for prescribe’?      
Reason for prescribe is included to improve consumer adherence to medications and to assist pharmacists in their clinical review of the prescribed medication, dosage regimen and route of administration.  

PRES-22 What is original text and what does this requirement expect?      
The reference to 'original text' means that the inclusion of codes (e.g. SNOMED/PBS) does not remove the need to include 'plain English' values/attributes provided by the prescriber.  

PRES-24 What does “obtain final approval from the prescriber” mean and can a preview of an electronic prescription resemble a paper prescription?     
The on-screen prescription can look like a paper prescription but it is not a requirement. A printed Evidence of Prescription must not resemble a paper prescription. The final approval could be a “SEND” button or similar so that the prescriber makes a conscious decision to send the prescription to the NPDS.   

PRES-24 requires the display of "all data fields" to the prescriber. Does the system need to represent data that is already stored in the GUI, on layers behind the screen or stored elsewhere in the system?      
Yes.  Prescribers must be given an opportunity to review the prescription in full prior to issuing, and make any required amendments, to ensure patient safety.    

PRES-25 My software uses a PDS connecter (adaptor) – how do these requirements apply?  A "prescribing system" under test is defined as the combination of the Prescribing software and the PDS adapter (if relevant). The Prescribing software developer is expected to coordinate the installation and testing of any additional software components that are required for their software to function as a "prescribing system". PRES-25 refers to authentication of the PDS system details   

PRES-26 My software uses a PDS connecter (adaptor) – how do these requirements apply?      
A "prescribing system" under test is defined as the combination of the Prescribing software and the PDS adapter (if relevant). The Prescribing software developer is expected to coordinate the installation and testing of any additional software components that are required for their software to function as a "prescribing system". PRES-26 refers to assertion of the prescribing system authentication.   

PRES-31 requires time and time zone. Can the system capture just the time and then add the time zone later when there is a report, query, or enquiry?     
The time zone needs to be recorded with the timestamp at the time of capture/data entry. Trying to derive or calculate the time zone after-the-fact is prone to error and is unsuitable for auditing purposes, for which clear and indisputable data logs are required.  

PRES-48A Can the Evidence of Prescription (EoP) contain information on the patient's existing conditions?     
No. Information on existing conditions may be clinically sensitive and must not be displayed on the EoP.  

PRES-931 How do we present conformance evidence for password cryptography?      
The evidence should show that passwords are not stored as plain text.  It should also include a screenshot of configuration settings or code that clearly indicates which cryptographic algorithm/function is being used. An explanation or example can be provided when demonstrating cryptography salt.  

Is there a minimum length of the cryptographic salt used by the hashing algorithm?       
The Conformance Profile does not specify the minimum length of salt.   

PRES-38 If a request to the NPDS has been rejected due to security reasons, is it OK for the audit log to not include a DSPID or other data?
The software system needs to log all the information specified in PRES-38. If some information is intentionally not available, then it should be noted in the audit log (which is not the same as leaving it blank/null). 

I have a consumer facing mobile platform that provides access to prescribers. Can I insist that all EoPs are provided through that mobile platform?      
No. PRES-45 ensures that the consumer has the option to specify the address they wish to receive an EoP.  

My prescribing software is mobile based or used in a telehealth setting and has no access to a printer. Does the software still need to satisfy requirements around printing prescriptions and printing an EoP?     
Prescribing software that is designed to be used on a mobile device or in a telehealth setting doesn't need to print an EoP but does still need to be able to print a paper prescription. Telehealth services need the option to print paper prescriptions and post them to a patient or pharmacy when the creation of an electronic prescription is not possible (e.g. NPDS is unavailable) or when the patient chooses to use paper prescription.

PRES-6 requires workstations to be locked. Can the software allow an organisation to disable the time out for automatic workstation locking through configuration options?  
No. PRES-6 is designed to mitigate the risk of workstations being left unattended.

Dispensing Systems

How do prescriptions held on file work with electronic prescriptions?      
Printed Evidence of Prescriptions (EoPs) for repeat prescriptions should only be retained in pharmacies in specific cases, such as consumer request or Staged Supply arrangements. Consumers who traditionally keep their scripts on file should be encouraged to register for an Active Script List (ASL).  

DISP-3 My software uses a PDS connecter (adaptor) – how do these requirements apply?      
A "dispensing system" under test is defined as the combination of the Dispensing software, any PDS adaptor and any other products used to meet the conformance requirements (if relevant) (DISP-95). The Dispensing software developer is expected to coordinate the installation and testing of any additional software components that are required for their software to function as a "dispensing system".  

DISP-6 What are user classes and which ones do the software need to support?      
The user classes mentioned in the requirement can be anything the software designer chooses. There must be at least one class. It is recommended that class names are intuitive, logical and obvious in meaning.  

DISP-30 What is the ‘Evidence of Prescription (EoP)’ and can it be printed/reprinted multiple times if requested/necessary?      
The EoP contains a barcode/QR code that enables the CIS to retrieve the legal electronic prescription. It can be reprinted if necessary.  

DISP-24 The Conformance Profile states: "If the dispense does not proceed, it shall be unlocked." How is "does not proceed" defined?      
“Does not proceed” means the dispenser does not dispense the electronic prescription and cancels the process in their software prior to a dispense record being posted to the NPDS (or the process times out).   

DISP-36 Does the audit log require a GUI so it can be viewed?      
There is no requirement to provide a GUI for any audit log. Access via any tool/back-end process is sufficient.  

DISP-36 What does “all information fields” mean?      
All the information that is sent to the NPDS needs to be provided in the audit log.  

DISP-38A If the CIS system experiences extended internet outage will all dispense records need to be reconciled to prescriptions when the NPDS can be eventually reached?      
Yes. Reconciling dispense record to prescriptions is necessary to track repeats and to prevent excess dispenses.  

DISP-51 What format and structure does the ‘prescription file’ need to be?      
This requirement relates to dispensing systems obligations to keep accurate records that are available for regulators when and if required. There is no pre-defined criteria or fixed format but the product must ensure it can provide the described information on request.

Mobile Applications

Can my mobile app have a button that sends a token directly to a pharmacy that is determined by the mobile app developer?      
The mobile app can send a token to a pre-determined pharmacy however, there must also be options for a consumer to share that token with other pharmacies if they prefer. This is required to ensure consumer choice is preserved.   

Requirement MA-8 states that the system SHALL allow a user to de-activate an account with a mobile intermediary.  Account de-activation for our system is available via Customer Support. Would this satisfy the conformance requirement MA-8?     
No. MA-8 requires the software to provide a de-activation function. This software requirement can't be satisfied by a process that sits outside the software. The software needs to demonstrate this function.  

Do mobile applications and mobile intermediaries need to connect to the HI Service?      
No. Mobile applications and mobile intermediaries are not permitted to interact with the HI Service as there is no provision for this in the legislation.  

How can my mobile application receive an activation code for consumers trying to access their Active Script List (ASL)? 
The Conformance Profile references a consent message that is sent to a consumer mobile phone or email address. A different authentication code is sent for identity management reasons. Review the ASL technical specifications regarding the authentication code.

Mobile Intermediaries

Can a Mobile Intermediary provide connection services to third party's mobile applications?     
Yes. A Mobile Intermediary may provide connection services to mobile applications developed by third parties.  

What are the obligations of Mobile Intermediary Service (MIS) providers?     
A MIS that provides connection services to mobile applications developed by third parties will need to perform a range of conformance activities. This includes providing all relevant system documentation for integration, providing a test environment, and performing/overseeing integration testing and assessing conformance for the mobile applications that connect to the MIS infrastructure. 

Can a mobile application retrieve and present ASL information to the consumer? 
Mobile applications can access a consumer ASL (if they have one) using a mobile intermediary. Support for this functionality is included in Electronic Prescribing – Connecting Systems Conformance Profile v3.0.1. Refer to the profile for more information about the ASL features.

Transitional eNRMC and Conformance Profile 3.0.1

General Questions

Where can I find information regarding Transitional electronic National Residential Medication Chart (eNRMC) arrangements?      
Information on the Transitional eNRMC process can be found in the Department of Health and Aged Care EMM vendor information pack.  

Can we provide a written explanation or an excerpt from our system specification/manual as evidence of conformance?      
No. Conformance assessment requires evidence of required software behaviour. The submission of design documents and technical specifications is not sufficient.

Healthcare Identifiers (HI) Service and Electronic Prescribing

Do we need to be HI conformant to undergo Transitional eNRMC Conformance process? Can we have conformance for eNRMC assessed after, before, or during HI Service assessment?       
There is no requirement for completing Healthcare Identifier (HI) Service conformance prior to Transitional eNRMC conformance, though it is recommended and considered best practice to have the suite of assessments completed as early as possible. HI service functionality is a pre-requisite for some mandatory requirements (e.g., PRES-70) and HI service testing is required to conform to Electronic Prescribing Conformance Profile v3.0.  

Does Electronic Prescribing require a Clinical Information System (CIS) to validate HPI-O's when constructing/sending a prescription record?      
No. The conformance profile does not include any requirement for the HPI-O to be validated when constructing or sending a prescription record.

eNRMC and Electronic Prescribing

Does conformance to the eNRMC transition remove the need to do Electronic Prescribing – Connecting Systems Conformance Profile v3.0.1 assessment? 
No. Transitional eNRMC conformance requirements are the same as Electronic Prescribing – Connecting Systems Conformance Profile (CP) v3.0.1 requirements and both will use the Conformance Test Specifications (CTS) v3.0.3. However, the Agency cannot assess and approve an EMM product as a CP v3.0.1 conformant eNRMC product until it connects to and is tested against an approved CP v3.1 conformant PDS. Further information is available in the Department of Health and Aged Care EMM vendor information pack.

When a medication chart is ceased and a new med-chart is created, are all the scripts that carry over considered new prescriptions - even if they weren't dispensed?      
Yes. Every item on the old chart is extinguished and new prescriptions are added to the new chart.  

Do items stored at the medication chart level need to be included in each individual prescription sent to the NPDS?      
Yes. Each prescription sent to the NPDS is a single and independent prescription and must contain all the information that is legally required and stated in CP v3.0.1.  

When does medication chart-based electronic prescriptions expire?      
Medication chart-based electronic prescriptions expire when either the medication chart has expired or the prescription item has expired. Further information is available in the Department of Health and Aged Care pharmacy information pack.   

What is a medication chart identifier? Does it require a barcode/QR code?      
Refer to the NPDS for information on medication chart identifiers.  

Is the token the same as Evidence of Prescription (EoP)?
The token is one part of an EoP.  Medication charts must contain tokens with QR or barcodes that can be scanned for dispensing, however, an EoP is a separate document that is often given to the consumer, and it needs to comply with the relevant requirements specified in Electronic Prescribing – Connecting Systems Conformance Profile v3.0.1.  

Electronic Prescribing – Connecting Systems Conformance Profile v3.0.1 requires an EoP to display the number of available repeats. This may not be applicable for medication chart-based electronic prescriptions. Can this part of the EoP be omitted for chart-based medicines? 
Yes. The available repeats option can be omitted as it is out of scope for medication chart-based prescribing. For more information, refer: National Health (Pharmaceutical Benefits) Regulations 2017, sections 51(6) and 52(1). For more information, refer:  National Health (Pharmaceutical Benefits) Regulations 2017, sections 51(6) and 52(1).   

Can Section 100 medicines be prescribed via electronic prescription?     
The eNRMC transitional arrangement does not support electronic prescribing for Section 100 medicines. For more information, refer to the Department of Health and Aged Care EMM vendor information pack.

Does medication-chart software require EoPs for chart-based prescriptions?  
No. Medication-chart software does not need to provide that functionality for chart-based prescriptions.

Useful links

For enquiries and information regarding conformance process, Conformance Profile, Conformance Test Specification:

For general eNRMC information:

Services Australia:

Australian Cyber Security Centre Guidelines for Cryptography

Developer Centre - Electronic Prescribing homepage 

Active Script List podcast:  https://www.digitalhealth.gov.au/newsroom/podcasts/electronic-prescriptions-active-script-list

Conformance Process

You can find the conformance process here: Electronic Prescribing Conformance Process 

Do software developers obtain the Conformance ID for their Development and Test environments?      
The Conformance Assessment Scheme identifies the conformance identifier and the maximum number of characters associated with it. The software developer will need to generate their own Conformance ID which is submitted as part of the Conformance Declaration. The Agency will record the Conformance ID on a published Register of Conformance.  

How long does conformance testing take?      
The observed conformance testing process may typically take  up to 10 business days to complete. During periods of increased demand for observed conformance testing this timeframe may be extended, and advice on expected completion time will be provided when an observed testing booking is confirmed. Upon completion of the observed test session, you may also be requested to provide additional evidence to satisfy the test cases. Contact the NPDS for more information. In order to streamline the process, you’re strongly encouraged to have submitted evidence of passed testing prior to booking your observed testing. This evidence includes the CTS with accompanying evidence such as screenshots. Please include clear references to the evidence to support the review process.  

When submitting test evidence for assessment against Electronic Prescribing – Connecting Systems Conformance Profile v2.3 can we include some test results using requirements from Electronic Prescribing – Connecting Systems Conformance Profile v3.0.1?
We perform assessment for only one Conformance Profile version that you nominate. If there are special circumstances you would like the Agency to consider, please submit a formal request for consideration in an email to [email protected].

The conformance profile contains a range of functionality that is dependent on the state or territory that my product will be used in. How will this be tested?      
All states and / or territories you intend to provide for need to be demonstrated and evidence provided on how your product meets these requirements. Our Conformance Test Specifications indicate those tests which are conditional to the state and/or territory your product will be used in, or which, you intend to make available in. Prior to commencing your observed test session, please indicate to your observed test organisation which state(s) and/or territory(ies) you are intending your product to be available in. If you intend to provide the functionality of more than one state and/or territory, you must be able to demonstrate and provide evidence of how your product will meet those requirements. This may be achieved by executing the test, reconfiguring your system to a different state or territory set up, and executing that test again. Please also include those relevant state and/or territories you demonstrated in your testing (observed test and/or test evidence) on your declaration form when submitted to the Australian Digital Health Agency (e.g. QLD only, QLD and NSW, All, etc).  

If software ceases to be conformant, what is the obligation on the software developer to inform the Agency?      
All software developers must inform the Agency when software becomes non-conformant against the Conformance Profile. The Agency will work with software developers to remediate any issues to ensure their software remains conformant.   

What software changes will require conformance retesting?     
If the change to software does not impact any of the conformance requirements that the software has already satisfied to achieve conformance, then the software is unlikely to require any retesting.   

​Glossary

Active Script List
Active Script Lists support the ability to access electronic prescriptions through an individual’s assertion of identity rather than through presentation of a Token. This overcomes the issue of lost tokens and would assist medication management and adherence for patients who have complex medical needs. It is only relevant in the context of an open Prescription Delivery Service (oPDS) and is not applicable to electronic prescriptions under the direct model of prescription delivery. 

Active Script Lists contain the summary information associated with electronic prescriptions where:

  • The patient has registered for an Active Script List; and
  • The electronic prescriptions are “active” – i.e. not expired, exhausted or cancelled.

​Active Script Lists are an interface only and do not contain electronic prescriptions. Active Script Lists are an interface to the Active Script List Registry. The summary data in an Active Script List includes the identifier for each electronic prescription to enable the retrieval of electronic prescriptions from the open Prescription Delivery Service.

Active Script List Registry     
Active Script Lists are enabled through an Active Script List Registry – the system and services that enables:

  • a patient to register for an Active Script List;
  • prescribing and dispensing systems to add prescriptions and repeat prescriptions to a patient’s Active Script List; and
  • mobile application intermediaries to provide mobile applications to allow patients to view and manage access to their Active Script List.  

Open Prescription Delivery Service (oPDS)
A Prescription Delivery Service that accommodates choice of supply by the subject of care. The National Prescription Delivery Service is an open Prescription Delivery Service. 

Participating System     
A computer system that participates in electronic prescribing. Participating systems include any system which generates an electronic prescription, retrieves and dispenses from an electronic prescription, facilitates the transfer of an electronic prescription or manages an electronic prescription.  

State and Territory Legislation     
The Department of Health and Aged Carehas made the legislative amendments to the National Health (Pharmaceutical Benefits) Regulations recognising an electronic prescription as an alternative legal form by which medicines can be supplied under the PBS. Additional requirements for prescribing and dispensing of medicines under jurisdictional Poisons and Therapeutic Goods Regulations (or equivalent) may vary between states and territories. The electronic prescribing Conformance Profile states that software developers must accommodate the specific regulatory requirements of both the Commonwealth and States and Territories.  

Token     
An electronic prescription token refers to the barcode and associated Delivery Service Provider ID (DSPID). A Token may or may not be provided with other prescription information. The Token itself is not the legal electronic prescription. Repeat authorisations will be handled with a new token being issued to the patient when a repeat prescription is generated.