- Who are the main stakeholders requiring developer support?
- Electronic Prescribing stakeholders that can access support include:
- developers of prescribing systems;
- developers of dispensing systems;
- developers of prescription delivery systems;
- developers of electronic prescription mobile applications;
- developers of mobile intermediaries used by electronic prescription mobile applications; and
- any registered users of the support portal who may access self-service support including but not limited to: peak bodies and government departments.
- Do GP clinics and community pharmacies need to connect to the HI Service?
Software upgrades to accommodate electronic prescribing will make use of your organisation’s HPI-O and authorised health professional’s HPI-I. GP software and community pharmacy software will also need to access the HI service to obtain and validate a patient’s IHI. Relevant Health Identifiers are required to be included in an electronic prescription and are obtained by connecting a GP clinic or community pharmacy to the HI Service. If you do not currently have these identifiers for your organisation contact the Australian Digital Health Agency to discuss how to register for them.
If your prescribing or dispensing software product has not previously been connected to the HI Service, conformance testing will be required. Please visit the following page for more information: https://developer.digitalhealth.gov.au/resources/faqs/hi-scope-use-cases-conformance-and-testing
- Currently being integrated with eRx / MediSecure requires a Medicare Developer Certificate; will early adopters of web-services be impacted?
The integration process with eRx/MediSecure is in line with existing processes. Electronic prescribing will not change these existing requirements. It is recommended you contact eRx/MediSecure directly.
- Is the prescription Token sent to the patient from the Prescribing Software, or, from the Prescription Delivery Service (in the Open model)?
This could be either or both. 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 will provide testing material as part of the software conformance process. Software testing will demonstrate use of the required encryption of the prescription payload between prescribing system and the PDS; between the dispensing system and the PDS; and prescription traffic between PDS providers.
- 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 can be authorised where an additional written approval is required. A number of Government departments are working through how this will be managed in the electronic prescribing world.
- Can a family member collect a prescription on a patient’s behalf; how will this work? As is currently the case with paper prescriptions, a family member or agent may collect a prescription for another person by presenting the evidence of prescription or token to the pharmacy.
- Will electronic prescribing be available to non-PBS registered/approved pharmacies?
The legislative changes at a Commonwealth level only apply to the PBS. States and Territories recognise electronic prescriptions regardless of whether it is a PBS prescription or a private prescription. The software systems used by non-PBS approved pharmacies are generally the same. If electronic prescribing software is used, then the same solution exists.
- Is it possible for a pharmacist to annotate/modify an electronic prescription?
Yes. The solution design allows for a pharmacist to annotate a prescription electronically as part of a dispensing activity to display the annotation and the modification so that any dispensing pharmacist will see the original prescription. The annotation from other pharmacists and details of the last prescription dispensed are also shown.
- Are there any specific considerations for public or private hospital discharge scripts, or the expectation is that we will 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 an open prescription delivery service (oPDS- see Glossary) in the same way as a prescriber would in the community.
The patient can take their prescription tokens to the pharmacy of their choice to have their medicines dispensed when required.
- What Jurisdictional Regulations apply to my product?
Each developer needs to consider the jurisdictions they think their software will operate in and consider the legal obligations for those jurisdictions. Developers are responsible for contacting their relevant state and territory regulation authorities to attain this information (https://developer.digitalhealth.gov.au/topic/electronic-prescribing)
- Where can I find the wording for the Privacy Notice?
The profile makes reference to the “Privacy Notice”. This is managed by Services Australia. The approved wording is available via the Services Australia “Health Systems Developer Portal”. You can access this portal here: https://healthsoftware.humanservices.gov.au/claiming/ext-vnd/
Please note that you must be registered for to portal to access any content within it.
- What should a printed evidence of electronic prescription look like?
The Agency has included an example (printed) evidence of prescription in Appendix A of the conformance profile. This is an example only and developers may implement a design of their own choice if it meets the associated conformance requirements.
- Are there Standard API schema defined by Agency for Open Prescription Delivery Service APIs?
The Agency isn’t developing new standard API schemas. The Agency is developing a Conformance Profile which will mandate some new information which is required to be captured. It will be up to the open Prescription Delivery Service to define their own APIs
What is considered “companion software”?
Companion software is any software that is used to fully or partly satisfy any 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 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.
- PRES-6 What is meant by ‘healthcare organisation’?
The 'healthcare organisation' is the entity that owns and operates the facility in which the prescribing system operates
- 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, i.e. the passwords can be the same.
- 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-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. Prescription delivery services shall support CIS products to include SNOMED CT-AU codeable values.
The relevant SNOMED CT-AU content for Reason for prescribe includes medical problems or diagnoses, procedures, some situations and some events. Relevant SNOMED CT-AU reference sets include the Problem/diagnosis reference set, Procedure foundation reference set and Australian Emergency Department reference set. When a healthcare provider selects a Reason for prescribe description in the Prescribing System, the Prescribing System needs to include the corresponding SNOMED CT-AU code in the electronic prescription and the actual text selected or entered by the healthcare provider must be recorded in the electronic prescription as the "original text".
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’?
The reason for the prescription allows the Department of Health to understand trends in prescribing that will help the Department of Health to better manage the PBS Scheme in the long run.
- 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 the print preview 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 PDS.
The on-screen prescription can look like a paper prescription but does not need to.
- 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-42 Should there be a facility to reprint the paper token in case of paper jam?
Yes. You can print the token as many times as necessary as they all links to the one, legal, prescription. Once the electronic prescription is dispensed, the token is extinguished, and those tokens will not be able to be used to access a prescription.
- How do prescriptions held on file work with electronic prescriptions?
We have been advised there is some instances where the paper script repeat authorisations are not provided to the Subject of Care and are kept ‘on-file’ in the pharmacy. Case examples include Dose Administration Aid supply and Staged Supply arrangements.
A change has been included in the Electronic Prescribing Conformance Profile version 2.2 to clarify how a repeat authorisation may be handled in this scenario. The system should allow the user to not issue an electronic token for the repeat authorisation and allow the user to print a repeat authorisation token for filing instead.
Software developers are advised to check their systems can manage a scripts on-file workflow.
- 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 and the PDS adapter (if relevant). 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 class names are intuitive, logical and obvious in meaning.
- DISP-30 What is the ‘Evidence of Prescription’ and can it be printed/reprinted multiple times if requested/necessary?
The Evidence of Prescription contains a barcode/QR code that enables the CIS to retrieve the legal electronic prescription. It has no legal relevance and 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 dispensing system user does not dispense the dispense record and Cancels the process prior to dispense notice being posted to the PDS; or that the dispensing system user does not dispense the dispense record, which times out as PDS is unavailable. In both cases, Electronic Prescription must then return to its original state and is unlocked. The pharmacy will need to inform the Prescription Delivery Service (via their dispensing software) for the prescription to be unlocked, otherwise the electronic prescription cannot be dispensed at any other pharmacy. This is a requirement of the software as well as the pharmacy itself.
- DISP-36 Does the audit log require a GUI?
There is no requirement to provide a GUI for any audit log. If they can be accessed on request via any tool/back-end process, then that is sufficient.
- DISP-36 What does “all information fields” mean?
All the information that is sent to the PDS needs to be provided in the audit log.
- DISP-38A If the CIS system has extended internet outage will all dispense records need to be reconciled to prescriptions when the PDS 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, rather it will be determined by the regulator at the time based on the nature of the investigation.
You can find the conformance process here: https://developer.digitalhealth.gov.au/resources/articles/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 do I schedule my observed conformance testing?
Please contact your Prescription Delivery Service provider to schedule your observed conformance testing. If you intend on connecting to more than one PDS, please see the FAQs below.
If you’re product is a part of either the MediSecure or FRED IT group, please contact the Agency at [email protected] to schedule your observed testing.
- How long does Conformance Testing take?
The observed conformance test sessions themselves may take several days depending on the availability of your team and the observed testing organisation. Upon completion of the observed test session, you may be requested to provide additional evidence to satisfy the test cases.
In order to streamline the process, you’re strongly encouraged to have submitted evidence of passed testing prior to booking your time. This evidence includes the CTSs with accompanying evidence such as screenshots. Please include clear references to the evidence to support the review process.
- 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 trigger conformance retesting? Are software developers allowed to reuse conformance IDs when making software changes that are unrelated to electronic prescribing?
If the change to software does not impact any of the conformance points that software has already been declared conformant to, then the software does not require any retesting. In terms of using Conformance IDs between versions of software, developers have the discretion as to where they draw the line between old Conformance IDs and new Conformance IDs. If software is taken off the software conformance registry, it will not be able to use electronic prescribing.
- We are looking to schedule our first conformance testing session for the open model, but we would like to connect to both Prescription Delivery Services, what is required?
If you intend to connect to both Prescription Delivery Services in the Open model you will need to:
Undertake all mandatory conformance requirements with one (1) PDS provider
Undertake integration testing and a subset of the mandatory conformance requirements with the other PDS provider. (see list below). You may also contact [email protected] to assist you identify which tests you are required to conduct.
Once you have successfully completed these two steps, please complete the conformance developer declaration form, reflecting that you are connected to both PDSs. This would be indicated by entering each PDS adapter you have integrated in the Software component table, and submit it to [email protected].
- Our product is conformant, currently integrating with one Prescription Delivery Service, we would like to add a connection to another Prescription Delivery Service (i.e. two connections). What is required?
If you have made no significant changes to your software product since becoming conformant, you are required to undertake integration testing and a subset of the mandatory conformance requirements with the other PDS provider. Please contact [email protected] to assist you identify which tests you are required to conduct.
Once you have successfully completed this step, please complete the conformance developer declaration form and submit it to [email protected] clearly outlining the change to your system (connecting to a secondary PDS and, if applicable, a new conformance ID where your product version number has changed) and reflecting that you are connected to both PDSs.
- Our product is conformant, currently integrated with PDS A. We wish to no longer integrate with PDS A, and connect to PDS B. What is required?
If you have made no significant changes to your software product since becoming conformant, you are required to undertake integration testing and a subset of the mandatory conformance requirements with PDS B provider. Please contact [email protected] to assist you identify which tests you are required to conduct.
Once you have successfully completed this step, please complete the conformance developer declaration form and submit it to [email protected] clearly outlining the change to your system (change of integrating PDS and, if applicable, a new conformance ID where your product version number has changed).
- Active Script List
Active Script Lists support the optional 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/dispense notifications 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.
- Direct Prescription Delivery Service
A prescription delivery service that communicates an electronic prescription directly to a nominated dispenser. Such a mechanism is only permitted under circumstances where a choice of dispenser is made before prescription such as during the admission to a residential care or hospital facility.
- Open Prescription Delivery Service (oPDS)
A Prescription Delivery Service that accommodates choice of supply by the subject of care.
An open Prescription Delivery Service may be constructed using a variety of implementation patterns provided they all interoperate. Interoperate means where an electronic prescription sits in one open Prescription Delivery Service, it can be accessed for use by a dispenser who is connected to a different 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 has 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.
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.