27
Electronic Prescribing Solution Architecture and Conformance Overview ADHA Webinar: Friday 13 December 2019 OFFICIAL Ask a question: Go to sli.do Event code #5368

Electronic Prescribing Solution Architecture and

  • Upload
    others

  • View
    5

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Electronic Prescribing Solution Architecture and

Electronic Prescribing Solution Architecture and Conformance Overview

ADHA Webinar: Friday 13 December 2019

OFFICIAL

Ask a question:

Go to sli.do Event code #5368

Page 2: Electronic Prescribing Solution Architecture and

Slido

Throughout the presentation you will be able to ask questions anonymously through Slido.

Please pull up on your phone or browser:

https://www.sli.do/

Event code #5368

Page 3: Electronic Prescribing Solution Architecture and

Digital Health Developer – Document Overview

On our developer site:

There are two download packs for developers:

▪ A welcome pack

▪ Technical Framework

▪ National Requirements

▪ Solution Architecture

▪ Conformance Profile

▪ Conformance Assessment Scheme

https://developer.digitalhealth.gov.au

TechnicalFramework

Welcome Pack

Electronic Prescribing Documents

Page 4: Electronic Prescribing Solution Architecture and

System Components

▪ Prescribing Systems

▪ Dispensing Systems

▪ Prescription Delivery Service

▪ Active Script List Registry

▪ Mobile Intermediary

▪ Mobile Application

Page 5: Electronic Prescribing Solution Architecture and

Delivery Service Overview

Page 6: Electronic Prescribing Solution Architecture and

Open Prescription Delivery Service

▪ An Open PDS is used predominately in community dispensing.

▪ An Open PDS receives electronic prescriptions from the Prescribing software.

▪ Dispensing software can retrieve electronic prescription using a valid token.

▪ Once the medication has been dispensed a dispense record is provided to the PDS so no other dispenses can be made against the prescription.

▪ When Dispensing software queries an Open PDS it can provide the prescription from its own store or from a connected PDS.

▪ Interact with Active Script List Registries to update them with new, cancelled or dispensed prescriptions.

A system that supports defined interfaces and services to facilitate the transfer of electronic prescriptions and related information between participating systems.

Page 7: Electronic Prescribing Solution Architecture and

Direct PDS

▪ Direct PDS model is used in a setting where the dispensing location is known and patient consent has been obtained, e.g. contracted pharmacy for in-patient or aged care settings.

▪ Direct PDS can be a logical concept, where prescribing and dispensing occurs within the same system.

A system that supports defined interfaces and services to facilitate the transfer of electronic prescriptions and related information between participating systems.

Page 8: Electronic Prescribing Solution Architecture and

Prescribing System

▪ Lookup and validate IHI and HPI-I in the HI Service

▪ Register for an Active Script List for a patient

▪ Check if an Active Script List exists for a patient

▪ Retrieve the Active Script List with patient consent from the Active Script List Registry

▪ Send electronic prescription data within structured message to an Open Prescription Delivery Service

▪ Directly or via an Open PDS, send notification with URI to a consumer mobile device, the URI links to a web resource holding the electronic prescription token

▪ Print an electronic prescription token on paper

Clinical Information System software that is used by an authorised prescriber to facilitate the creation of prescriptions.

Page 9: Electronic Prescribing Solution Architecture and

▪ Lookup and validate IHI and HPI-I in the HI Service

▪ Register for an Active Script List for a patient

▪ Check if an Active Script List exists for a patient, retrieve the Active Script List with patient consent from the Active Script List Registry

▪ Retrieve electronic prescription from the Open Prescription Delivery Service

▪ Send electronic dispense data within structured message to an Open Prescription Delivery Service

▪ Send dispense notification to a consumer mobile device

▪ Provide Evidence of Prescriptions for remaining repeats and deferred supply to a consumer

OR Dispense paper prescription

In a Direct Prescription Delivery Service model, the Dispensing System receives an electronic prescription from the Prescribing System, and the lookup and validation of HPI-I is optional.

Dispensing System

Clinical Information System software that is used by an authorised dispenser to facilitate the dispensing of medications and creation of dispense records

Page 10: Electronic Prescribing Solution Architecture and

Active Script List Registry

