Digital health

Electronic prescribing conformance: what to plan before assessment

Plan the integrations, test evidence and release decisions needed for Australian electronic prescribing conformance, with a clear owner for each step.

Electronic prescribing touches every step from prescriber to dispensary, which is why conformance is tested end to end.

Electronic prescribing conformance needs to be part of the product plan from the start. It affects the workflow, external connections, test evidence and conditions for release. Leaving it until the interface is finished can expose decisions that are expensive to change.

For a clinical information system, the Australian Digital Health Agency publishes a process for connecting to the National Prescription Delivery Service or Active Script List Registry. Start with the requirements that apply to the product you are actually building.

Establish the scope and the parties involved

Write down whether the product prescribes, dispenses, supports mobile use or performs another participating role. Confirm which external services it needs and who supplies their specifications and test access. A product supporting an Active Script List may have a different scope from one handling electronic prescriptions alone.

Keep the Agency, the delivery service provider and your own team distinct in the plan. Ask each party to confirm its responsibilities before you promise an assessment or release date. The Agency's CIS guide is the starting reference; use its current documents when planning the work.

ScriptStream's integration model shows identifiers, credentials, external services and recovery within the wider prescribing workflow.

Build an evidence plan alongside the software

The published sequence covers provider access, development, internal tests, submission of the Conformance Test Specification, an observed assessment, a vendor declaration and notification of registration before production deployment. The assessor is normally the NPDS provider; the Agency handles the specified provider-ownership exception.

Turn that sequence into work the delivery team can track. For each applicable requirement, record the implementation, test scenario, result and supporting evidence. Explain why a requirement is not applicable instead of leaving a blank. Keep the product version consistent across the submission and test records.

Capture evidence while testing. Recreating a particular state weeks later can be difficult, especially when it depends on credentials, another service or a sequence of user actions. Someone should own the completeness of the evidence pack as well as the behaviour of the software.

Test the responsibility around each prescription

A successful submission is only part of a usable prescribing workflow. Test who can prepare information, who can approve it, how changes affect an earlier review and what users see when an external response is delayed or rejected.

Include an uncertain outcome: the service may have received a request even though the application did not receive its reply. The recovery process needs to establish what happened before repeating an action that could create a duplicate.

Agree how support staff investigate an issue without giving them unnecessary access to health information. Useful evidence identifies the relevant event, product version and outcome while protecting the details that do not need to be exposed.

Keep other release requirements visible

Electronic prescribing conformance does not replace other applicable obligations. Plan Healthcare Identifiers testing, certificate handling, production access and any relevant state or territory requirements as separate dependencies. Confirm the applicable legal and clinical requirements with the product owner's advisers.

Before release, name the people responsible for customer onboarding, credential setup, incident handling and further product changes. A registration milestone does not by itself demonstrate that every operational dependency is ready.

A ScriptStream prescription preparation screen, with sensitive details redacted. BOP Plus owns the platform; Twin Global developed it.

What the ScriptStream record demonstrates

Twin Global developed ScriptStream for BOP Plus, covering workflow engineering, integrations, conformance support and release preparation. The ADHA register lists Script Stream, BOP Plus Pty Ltd, software version 1.0, as a Prescribing System under profile 3.0.1, registered from 6 November 2025.

That registration date is a specific public milestone. It should not be confused with other testing or development milestones. The platform is in early production, with prescriber onboarding and further development continuing; full PRODA integration remains in progress.

Read the ScriptStream customer story for the delivered scope, or use the workflow lessons to review permissions, status and recovery in your own design.

Discuss your project with Twin Global