▪ Only relevant in the context of an Open PDS. A Subject of Care can choose to register for an active script list at a prescribing system location or a dispensing system location, or via a mobile application.

▪ Lookup/validate patient IHI against the HI Service

▪ Allows patient registration from Prescribing and Dispensing Software

▪ Receives requests from Prescribing and Dispensing systems to retrieve current list of active prescriptions

▪ Receives electronic prescriptions data and dispense data from Open PDS

▪ Allows Mobile Intermediaries to register, view and manage the ASL

▪ Subject of Care controlled

▪ Prescription is still stored in the Open Prescription Delivery Service

An Active Script List is an optional for patients that stores tokens for all currentactive scripts.

Page 11: Electronic Prescribing Solution Architecture and

Mobile Intermediary Software which manages communication between the delivery services (i.e. Open Prescription Delivery Services and Active Script List Registry Services) and Mobile Applications.

▪ Provide mobile application user authentication and validation▪ Access prescription information contained in one or more Open PDSs on behalf of

mobile applications▪ Register for or Access the Active Script List on behalf of mobile applications▪ May store electronic prescription tokens on behalf of the Subject of Care

In most cases the mobile intermediary will be the mobile application’s server component.

Page 12: Electronic Prescribing Solution Architecture and

Mobile Applications

A mobile (or web) application allows the Subject of Care (or Agent) to perform a range of tasks including:

▪ View the electronic prescription details▪ Register and view an Active Script List▪ View an audit trail of who has accessed their Active Script List▪ Forward prescription links to online or bricks and mortar pharmacies▪ Create an electronic token for an Active Script List prescription item▪ Hide/unhide prescription items

Page 13: Electronic Prescribing Solution Architecture and

Community Setting

Page 14: Electronic Prescribing Solution Architecture and

Residential Care Settings

Page 15: Electronic Prescribing Solution Architecture and

Hospital

Page 16: Electronic Prescribing Solution Architecture and

Pathway to Electronic Prescribing Conformance

1

6

2

3

5

4

Access the technical framework and welcome pack from the Australian Digital Health Agency’s developer website.

Contact Open Prescription Delivery Service provider(s) to get access to test environments and technical specifications (if applicable).

The Agency will offer a range of support services throughout the above process and operations of electronic prescribing including consultative support and scheduled information sessions.

Identify which conformance points are relevant i.e. Prescribing Systems, Dispensing Systems, Mobile Application, etc. Open PDS or a Direct PDS

Declare the conformance to the Australian Digital Health Agency along with a nominated Conformance ID

Perform observed testing, this will either be observed by the Australian Digital Health Agency or the Open Prescription Delivery Service Provider.

Upon successful completion, the conformance ID is added to the Register of Conformance. This register is communicated by the Agency to the Department of Human Services and PDS providers for operationalisation. Developers are now able to commence deploying electronic prescribing functionality to their users.

Page 17: Electronic Prescribing Solution Architecture and

Conformance ID

▪ When submitting conformance declaration form to the Australian Digital Health Agency the vendor will need to provide a Conformance ID.

▪ Conformance IDs must be no longer than 36 printable characters, which uniquely identify the software product and version.

▪ The Register of Conformance will include a list of all conformant products and their Conformance IDs.

▪ Software not on the Register of Conformance will not be able to interact with Prescription Delivery Services nor make electronic prescribing PBS claims (Existing paper prescription claims will continue to work).

▪ Further information is available in the Conformance Assessment Scheme.

Page 18: Electronic Prescribing Solution Architecture and

Conformance Profile

Covers Conformance Points for:

▪ Prescribing Systems

▪ Dispensing Systems

▪ Prescription Delivery Services

▪ Open Prescription Delivery Services

▪ Direct Prescription Delivery Services

▪ Active Script List Register Systems

▪ Mobile Intermediary Systems

▪ Mobile Application Systems

▪ Authentication and authorisation

▪ Audit▪ User Selection▪ Composition▪ Finalisation▪ Modification▪ Submission▪ Viewing ▪ Retrieval

▪ Presentation ▪ Finalisation ▪ Reconciliation ▪ Connections▪ PDS Connections ▪ Data Integrity ▪ Privacy▪ Security▪ Registration

Page 19: Electronic Prescribing Solution Architecture and

Conformance Profile Extracts – Prescribing Software ▪ PRES-50 -Where the Evidence of Prescription is provided in paper form, the system SHALL provide

a clear indication that it is not to be signed.

Note: Evidence of Prescription must not be misconstrued by a dispenser as a legal prescription.

▪ PRES-41 - Post finalization, where an electronic prescription has been sent to the PDS as an electronic prescription, the system SHALL issue a cancellation for the original prescription and issue a new prescription if a prescriber makes any changes to the prescription.

Note: This supports the existing front end "correction" process, where a prescriber may make alterations and re-issue the prescription to the SoC. The original prescription must be cancelled and

reissued.

Page 20: Electronic Prescribing Solution Architecture and

Conformance Profile Extracts – Dispensing Software

▪ DISP-24 If an item is not dispensed, the system SHALL restore the state of the electronic prescription in the Open PDS.

Note: The electronic prescription is locked in the Open PDS when retrieved by a dispensing system. If the dispense does not proceed, it shall be unlocked.

Page 21: Electronic Prescribing Solution Architecture and

Conformance Profile Extracts – Open Prescription Delivery Services

▪ DS-27 -The system SHALL facilitate the exchange of electronic prescriptions between other conformant open PDS operators.

▪ DS-33 - Where any transaction received by the PDS relates to an electronic prescription linked to a SoC’s Active Script List, the system SHALL pass an encrypted copy of the transaction to the relevant Active Script List Registry.

Note: Other transactions may include dispense records, cancellation of electronic prescriptions or cancellation of dispense records.

▪ DS-11- When a dispensing system retrieves an electronic prescription, the system SHALL lock that electronic prescription while the transaction is in progress to prevent multiple concurrent transactions.

Page 22: Electronic Prescribing Solution Architecture and

Conformance Profile Extracts – Direct Prescription Delivery Services

▪ DS-6A - The system SHALL define and use a DSPID format that will result in organisationally unique and distinguishable prescription identifiers.

▪ DS-27a - The system MAY facilitate the exchange of electronic prescriptions between other conformant PDS operators.

Page 23: Electronic Prescribing Solution Architecture and

Conformance Profile Extracts – Active Scripts List Registry

▪ ASLR-4-The system SHALL have a conformant connection to the Healthcare Identifiers (HI) Service.

Note: The system operator will need to be a Healthcare Provider Organisation or a Contracted Service Provider within the meaning of the Healthcare Identifiers Act.

▪ ASLR-18 - When access to view an Active Script List is requested by a provider that does not currently have access to the ASL, the system SHALL send a direct communication (for example, SMS or email) to the SoC requesting authorisation for the provider. This communication SHALL provide enough information to make it clear to the SoC who the requestor is.

▪ ASLR-32- The system SHALL NOT return details of an electronic prescription that is cancelled or exhausted.

Page 24: Electronic Prescribing Solution Architecture and

Conformance Profile Extracts – Mobile Intermediary System

▪ M1-8- The mobile intermediary SHALL NOT access the encrypted payload of any message without explicit consent.

Note: In this scenario, "consent" may be from the patient in the initial instance. Mobile intermediaries would manage this information and would be subject to use and

disclosure laws applicable federally (Privacy Act 1988) and any applicable laws in their jurisdiction of registration.

Page 25: Electronic Prescribing Solution Architecture and

Conformance Profile Extracts – Mobile Application Systems

▪ MA-9 - For an electronic prescription, the system SHALL render, at minimum:

▪ The DSPID as a barcode/QR code.

Note: Irrespective of what information the mobile application has about the prescription, as a minimum, it shall render (display) the DSPID as a barcode/QR code to be scanned at a dispenser.

▪ MA-11- The system SHALL display all rendered information in "original text", irrespective of the presence or otherwise of coded information fields.

Note: "Original Text" is defined as the text "exactly as presented to the prescriber or dispenser". This ensures that the content is human readable and facilitates consumer access to information.

Page 26: Electronic Prescribing Solution Architecture and

Contact us

1300 901 001

[email protected]

digitalhealth.gov.au

twitter.com/AuDigitalHealth

Help Centre

Website

Twitter

Email

Page 27: Electronic Prescribing Solution Architecture and

Questions