eps prescribing system minimum viable product functional ...€¦ · eps prescribing system –...

Copyright ©2017 Health and Social Care Information Centre of 55 The Health and Social Care Information Centre is a non-departmental body created by statute, also known as NHS Digital.

Document Filename: EPS Prescribing System MVP Functional Specification.docx

Programme Digitising Community Pharmacy and Medicines

Project Electronic Prescription Service

Document Reference

Project Manager Jo Lambe Status Draft

Owner Aled Greenhalgh Version 1.2

Author Aled Greenhalgh Version Issue Date 06/10/2017

EPS Prescribing System – Minimum Viable Product – Functional Requirements

.

EPS Prescribing System – Minimum Viable Product – Functional Requirements v1.2 06 Oct 2017

of 55 Copyright ©2017 Health and Social Care Information Centre

Document Management

Revision History

Version Date Summary of Changes

0.1 02/06/2017 Branched from EPS Prescribing Systems Compliance Specification, split out NFRs & functionality reduced to MVP

0.2 29/06/17 Updated reference to PDS Baseline v3

Reintroduced requirement for toggling Schedule 2&3 CDs and post-dated prescriptions

Removed bulk signing and printer routing requirements

Introduced explicit requirement to be able cancel after an episode has been closed.

1.0 11/08/17 Replaced references to MIM & DMS with ‘message specification’ unless a specific version.

Reduced EPMVP-FR-7 to SHOULD.

Clarified wording in EPMVP-FR-47.

Removed section 6.5.1 as only relevant to repeats.

Requirement trace added to cancellation requirements

Added requirement EPMVP-FR-117 requiring token destruction when prescription rejected

Amended requirement EPMVP-FR-158 to prevent tokens being printed for unsigned EPS prescriptions

Added requirement EPMVP-FR-151.1 mandating page number where token spans several forms

Added requirement EPMVP-FR-162 to ensure information on the token is comprehensive and identical to that in the message

Table 4 – token / xpath crossref: corrected xpaths

Amended EPMVP-FR-90 to refer to new nomination supplementary specification

Amended EPMVP-FR-2 to allow PDS v2 or v3 or ITK PDS mini service

Updated appendices to remove deprecated codes and add information from NHSBSA

1.1 19/09/17 Updated wording of EPMVP-FR-1 to clarify Spine demographics may be read only

Updated EPMVP-FR-91 to require nomination of only community dispenser

Removed EPMVP-FR-92 as DACs not supported in MVP

Amended EPMVP-FR-147 to remove reference to reauthorisation

Removed section 14 and EPMVP-FR-150 to EPMVP-FR-162 removing requirement for printed token

Removing requirement EPMVP-FR-117 removing requirement relating to printed tokens

Added EPMVP-FP-118.1 & EPMVP-FP-118.2 allowing whole-prescription only cancellation



Renumbered first instances of EPMVP-FP-115 & EPMVP-FP-116 to EPMVP-FP-111 & EPMVP-FP-112 respectively avoiding duplicate requirement IDs

1.2 06/10/17 Removed patient-level additionalInformation, removing EPMVP-FR-60, EPMVP-FR-61 & EPMVP-FR-62, EPMVP-FR-64 & section 6.5.1.2

Updated EPMVP-FR-143 text to remove requirement for positioning after medication list and patient info

Updated XML example to remove patientInfo and medication list

Upversioned vocabulary in Appendix B1 & table in Appendix C ‘GP’ to ‘Medical Prescriber’



Reviewers

This document must be reviewed by the following people:

Reviewer name Title / Responsibility Date Version

Adrian Price NHS England Head of IT & Telephony Approved 1.0

Alistair Pickering Domain B Clinical Lead Approved 1.0

Candice Moore DCPM Programme Head Approved 1.0

Jo Lambe DCPM Senior Project Manager Approved 1.2

Kerry Frenz NHSBSA / Clinical Safety Assurance and Engagement Manager

Approved 1.2

Martha Waters DCPM Business Analyst Approved 1.1

Martin Hagan NHSBSA Prescriptions Support, Technology Solutions Approved 1.0

Matt Stibbs Domain B Lead Architect Approved 1.0

Mohammed Hussein

Domain E Clinical Lead Approved 1.2

Oliver Christie NHS Digital Implementation Manager Approved 1.0

Rich Cole DCPM Programme Manager Approved 1.2

Rob Gooch Domain E Lead Architect Approved 1.0

Simon Branton Solution Assurance Functional Assurance Approved 1.2

Approved by

This document must be approved by the following people:

Name Signature Date Version

Mohammed Hussein, Domain E Clinical Lead

Approved 1.2

NHS Digital Technical Design Authority

See: http://enterprisearchitecture.digital.nhs.uk Approved 1.0

Rich Cole, DCPM Programme Manager

Approved 1.0

Rob Gooch, Domain E Lead Architect

Approved 1.0

From: HUSSAIN, Mohammed (NHS DIGITAL) [email protected]

Subject: RE: FOR REVIEW & APPROVAL: EPS Prescribing System MVP - Functional Requirements

Date: 29 August 2017 12:13

To: GREENHALGH, Aled (NHS DIGITAL) [email protected]

Cc: COLE, Rich (NHS DIGITAL) [email protected], FRENZ, Kerry (NHS DIGITAL) [email protected],

WATERS, Martha (NHS DIGITAL) [email protected]

Hi Aled

Thank you for taking the time on Thursday 24th August, to walk me through the spec andthe changes proposed. I agree to the specification with these additional comments as wediscussed:

· The cancellation message could be applied to the whole prescription rather than

individual items on the basis that overwhelming majority of items in urgent care willbe one item prescriptions. This will simplify the messaging needed and will also helpto evaluate if the approach to each item being a prescription has advantages for theworkflow and simplicity for EPS in other care settings too

· The requirement for printing the token at the prescriber end could be removed from

the specification on the basis that most prescribing will be done in situations otherthan a face to face consultation with the patient, and sent to the pharmacy.

· No need to add RHS repeat messages on what will be emergency and acute

prescriptions – again makes the product simpler and cleaner, and no worse than theexisting paper process

· Medicines specific additional information does need to be in scope, and is essential

· DACS and Internet pharmacies not being in scope - I agree with this, but add the

caveat in the future distance selling pharmacies may be able to offer a more rapidresponse (akin to amazon fresh, same day service) at which point we will need toinclude.

Hope this helps. Come back to me if you need anything further Kind regards Mohammed Mohammed(Hussain(FRPharmSSenior(Clinical(Lead,(Domain(EDigital(MedicinesCode4Health(Pharmacy(LeadHealth(Digital(Services

NHS(Digital

8th(floor,(Bridgewater(place,(Water(Lane,(Leeds,(LS11(5DR(Telephone:(07870265897(

Please(note:([email protected](is(the(new(interim(Programme(Head(for(IPaCS(www.digital.nhs.uk@NHSDigitalGeneral(enquiries:

From: Greenhalgh Aled (HEALTH AND SOCIAL CARE INFORMATION CENTRE) [email protected]

Subject: FOR REVIEW & APPROVAL: EPS Prescribing System MVP - Functional Requirements

Date: 11 August 2017 16:31

To: COLE, Rich (NHS DIGITAL) [email protected], GOOCH, Robert (NHS DIGITAL) [email protected],

HUSSAIN, Mohammed (NHS DIGITAL) [email protected]

Cc: Implementation Eps (NHS DIGITAL) [email protected], Matthew Stibbs [email protected],

GOOCH, Robert (NHS DIGITAL) [email protected], HUSSAIN, Mohammed (NHS DIGITAL) [email protected]

, FRENZ, Kerry (NHS BUSINESS SERVICES AUTHORITY) [email protected],

HAGAN, Martin (NHS BUSINESS SERVICES AUTHORITY) [email protected], WHITE, Shaun (NHS DIGITAL)

[email protected], Alastair Pickering [email protected], LAMBE, Joanne (NHS DIGITAL) [email protected]

, MOORE, Candice (NHS DIGITAL) [email protected], BRANTON, Simon (NHS DIGITAL) [email protected],

Oliver Christie [email protected], PIERCE, Rebecca (NHS DIGITAL) [email protected]

Please find attached a version 1.0 of the EPS MVP Functional Requirements for your review and approval **by Wed 23rd Aug** following

your earlier review and comments.

Those in the TO: field please review and indicate your approval; Those in the CC: field please review against your comments as provided

in the attached review log and indicate you’re happy to close the comment.

Please cc all responses to Rebecca Pierce [[email protected]] as I’ll be away on a course until 20th Aug.

Regards,

A.

20170720_Review Log -

EPS Presc…cation.docx

EPS Prescribing System

MVP Funct…cation.docx

!!Aled&GreenhalghTechnical&ArchitectNHS&Digital

t:&0113&397&3294e:&[email protected]

From: GOOCH, Robert (NHS DIGITAL) [email protected]

Subject: RE: FOR REVIEW & APPROVAL: EPS Prescribing System MVP - Functional Requirements

Date: 17 August 2017 10:59

To: GREENHALGH, Aled (NHS DIGITAL) [email protected]

Cc: PIERCE, Rebecca (NHS DIGITAL) [email protected]

Aled, I’ve added a couple of comments and made one change + comment into the master version on OneDrive.Otherwise, pending the stuff around Pathways/Choices API’s it’s an Approved from me. Rob

From: GREENHALGH, Aled (NHS DIGITAL)

Sent: 11 August 2017 16:31

To: COLE, Rich (NHS DIGITAL); GOOCH, Robert (NHS DIGITAL); HUSSAIN, Mohammed (NHS DIGITAL)

Cc: IMPLEMENTATION, Eps (NHS DIGITAL); STIBBS, Matthew (NHS DIGITAL); GOOCH, Robert (NHS

DIGITAL); HUSSAIN, Mohammed (NHS DIGITAL); FRENZ, Kerry (NHS BUSINESS SERVICES AUTHORITY);

HAGAN, Martin (NHS BUSINESS SERVICES AUTHORITY); WHITE, Shaun (NHS DIGITAL); PICKERING,

Alastair (NHS DIGITAL); LAMBE, Joanne (NHS DIGITAL); MOORE, Candice (NHS DIGITAL); BRANTON,

Simon (NHS DIGITAL); CHRISTIE, Oliver (NHS DIGITAL); PIERCE, Rebecca (NHS DIGITAL)

Subject: FOR REVIEW & APPROVAL: EPS Prescribing System MVP - Functional Requirements

Please find attached a version 1.0 of the EPS MVP Functional Requirements for your review and approval **by Wed 23rd Aug** following your earlier review and comments. Those in the TO: field please review and indicate your approval; Those in the CC: field please review against your comments as provided in the attached review log and indicate you’re happy to close the comment. Please cc all responses to Rebecca Pierce [[email protected]] as I’ll be away on a course until 20th Aug. Regards,A.



Glossary of Terms

Term / Abbreviation What it stands for

Acute prescription A “one-off” prescription generated following a consultation between a prescriber and a patient

AHP Allied Healthcare Professional

Advanced Electronic Signature (AES)

An electronic digital signature standard referenced within DH legislation for signing prescriptions

Domain Message Specification (DMS)

The new name for the MIM. Separate versions are now published per domain.

Electronic prescription The information transmitted electronically, with the inclusion of an Advanced Electronic Signature, from a prescriber to Spine to allow dispensing and claiming via ETP

Electronic Prescription Service (EPS)

Electronic Prescription Service delivered by the ETP programme

Electronic Transmission of Prescriptions (ETP)

Electronic Transmission of Prescriptions programme

Prescription token Paper copy of the electronic prescription used to capture the patient’s declaration of charge paid or exemption.

FP10 The paper form that is used to create a paper–based NHS prescription.

Health & Social Care Information Centre (HSCIC)

The Health and Social Care Information Centre is the national data, information and technology organisation for the health and care systems in England.

Health Level 7 (HL7) Organisation responsible for the production and communication of healthcare IT communications standards (http://www.hl7.org.uk)

Medication item Any medicine, appliance or reagent that can be prescribed

Message Implementation Manual (MIM)

Deprecated term - see ‘Domain Message Specification’. A product from the NHS CFH that defines the HL7 messages implemented within the NCRS.

Organisation Data Service (ODS)

The Organisation Data Service (ODS) provided by the Authority. It is responsible for the national policy and standards with regard to organisation and practitioner codes.

NHS Dictionary of Medicines and Devices (dm+d)

Standard for exchange of information on drugs and devices between prescribers, dispensers and reimbursement agencies (http://www.dmd.nhs.uk)

Nomination of dispenser Process by which a patient specifies a dispenser to manage their prescriptions

Patient Medical Record (PMR)

A term used to describe the module/component of the system that holds patient medical records. Some implementers use the term PMR to describe a single patient medication record. Within the EPS documentation the term relates to the entire collection of patient medical records for the GP practice.

Personal administration The prescribing, dispensing and claiming of products listed in the GMS Statement of Financial Entitlements, by a GP practice, which can be directly administered to the patient.

Prescribe The act of authorising medication items on a prescription.

Repeat prescription A prescriber-authorised repetition of a prescription

Repeatable prescription A prescription valid for an authorised number of issues

The System The system seeking compliance as an ETP prescribing system

Universal Unique Identifier (UUID)

An information technology term for a unique identifier, also known as a Globally Unique Identifier (GUID) more specifically a DCE UUID

http://www.hl7.org.uk/

http://www.dmd.nhs.uk/



Document Control:

The controlled copy of this document is maintained in the Authority’s corporate network. Any copies of this document held outside of that area, in whatever format (e.g. paper, email attachment), are considered to have passed out of control and should be checked for currency and validity.

Further Requirements:

CDT D0002 Spine External Interface Specification

NPFIT-ETP-ECAP-0004 NHS Dictionary of Medicines and Devices Compliance Requirement

NPFIT-FNT-TO-IG-0007 National RBAC Database

EPS Supplementary Specification: Nomination

NPFIT-FNT-TO-DSD-0083 Native use of dm+d Definition

Message Implementation Manual v4.2.00

NPFIT-ETP-EDB-0027 EPS Prescription Token Specification

NPFIT-ETP-EDB-0064 ETP Message Signing Requirements

NPFIT-FNT-TO-IG-0019 Digital Signature and Non Repudiation

NPFIT-FNT-TO-TIN-0453 CC API for ETP suppliers

NPFIT-FNT-TO-TIN-1383 IG v3 Foundation Module

NPFIT-FNT-TO-TIN-1023 PDS Compliance Module V2 - Baseline Index

NPFIT-FNT-TO-TIN-1023 PDS Compliance Module V3 - Baseline Index

NPFIT-ELIBR-AREL-DST- 0408.04 ITK Spine Mini Services Client Requirements

NHSBSA Overprint Specification for NHS Prescriptions

NPFIT-ETP-EIM-0015 Guidance for Endorsement

EPS Prescribing System MVP Non Functional Specification

NPFIT-ETP-EDB-0278.03 EPS Infrastructure Specification

Related Guidance Documents:

NPFIT-ETP-EDB-0025 EPS Prescribing Systems Compliance Specification v6.10

NPFIT-ETP-EIM-0110 RBAC Implementation Guidance for the EPS R2

NPFIT-ETP-ECAP-0002 Electronic Prescription Service Release 2 Clinical Assurance

dm+d Implementation Guide (Primary Care)

NPFIT-ETP-EDB-0104 Digital Signature Toolkit Guidance

NPFIT-FNT-TO-DSD-0083 Native use of dm+d Definition



Contents

1 About this Document 10

1.1 Purpose 10

1.2 Audience 10

1.3 Content 10

2 Background 10

3 Scope 11

3.1 EPS Functional Scope 11

3.2 MVP Functional Scope 11

3.3 EPS National Model 13

4 Patient Demographics 13

4.1 Synchronisation of PDS Attributes 13

4.2 Demographics restrictions to Prescribing 14

5 Electronic Prescription Generation 15

6 Prescription Attributes 16

6.1 Electronic Acute Prescribing 17

6.2 Medication Items 17

6.3 Prescription IDs 18

6.4 Population of Clinician and Patient Details 20

6.5 Supplementary Messaging Requirements 28

7 Medication Management 29

8 Prescription Nomination 33

8.1 Dispensing Contractors and Nomination 34

9 Electronic Signature 35

10 Prescription Acknowledgements & Errors 36

10.1 Application Acknowledgements 36

10.2 Prescription Rejections 36

11 Prescription Cancellation 37

11.1 Update Semantics 37

11.2 Prescription Cancellation 38



12 Messaging 42

13 Controlled Drugs 44

14 Section removed 46

15 Reporting and Information Requirements 46

15.1 Electronic Prescriptions Report 46

15.2 Prescription Workflow/Status Visibility 46

Appendix A: Messaging Vocabularies Maintained Outside the Messaging

Specification 49

B1: PrescriptionType 49

B2: PrescriberEndorsement 50

Appendix B: Prescriber Codes 51

Medical Prescriber Codes 51

Spurious codes 52

Non-Medical Prescriber Codes 52

Pooled list codes 52

Code Formats 53

Appendix C: Cross reference of “Prescription Type” code and prescriber codes 54

Appendix D: Cross reference of EPS “Prescription Type” code and FP10 “Paper Type” and Prescriber Initiative 54



1 About this Document

1.1 Purpose This document details the functional requirements that must be fulfilled in order to achieve an MVP for prescribing using EPS

Some aspects of the business processes and implementation will require agreement with the relevant professional and/or representative bodies and local implementation detail may vary between organisations, in particular identifying those processes which are optional and mandatory. The system will be expected to support the documented business process whether they are optional or mandatory.

Further, in the main this document only details pertaining directly to EPS. It is recognised some wider system reconfiguration may be required to support EPS processes. This will be outside of the scope of EPS compliance and will not be tested.

This document specifies the functionality required to support the EPS for prescribing systems in England prescribing within the NHS.

It is recognised that some prescribing systems may be combined with dispensing systems. All such systems must additionally adhere to the requirements defined within the “Dispensing Systems Compliance Specification” (ref: NPFIT-ETP-EDB-0024).

1.2 Audience This document has been written for implementers.

1.3 Content Within this document, system requirements are explicitly listed within tables. Additional documentation, guidance and illustrations are contained within each document section to support the understanding of the requirements.

A requirement trace back to the main EPS Prescribing System Specification is included, and is marked with an asterisk where the requirement differs substantively from the source.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Drafting notes and areas for further review and confirmation are highlighted.

A requirements trace back to the EPS Prescribing System Specification is included. Where requirement differs from the original this is noted with an asterisk.

2 Background

EPS has to date been used solely in primary care, in particular to transfer prescriptions from a patient’s GP to a nominated dispenser. The intent of this requirement set is to broaden the scope of implementation by reducing and



simplifying the functionality, making compliance relatively simpler to achieve by providing functionality necessary for other care settings. These settings include AHP outpatient clinics, limited formulary prescribers and urgent care.

3 Scope

3.1 EPS Functional Scope EPS starts at the point where a decision to prescribe has been taken and ends when medication is dispensed and reimbursed by a dispensing contractor in the community setting (or prescription is cancelled, expires etc.).

EPS covers all prescribing and dispensing (including repeat dispensing) and supply of medicines, drugs, appliances and chemical reagents by NHS dispensing contractors. Also within scope are secondary care prescriptions issued for dispensing in the community.

This specification is applicable to all NHS independent and supplementary prescribers. Refer to the DH publication “Medicine Matters”, dated July 2006, Gateway Ref 6773, for the definition of independent and supplementary prescribers.

The EPS can be used for any patient with a known and valid NHS number.

The following are explicitly out of scope for EPS.

• Bulk prescriptions

• Prescribing of non dm+d medication items

• Handwritten medication items or amendments on prescription tokens that relate to electronically signed prescriptions

• Automated non-age exemption verification

• Schedule 1 controlled drugs

• Prescribing of extemporaneous preparations not already defined within dm+d

• Personal administration

• Private prescriptions

• Dispensing outside of England

• FP 10 REC

3.2 MVP Functional Scope The scope of the functionality described in this document is further constrained by removing the following EPS functionality:

• Repeat Dispensing prescriptions

• Repeat Prescribing prescriptions

• Delayed prescribing

• Routine prescriptions

• Nomination update

• EPS Release 1

• Patient consent flags

• Non nominated prescriptions

• EPS implementation phase modes

• Post-dated prescriptions



• DMS 3.3.0 prescription messaging

• Repeat lists

• Cancellation on deduction

• Personal Administration

• Protocol supply

• Bulk signing

• Medication list & patient-level information, as normally printed on right-hand side of the token.



3.3 EPS National Model The high level technical architecture for the EPS is shown in Figure 1 below.

Figure 1 - EPS Technical Architecture

4 Patient Demographics

The EPS is available to any patient with a known and valid NHS Number obtained from the PDS and whose record is not flagged within PDS with a confidentiality code of “sensitive” or flagged as deceased.

Patient demographics may be sourced either from a fully PDS compliant system as defined in the document “PDS Compliance Module V2 - Baseline Index” (ref: NPFIT-FNT-TO-TIN-1023). Alternatively demographics can be sourced from a PDS Mini Service on an ITK accredited system.

4.1 Synchronisation of PDS Attributes For integration with the EPS, a minimum set of patient demographic attributes must be synchronised between the local system and the Spine PDS. These attributes are as follows;

• NHS Number



• Usual name

• Usual address

• Date of birth

• Gender

• Nominated dispenser (if available)

4.2 Demographics restrictions to Prescribing The following prescribing scenarios are not permitted when using the EPS. If a prescription is required in these scenarios, a paper FP10 prescription must be used.

Data retrieved from Spine demographics and local systems may not meet data format requirements for EPS and must not be permitted to be included in messaging, ensuring that only schema-compliant data is submitted to Spine. Common examples include non-numeric characters in phone numbers.

4.2.1 Prescribing for Dead Patients

The System must prevent the creation of prescriptions for dead patients. The System must prevent this based upon the data from PDS or locally: The ‘deceasedTime’ attribute within the patient’s PDS record holds details of time of death. This requirement applies to both the death status flags within PDS of ‘formally’ and ‘informally’ dead.

In addition, an internal trigger from Spine Demographics will inform the Spine Prescriptions system that a patient has died. On receipt Spine Prescriptions will cancel all outstanding prescriptions for that patient on Spine.

4.2.2 Prescribing for ‘Sensitive’ Patients

The System must ensure that an electronic prescription cannot be authorised for a patient whose demographic record within Spine PDS is flagged as ‘sensitive’. A demographic record that is sensitive will be identified with a ‘confidentialityCode’ attribute of “S”.

Ref Requirement Req Trace

EPMVP-FR-1

The System must allow EPS to be used to prescribe for patients with a local demographic record matched with PDS

Nil




EPMVP-FR-2

The system must implement PDS synchronisation as described either in:

“PDS Compliance Module V3 - Baseline Index” (ref: NPFIT-FNT-TO-TIN-1188)

OR

ITK PDS Spine Mini Service bundle as described in the document ITK Spine Mini Services Client Requirements (NPFIT-ELIBR-AREL-DST- 0408.04)

OR

“PDS Compliance Module V2 - Baseline Index” (ref: NPFIT-FNT-TO-TIN-1188)

EPMVP-FR-3

The System must synchronise at least the following attributes from the PDS with the local demographic record.

• Usual name

• Usual address

• Date of birth

• Gender

5.2.10

EPMVP-FR-4

The System must not automatically synchronise PDS telecom details, including ‘use’ attributes.

5.2.12

EPMVP-FR-5

The System must prevent an electronic prescription for a patient who is recorded as deceased from being signed.

6.10.1

EPMVP-FR-6

The System must prevent an electronic prescription for a patient whose demographic record within Spine PDS is flagged as ‘sensitive’ from being signed.

6.10.2

EPMVP-FR-7

Systems should notify the user where an incomplete date of birth exists on the currently selected patient’s demographic record, so that an actual date of birth can be updated on PDS and used on the prescription.

6.2.16

5 Electronic Prescription Generation

An electronic prescription is implemented using the HL7 message “Parent Prescription” defined in the MIM.



This section details some of the specific requirements relating to the generation of the HL7 “Parent Prescription” message. Refer to the message specification for the complete message definition.

The purpose of the “Parent Prescription” message is to convey the necessary patient and clinical information between the prescriber, the Spine, the dispenser and the NHSBSA.

There may be the need, in extreme case, to temporarily disable EPS prescription generation at a prescribing site, most likely as a result of implementation issues. Under such circumstances all prescriptions must be FP10 paper prescriptions with no printed barcode and no parallel HL7 prescription message.


EPMVP-FR-10

The System must implement the Parent Prescription PORX_IN020101UK31 interaction.

6.8.1*

6.2.1

EPMVP-FR-11

Systems must allow the user to generate a paper-based hand-signed FP10 prescription instead of an electronic prescription.

6.7.7

EPMVP-FR-12

The System must be able to disable EPS functionality resulting in all prescriptions being generated as FP10 paper prescriptions with no printed barcode and no EPS Spine messaging sent.

6.3.5

EPMVP-FR-13

The electronic prescribing module of the System must pass all signed EPS prescriptions immediately to the Message Handler Service (MHS) module.

6.8.4

6 Prescription Attributes

The diagram below shows the business view of an electronic prescription.



The simplest form of electronic prescription is the acute Prescription Treatment Type, which does not use all of the attributes shown above.

6.1 Electronic Acute Prescribing An acute prescription is generated following a consultation between a prescriber and a patient and is a “one-off” prescription. An electronic “Parent Prescription” message is created by the System and sent to the Prescriptions sub-system within Spine, to be made available for “pull-down” by a dispenser.

Spine will respond with either an acceptance or a rejection message. Details of the reason for rejection will be contained within the message. After successful receipt of the prescription by Spine it is immediately available to be requested by a dispenser.

6.2 Medication Items

6.2.1 Medication Number Restrictions

The electronic prescription must detail all prescribed medication items that are to be dispensed using the EPS. Unlike a paper prescription where physical paper size limitations mean that the maximum number of prescribed items is limited to the size of the FP10 stationery (typically 4 items per prescription), an electronic prescription can, in theory, contain an unlimited number of medication items. Currently the maximum number of items on a single electronic prescription will remain limited to 4 but this position may be revisited in the future. An electronic prescription must contain at least one medication item.

EPMVP-FR-21

The System must ensure that all electronic prescriptions include at least one medication item.

6.4.2



EPMVP-FR-22

The System must not allow more than 4 items in a single electronic prescription message.

6.4.3

6.2.2 Splitting Items across Electronic and FP10 Prescriptions

Not all medication can be prescribed via the EPS, for example, where a mapping from a proprietary drug database to the dm+d does not exist. In such cases the default position is to prescribe medication not prescribable via the EPS on a separate FP10, thus splitting the medication across electronic and FP10 prescriptions.

However it is permissible in this scenario, at the choice of either the prescriber or patient, to prescribe all medication items on an FP10 prescription.

Out of scope types of medication item for the EPS are listed in Section 3.

EPMVP-FR-25

Systems CAN by default allow medication items selected by the prescriber which are unable to be included on an electronic prescription to be prescribed on a separate hand-signed FP10 prescription, with any remaining items included on an electronic prescription.

6.4.14

EPMVP-FR-26

Systems SHALL allow all items to be prescribed on a separate hand-signed FP10 prescription where some medication items selected by the prescriber are unable to be included on an electronic prescription

6.4.14

6.2.3 Prescriber Endorsements

Some items require endorsement by the prescriber for the dispenser to be reimbursed correctly. These endorsements would be marked next to the item on a paper prescription. There is no endorsement code for ‘no endorsement’ as there is in dispensing endorsements, so items will no prescriber endorsement will not include the pertinentPrescriberEndorsement element in the message.

EPMVP-FR-30

The System must permit the prescribing endorsements in the Prescribing Endorsements vocabulary (OID: 2.16.840.1.113883.2.1.3.2.4.16.32) Version: 3.0 to be applied to prescription items.

6.4.4

6.3 Prescription IDs Each prescription and medication item within a prescription is uniquely identified by a locally generated Universal Unique Identifier (UUID).

6.3.1 Short Form Prescription Identifier

The purpose of the Short Form Prescription ID is to identify the prescription during its lifecycle within the Spine. The prescription UUID must be included as the first identifier within the prescription message.

The format of the Short Form Prescription ID is as follows;



<RandomNumber>-<PracticeODSCode>-<PracticeSequence><CheckDigit>

Where;

<RandomNumber> is a locally generated random number each time a Prescription ID is generated of length 6 hexadecimal characters.

<PrescribingOrgODSCode> is the unique ODS code for the prescribing organisation as defined within the Spine SDS of length 6 characters. Where the prescriber ODS code is shorter than 6 characters it must be zero-padded up to six characters from the start of the ODS code.

<PrescribingOrgSequence> is an incremental sequence number starting from 00000 that is reset after FFFFF back to zero of length 5 hexadecimal characters. For systems that support multiple practices, a sequence number per practice is required. This is to ensure uniqueness of prescriptions within the Spine EPS component during the prescription lifecycle.

<CheckDigit> is calculated on the entire ID using the ISO/IEC 7064:2003 MOD 37-2 standard.

Note. Hyphens are always included to separate the ID into 3 blocks of 6 characters, but are ignored in checkdigit generation.

Note. The implementation of the MOD 37-2 standard uses a “+” character for char 36 as opposed to a “*” character.

Short Form Prescription ID example (for illustration purposes only);

83C40E-A23856-00123W

6.3.2 Universal Unique Identifiers (UUIDs)

When UUIDs are used within HL7 messages they must be represented in an upper case human-readable hexadecimal format where hyphen separators are used as per the example below and as defined by the ‘datatype’ schema within the message specification.

UUID example:

<id root="C6ACA227-398E-47BC-8881-9A8BC763FC1C"/>

Ref Requirement

EPMVP-FR-35

Systems must represent the Short Form Prescription ID in upper case characters.

6.6.2

EPMVP-FR-36

Systems must include the hyphen characters in the Short Form Prescription ID HL7 messages, on screen, when printed and when represented as a machine readable barcode.

6.6.5

EPMVP-FR-37

Systems supporting multiple prescribing organisation must use separate incremental number for each practice to populate the <PrescribingOrgSequence> part of the Short Form Prescription ID.

6.6.3



Ref Requirement

EPMVP-FR-38

The System must provide a prescription search facility to locate prescriptions by Prescription ID from historic prescription records and prescriptions awaiting electronic signing.

6.6.7

EPMVP-FR-39

The system must Prescription ID must make Short Form Prescription ID visible to the user and capable of being copied to the operating system clipboard.

6.6.7

6.4 Population of Clinician and Patient Details EPS messaging makes used of HL7 CMETs which are message components common to several messages. From an XML schema and modelling perspective, a CMET schema is loose; each must support the lowest common denominator of use. For example when referring to a patient in care settings outside the EPS, the minimum data requirement is just the patient’s NHS Number. Hence within the CMET “R_Patient” the only mandatory attribute is “id” that holds the NHS Number.

Guidance is provided for the following CMETs and common data types within a CMET.

• R_Patient

• R_AgentNPFITPerson

• R_AgentNPFITOrgSDS

• Person Name data type

• Postal Address data type

• Telecommuncations Address data type

• Physical Quantity data type

• Implementation of SET data types

6.4.1.1 R_Patient

The “R_Patient” CMET contains data related to a single patient.



Figure 2 - R_Patient CMET

Additional EPS requirements beyond those defined in the messaging specification are as follows;

The required fields in addition to mandatory fields are;

• patient.addr

• person.name

• person.administrativeGenderCode

• person.birthTime

The ‘person.birthTime’ must be in the format YYYYMMDD. There may be scenarios when a patient’s date of birth is recorded within Spine Demographics as an incomplete date, for example, as a year and a month (YYYYMM), or as just a year (YYYY). The prescriber should be notified when an incomplete date has been returned so that an actual date of birth can be updated and used on a prescription. If an actual or estimated date or birth cannot be determined by the prescriber then the 1st day and/or the 1st month of the year must be used when populating the “R_Patient” CMET.

The ‘HealthCareProvider.id’ must be the ODS code for the patient’s registered GP practice. In the scenario where a patient is not registered with a GP practice, or when he patient’s registration details are not known, the ‘id’ element can be populated with nullFlavor, i.e. <id nullFlavor="NA"/>.



6.4.1.2 R_AgentNPFITPerson

The “R_AgentNPFITPerson” CMET is used when recording details of Spine user who is acting as the author or responsible party. This CMET supports two variants of such details; PersonSDS / OrganisationSDS and Person / Organisation. The SDS variants only capture the ID of the person or organisation. The details could be queried from the SDS. However for legal reasons, additional information such as name and address must be contained within a prescription.

Therefore in all cases, the non-SDS variant within this CMET must be used (e.g. “Organization” and “Person”, and not “OrganizationSDS” or “PersonSDS”).

Figure 3 – R_AgentNPFITPerson CMET

The population of this CMET is defined within the messaging specification within the tabular views. Business rules for data population are defined in this specification to account for different prescribing processes.

Population of “author”

The Author CMET must contain the personal and organisational details of the user who has electronically signed the prescription.

author

Required Fields

author

Population Rules

AgentPerson.id The prescriber’s SDS Role Profile ID.

AgentPerson.code The prescriber’s SDS job role code (returned in the SAML assertion following successful end-user authentication) for example “R8003”.

AgentPerson.telecom A valid telephone number for the prescriber. Where a specific telephone number is not available use the same telephone number as provided within the ‘AgentPerson.Organization’ entity.



author

Required Fields

author

Population Rules

AgentPerson.Person.name The name of the prescriber identified by the ‘AgentPerson.Person.id’ field.

AgentPerson.Person.id The professional code of the prescriber.

This will be the GMC for GPs, the NMC for nurse prescribers or the GPhC for pharmacist prescribers.

The OID must be 1.2.826.0.1285.0.2.1.54

AgentPerson.Organization.id The ODS code for the prescriber’s organisation.

The OID must be 1.2.826.0.1285.0.1.10

AgentPerson.Organization. code

The organization type from the pre-defined vocabulary within the messaging specification.

The vocabulary does not include all NHS organisation types. Until further notice, where an appropriate code for the prescribing organisation does not exist in the vocabulary used the code “999” = “Not Specified”.

AgentPerson.Organization. name

The name of the organisation.

AgentPerson.Organization. telecom

A valid telephone number for the organisation.

AgentPerson.Organization. addr

The postal address of the organisation.

AgentPerson.Organization. healthCareProviderLicense. Organization.id

The ODS code for the commissioning organisation for the prescriber’s organisation.

The OID must be 1.2.826.0.1285.0.1.10.

In most cases this with be the ODS code of the Clinical Commissioning Group (CCG).

AgentPerson.Organization. healthCareProviderLicense. Organization.name

The name of the commissioning organisation for the prescriber’s organisation.

In most cases this with be the name of the Clinical Commissioning Group (CCG).

Population of “responsibleParty”

The population of the ‘responsibleParty’ entity is equivalant to the details that would be printed at the bottom of an FP10.

responsibleParty

Required Fields

responsibleParty

Population Rules



responsibleParty

Required Fields

responsibleParty

Population Rules

AgentPerson.id Where the “AgentPerson.Person.id” prescribing code relates to a clinician then use their SDS Role Profile ID.

Where the “AgentPerson.Person.id” prescribing code relates to a service this field must be omitted as smartcards are not issued to services.

AgentPerson.code Where the “AgentPerson.Person.id” prescribing code relates to a clinician then use their the SDS job role code (returned in the SAML assertion following successful end-user authentication) for example “R8003”.

Where the “AgentPerson.Person.id” prescribing code relates to a service this field must be omitted as smartcards are not issued to services.

AgentPerson.telecom A valid telephone number for the prescribing clinician or cost centre. Where a specific telephone number is not available use the same telephone number as provided within the ‘AgentPerson.Organization’ entity.

AgentPerson.Person.name The name of the prescribing/cost centre clinician or organisation as identified by the ‘AgentPerson.Person.id’ field.

AgentPerson.Person.id The prescribing code issued by the NHSBSA.

The system must be capable of populating all medical and non-medical prescriber codes required by the NHSBSA in the correct format1

The OID must be 1.2.826.0.1285.0.2.1.54

Examples include;

Prescriber Code

Medic (e.g. any type of GP)

Doctor’s Index Number (DIN) or spurious code2

Nurse NMC

Pharmacist GPhC

See Appendix B.

1 See NHSBSA website and FP10 Overprint Specification for further details on the format of Prescriber codes and Appendix D.

2 See Appendix C for the definition of a ‘spurious code’.



responsibleParty

Required Fields

responsibleParty

Population Rules

AgentPerson.Organization.id The ODS code for the clinically responsible organisation.

The OID must be 1.2.826.0.1285.0.1.10

AgentPerson.Organization. code

The organization type from the pre-defined vocabulary within the messaging specification.

The vocabulary does not include all NHS organisation types. Until further notice, where an appropriate code for the prescribing organisation does not exist in the vocabulary used the code “999” = “Not Specified”.

AgentPerson.Organization. name

The name of the organisation.

AgentPerson.Organization. telecom

A valid telephone number for the organisation.

AgentPerson.Organization. addr

The postal address of the organisation.

AgentPerson.Organization. healthCareProviderLicense. Organization.id

The ODS code for the commissioning organisation for the clinically responsible organisation.

The OID must be 1.2.826.0.1285.0.1.10.

In most cases this with be the ODS code of the Clinical Commissioning Group (CCG).

AgentPerson.Organization. healthCareProviderLicense. Organization.name

The name of the commissioning organisation for the clinically responsible organisation.

In most cases this with be the name of the Clinical Commissioning Group (CCG).

6.4.1.3 R_AgentNPFITOrgSDS

This CMET is used to capture the patient’s nominated dispensing site.

Figure 4 - R_AgentNPFITOrgSDS CMET



The only required attribute is the OrganizationSDS ‘id’ containing the ODS code of the dispensing site and the OID 1.2.826.0.1285.0.1.10

6.4.1.4 Person Name (PN)

Within HL7 a name can be represented by either a structured or unstructured name format. Within the EPS domain, there are two implementations of this data type; for a patient name and for a registered Spine user name.

Patient Name

Patient names must always be formatted using the “Person name structured” flavour. This CMET supports multiple names however for the EPS only a single name must be populatedThe HL7 elements of “use” and “valid time” can be ignored.

Registered Spine User Name

The name of the registered Spine user may be formatted using either the “Person name structured” or “Person name unstructured” flavours. Two flavours are required because the Spine SDS, the repository for registered users, only mandates “full name” and “family name” attributes. Thus if the other optional attributes of a name are not populated, a structured name cannot be formed. Where possible, structured names must be used when data is available from Spine SDS and unstructured names used only when just the “full name” and “family name” exist. The HL7 elements of “use” and “valid time” can be ignored.

6.4.1.5 Postal Address (AD)

All postal addresses must use the “Unstructured address plus postal code” flavour. The minimum dataset as defined by the Spine PDS is the population of address lines 1, 2 and 4, therefore some elements of the flavour may be blank, but not omitted.

Multiple addresses are supported by the HL7 messages however for the EPS, only a single address is required

For all addresses, if additional HL7 elements such as “use” and “valid time” are included, these can be ignored.

6.4.1.6 Telecommunication Address (TEL)

All flavours of the “Telecommunication address” data type must be supported for the EPS so that the user has access to all known means to contact the patient or clinician. Suppliers can choose how they present telecommunications numbers when the “use” attribute and/or “useable period” elements are populated.

Note. A blank telephone number, e.g. value=”tel:” is not HL7 schema valid.

6.4.1.7 Physical Quantity (PQ)

When representing the quantity of a medication item, the Physical Quantity data type must be formatted using the “Quantity in Alternative Units” flavour when using a dm+d unit of measure. See Section 7 for more information.

6.4.1.8 Implementation of SET data types

The CMETs “R_Patient” and “R_AgentNPFITPerson” convey personal demographic information relating to the patient and clinicians for the prescription. Within these



CMET structures some data attributes can be recorded in “sets”, thus recording multiple values for the same data item. This specifically relates to the following demographic data;

• Name e.g. “name (SET<PN>)”

• Address e.g. “addr (SET<AD>)”

• Telecommunication address e.g. “telecom (SET<TEL>)”

The legal requirement for such patient demographics on a prescription is a single patient name and address, therefore the System must populate the HL7 message with a single patient name and a single patient address.

The Spine PDS supports multiple patient names and addresses. Refer to PDS guidance documentation for handling multiple patient demographic data, but note that in most circumstances, the patient name marked within PDS as the “Usual (current) name” and the patient address marked as the “Usual address” will be relevant for use when creating a prescription.

All available, and valid for the current date/time, patient telecommunication addresses recorded within the Spine PDS must be recorded within the prescription.

6.4.2 Data Types

EPMVP-FR-40

Systems shall use the PQ “Quantity in Alternative Units” data type flavour when representing the quantity of a medication item with a dm+d unit of measure.

6.6.20

6.5.5

EPMVP-FR-41

Systems shall format postal addresses using the AD “Unstructured address plus postal code” HL7 flavour.

6.2.18

EPMVP-FR-42

Systems shall support all flavours of the Telecommunication Address (TEL) datatype defined within the messaging specification.

6.2.19

EPMVP-FR-43

Systems shall support all ODS and prescriber code formats without truncation

6.2.25

6.4.3 Patient

EPMVP-FR-45

Systems shall provide the ODS code of the patient’s GP practice by populating the id element within healthcareprovider class within the R_Patient CMET, or must use a nullFlavor where this is not available.

6.2.23

EPMVP-FR-46

Systems must populate patient date of birth in the format YYYYMMDD

6.2.16



EPMVP-FR-47

Systems must notify the user and use the first of the month or the first of January where the day or month respectively of patient date of birth used in a prescription is an estimate.

6.2.16

EPMVP-FR-48

Systems must provide a structured patient name for patients by using the PN “Person name structured” data type flavour within the R_Patient CMET

6.2.13

EPMVP-FR-49

Systems must provide a single patient name and address 6.2.14

EPMVP-FR-50

The System must provide all telecommunication addresses recorded on the patient demographic record that are valid for the current date/time

6.2.15

EPMVP-FR-51

Systems must provide the patient’s gender by populating the person.administrativeGenderCode within the R_Patient CMET

Nil

6.4.4 Author & Responsible Party

EPMVP-FR-55

Systems shall format the name of registered Spine user using either the PN “Person name structured” or the PN “Person name unstructured” data type flavours within the R_AgentNPFITPerson CMET

6.2.17

EPMVP-FR-56

Systems must include all person and organisation details for author and responsibleParty by using the non-SDS variants (“Person” and “Organisation”) of the classes in the R_AgentNPFITPerson CMET.

6.2.7

EPMVP-FR-57

The “R_AgentNPFITPerson” CMET must be populated as per the business rules within this specification when defining the ‘author’ of a prescription.

6.2.8

EPMVP-FR-58

The “R_AgentNPFITPerson” CMET must be populated as per the business rules within this specification when defining the ‘responsibleParty’ of a prescription.

6.2.9

6.5 Supplementary Messaging Requirements The following sub sections provide supplementary requirements for messaging which add to those requirements defined within the messaging specification.

6.5.1 Entity: AdditionalInstructions

For EPS Release 2 the ‘AdditionalInstructions’ entity has two purposes.



6.5.1.1 Additional Medication Specific Clinical Information

Clinical information relating to a prescribed medication item that cannot be conveyed within dosage instructions is populated within the ‘AdditionalInstructions’ entity.

Figure 5 - Additional Instructions

Examples of additional instructions are;

• For certain drugs which require monitoring, such as Lithium or Amiodarone, additional instructions to inform patients how often they need to have a blood test or a review check-up.

• To explain changes in dosage, for example, “Dosage has been increased on advice of a specialist”.

Additional clinical information is formatted as plain text within the ‘value’ attribute.

6.5.1.2 Section removed

{Section removed}

6.5.2 Entity: PrescriptionType

The vocabulary for the ‘PrescriptionType’ vocabulary is defined within Appendix A of this document.

The System must populate the ‘PrescriptionType’ attribute for the appropriate combination of prescriber and care setting.


EPMVP-FR-63

The System must use the PrescriptionType vocabulary defined within this specification.

6.9.7

7 Medication Management

The ETP programme is dependent on a standard for exchange of information on drugs and devices between prescribers, dispensers and reimbursement agencies.

The NHS Dictionary of Medicines and Devices (dm+d, ref: http://www.dmd.nhs.uk) is the NHS standard for drug and device identification. It provides a stable, unique term (description) and identifier (code) for all drugs and devices used in the treatment of patients. It enables clinical system interoperability by ensuring safe and reliable exchange of information on drugs and devices. The dm+d uses the SNOMED coding scheme (ref: http://www.snomed.org).


http://www.snomed.org/



7.1.1 Native dm+d

Refer to the dm+d implementation guidance documents for more information related to the use of dm+d, including that related to the use of “native” dm+d. These are available from the dm+d web site (http://www.dmd.nhs.uk).

Where a medication item is not in the dm+d, current FP10 processes must be followed and no EPS prescription message will be generated.

7.1.2 Dosage Instructions

The prescriber is required to enter a medication item dosage. The use of a generic default value, for example “Use as directed”, if a value is not entered, is not acceptable from a clinical perspective. The user must be asked to select a dosage instruction from a pick list, type by hand or have the system populate with a valid and clinically safe dosage instruction relevant to the prescribed medication or clinical circumstances.

As per BNF guidelines, the dosage must be presented to the user without abbreviation although it may be entered and stored within the PMR in an abbreviated form. Within prescription messaging, the dosage instruction must be represented without abbreviation.

7.1.3 Unit of Measure

The system must associate each VMP (and hence each related AMP, VMPP or AMPP) with a single unit of measure which will then be used by prescribers and dispensers. This relationship is not directly defined within the dm+d and must be determined via navigation of the dm+d concepts and their data attributes.

To identify the unit of measure for a VMP concept, the unit of measure associated with the related VMPP concepts must be used. In the majority of cases, a common and usable unit of measure will exist.

For example;

“Paracetamol 500mg soluble tablets”, all VMPP units of measure are recorded as “tablet”

“Salbutamol 100micrograms/dose inhaler CFC free”, all VMPP units of measure are recorded as “dose”

Note. Some medication items exist where two or more units of measure are recorded within VMPP concepts. This applies to a small number of concepts where products are expressed, for example, either by weight (gram) or volume (ml), or by dose or weight (gram). Examples are;

• VMP “White soft paraffin 15% / Liquid paraffin light 6% cream”

o Prescribable as a number of ‘gram’ or a number of ‘ml’

• AMP Unguentum M cream (Almirall Ltd)

o Prescribable as a number of ‘gram’ or a number of ‘ml’

• AMP “ReplensMD vaginal mosituriser (Crescent Pharma OTC Ltd)

• Prescribable as a number of ‘gram’ or a number of ‘dose’




In such circumstances, the prescriber must be given the ability to prescribe using any of the relevant units of measure. For the examples above this would be either by ‘gram’ or ‘ml’, or by ‘gram’ or ‘dose’.

7.1.4 Quantity

A quantity of medication must be expressed in HL7 as a numeric value using the “Alternative Units” flavour of quantity with the dm+d unit of measure as defined in the above section. An example is shown below.

<quantity value="200" unit="1">

<translation value="200"

codeSystem="2.16.840.1.113883.2.1.3.2.4.15" code="3317411000001100"

displayName="dose" />

</quantity>

In the example above;

• ‘quantity/@value’ and ‘translation/@value’ represent the numeric quantity of the unit of measure. Always populate with the same value.

• ‘unit’ is the UCUM representation of the unit. If UCUM units are not available or the unit of measure is not known within UCUM the fixed value of "1" must be used

• ‘codeSystem’ is a fixed OID for SNOMED (dm+d)

• ‘code’ is the SNOMED (dm+d) code for the unit of measure

• ‘displayName’ is the dm+d text representation of the unit of measure.

7.1.5 Timeliness of Local dm+d Data

The dm+d terminology is updated weekly and is available to download from the Authority’s TRUD Service.

It is important that local systems use an up-to-date version of the dm+d to ensure that new concepts or amendments within the dictionary are available. The system supplier must ensure that the version of dm+d installed at each site is no more than 2 months older than the current version of dm+d as published on the TRUD website.

Suppliers can choose to implement dm+d directly or take a value-added terminology from a 3rd party supplier. To account for those suppliers who use a 3rd party terminology, a period of 2 months is sufficient for each supplier to process, manipulate and distribute the latest version of the dm+d.

7.1.6 Non dm+d mapped medication items

If the System uses a proprietary clinical terminology in addition to the NHS dm+d, then within medication picking lists, any items not mapped to the dm+d and hence not supported by the EPS must be indicated so that the prescriber is immediately aware that an FP10 will be required for this patient.





EPMVP-FR-70

The System must use the NHS Dictionary of Medicines and Devices (dm+d) coding scheme for medication item information within HL7 messaging, including specifically Snomed CT concept ID and the dm+d description for the medication item.

6.5.1

EPMVP-FR-71

The System must ensure that all dm+d content can be handled without string truncation.

6.5.2

EPMVP-FR-72

Systems must not provide a default value for medication item dosage.

6.5.3

EPMVP-FR-73

Systems must present medication item dosage instructions to the user and include in messaging without abbreviation

6.5.3

EPMVP-FR-74

Systems may allow dosage instruction entry and storage in an abbreviated form.

6.5.3

EPMVP-FR-75

The System must record prescribed medication items using the dm+d "Virtual Medicinal Product Name" or "Actual Medicinal Product Description" and the associated Snomed CT concept ID as described within the dm+d technical specification.

6.5.4

EPMVP-FR-76

The System must not permit prescriptions at the dm+d pack level using the VMPP or AMPP concepts.

6.5.4

EPMVP-FR-77

Systems must include dm+d descriptors in messages with the correct case as defined within dm+d.

6.5.4

EPMVP-FR-78

The System must use the unit of measure associated to the prescribed medication item derived from the related VMPP concepts.

6.5.5

EPMVP-FR-79

The System must use the dm+d VMP name or AMP description within the UI and within patient records where these concepts exist or where a mapping from a proprietary terminology exists.

6.5.6

EPMVP-FR-80

The System must use the dm+d VMP name or AMP description on printed output where these concepts exist or where a mapping from a proprietary terminology exists

6.5.7

EPMVP-FR-81

the System must adhere to the definition of “Native dm+d” as defined by the Authority where implements a mapped solution from another terminology service to dm+d

6.5.8




EPMVP-FR-82

The System must use the dm+d unit of measure description, where these concepts exist or where a mapping from a proprietary terminology exists, within the UI, within patient records and on printed output.

6.5.11

EPMVP-FR-83

The system must not use a dm+d release older than 2 months from the latest release as published weekly on TRUD.

6.5.12

EPMVP-FR-84

The system must not allow free-text entry of medication where the medication is defined within the local drug dictionary.

6.5.13

EPMVP-FR-85

The system may allow free-text medication entry when prescribing a medication that is not known within the local drug dictionary.

6.5.13

EPMVP-FR-86

The system may allow free-text entry as part of medication search functions, but once identified must require medication selection via drug dictionary identifiers and descriptions.

6.5.13

EPMVP-FR-87

The system may allow free-text entry as part of unit of measure search function, but once identified must require unit of measure selection via drug dictionary identifiers and descriptions.

6.5.13

EPMVP-FR-88

The System must indicate any items not mapped to the dm+d and hence not supported by EPS such that the user is immediately aware that a non electronic prescription will be required for this patient and medication item if prescribed.

6.5.15

8 Prescription Nomination

At the current EPS implementation stage for prescriptions to be sent electronically they must have a dispenser nominated, to which the prescription will be released by default. Patients are able to record dispenser nominations on their Spine Demographics record, which is accessed and used by primary care prescribers to apply to primary care prescriptions.

The limited functional scope of this specification precludes systems implementing full nomination functionality, and additionally in the expected care settings these systems support (e.g. urgent care, GUM, remote consultations) patients are likely to either not to wish to use their normal dispenser nomination, or to not have a nomination in place. Within this specification, systems must require the user to assist the patient to identify a dispenser for the prescription to be sent to, and to use this to apply a ‘one-off’ nomination to the electronic prescription.



Identification of a Dispenser ODS Code

To set a nominated dispenser for a prescription, the ODS code of the dispensing location must be known. Within a prescribing system, it is likely that such dispenser data is either not known, or only local dispensers are recorded. Details of dispensers operating will be provided by the Authority’s API

8.1 Dispensing Contractors and Nomination There are a number of different dispensing contractor types, who can different kinds of medication and appliance as defined in the NHS Drug Tariff. The MVP prescribing system need only support nomination to community dispensers who are able to dispense all categories of medication and appliance. The attribute “Dispensing Site Preference” of the Parent Prescription message is used to indicate which type of dispensing contractor is applicable to the prescription.

Figure 6: Dispensing Site Preference

Four dispensing site preference codes are defined within the messaging specification. The relevant code is shown below.

Code Description

P1 Other (e.g. Community Pharmacy)

Table 1: Dispensing Site Preference codes

The appropriate code ("P1"must be recorded within the "Dispensing Site Preference" attribute.

Any medication item within the dm+d, with the exception of oxygen and items out of EPS scope, can be prescribed on a prescription for a community pharmacy.

The ODS code of the nominated dispenser must be recorded within the ‘R_AgentNPFITOrganisationSDS’ CMET linked to the ‘performer’ act relationship. This must be populated with the ID (the ODS code) of the nominated dispenser.

Figure 7 - Nominated Dispenser Information

will




EPMVP-FR-90

Systems must implement the requirements defined within the document “EPS Supplementary Specification: Nomination”

Nil

EPMVP-FR-90.1

Systems must require the user to select and confirm a dispenser nomination to be applied to each prescription prior to signing.

Nil

EPMVP-FR-91

The System must identify a nominated community pharmacy for a prescription using the “Dispensing Site Preference” and “Performer” entities within the Parent Prescription HL7 message.

6.7.1

EPMVP-FR-93

Systems must use the authority’s web service to validate the selected dispenser’s ODS code and confirm that the dispenser operates EPS before applying the nomination to a prescription.

Nil

EPMVP-FR-94

The System must ensure that the chosen ODS code is a dispensing contractor ‘site’ and must not allow nomination of dispensing contractor organisations or groups

5.2.6

EPMVP-FR-95

Systems should default to sending prescriptions generated within the same consultation to the same dispenser.

Nil

EPMVP-FR-96

Systems must not default to the previously used nomination for a patient’s prescriptions in a separate consultation.

Nil

EPMVP-FR-97

Systems must display a message to the user to the effect that the patient must understand that prescriptions generated by the system will be nominated to the dispenser that they select on this occasion, and that this will not affect other electronic prescriptions.

Nil

EPMVP-FR-98

Systems should provide a mechanism to confirm that the selected dispenser is open and available to dispense the prescription within the period needed by the patient.

Nil

9 Electronic Signature

The “Parent Prescription” HL7 message must include an Advanced Electronic Signature (AES) of the authorising prescriber – the HL7 ‘author’ entity. Where a prescription message is electronically signed by the author, the electronic message represents the legal prescription entity.

Refer to separate digital signature documentation for more information regarding the technical requirements for signing (refs: NPFIT-ETP-EDB-0064 and NPFIT-FNT-TO-IG-0019).

The System must check the user content commitment certificate is valid at the time of signing an electronic prescription.

The System must check that the certificate used for electronic signing is the content commitment certificate, as opposed to the authentication certificate, which are both



present on the user’s NHS smartcard. The content commitment certificate is indicated by the non-repudiation value in the certificate’s keyUsage attribute.


EPMVP-FR-100

The system must generate the digital signature of the prescriber and apply to the prescription message as defined in the message specification when signing electronic prescriptions.

6.13.5

EPMVP-FR-102

The system must apply the signature to the electronic prescription once the signer has explicitly committed to the prescription content being signed.

6.13.5

6.13.6

EPMVP-FR-103

The System must check the certificate being used is valid at the time of signing an electronic prescription.

6.13.7

EPMVP-FR-104

The System must check that the being used for electronic signing is the content commitment certificate.

6.13.8

EPMVP-FR-105

The system must check that the certificate being used is issued by the appropriate NHS Certificate Authority.

Nil

EPMVP-FR-106

Systems must implement the signature requirements defined in the documents NPFIT-ETP-EDB-0064 and NPFIT-FNT-TO-IG-0019.

6.13.9

10 Prescription Acknowledgements & Errors

10.1 Application Acknowledgements Spine behaviour differs slightly from the behaviour described in the message specification in that all messages to Spine receive an async response message. Specifically this means that Parent Prescription messages receive an async acknowledgement in all cases, and not just in the case of an error as described in the message specification. Accordingly systems must expect an async response to all outbound messages, and take appropriate action if one is not received.

EPMVP-FR-110

The system SHALL alert the user if no async response to a message is received from Spine and prompt them to take appropriate action

Nil

10.2 Prescription Rejections After a “Parent Prescription” message has been submitted to the Spine, the Spine may respond with a rejection message within the application acknowledgement. Coded details for the reason for rejection will be contained within the acknowledgement.



The table below lists the rejection reasons that may be used in a prescription rejection:

Name Error Code

Text

DUPLICATE_PRESCRIPTION 0002 Duplicate prescription ID exists

DIGITAL_SIGNATURE_NOT_FOUND 0003 Digital signature not found

UNEXPECTED_EXCEPTION 9999 Unexpected Exception Occurred while processing

UNABLE_TO_PROCESS 5000 Unable to process message. Information missing or invalid

Error 5000 is likely to have supplementary information describing the error in more detail. This is included in the descriptive text of the error after a dash. For example:

<hl7:code codeSystem="2.16.840.1.113883.2.1.3.2.4.16.34" code="5000"

displayName="Unable to process message. Information missing or invalid -

prescriptionID has invalid format">

If the reason for a rejection can be fixed, for example populating the prescription with a valid number of items, then the prescription can be resubmitted using the same prescription ID.

If the reason for a rejection cannot be fixed within the current prescription, for example, if a duplicate prescription ID exists, then a new prescription must be generated and signed.


EPMVP-FR-111

The System must alert the prescriber on receipt of a “Parent Prescription Reject” message including the reason for rejection and update local records accordingly.

6.15.1

EPMVP-FR-112

The System must allow a rejected prescription to be corrected where this is appropriate and re-signed and resubmitted to Spine.

6.15.2

11 Prescription Cancellation

11.1 Update Semantics In cases where the clinician has made an error to a prescription or wishes to update a prescription, they must cancel that prescription and re-issue another prescription.



It is not possible to undo a cancellation request message. In such cases, the cancellation would remain and the clinician would need to issue a new replacement prescription.

11.2 Prescription Cancellation An electronic prescription can be cancelled after submission to the Spine provided the prescription has not been downloaded or processed by a dispenser.

To cancel a prescription the prescribing system is required to send a prescription cancellation request message. A cancellation can be to an individual item level or at the prescription level (which implies that all items are cancelled).

The reason for cancellation must be provided by the prescriber using the Cancellation Reason vocabulary:

Code Description

0001 Prescribing error

0002 Clinical contra-indication

0003 Change to medication treatment regime

0004 Clinical grounds

0005 At the Patient’s request

0006 At the Pharmacist’s request

0008 Patient deducted - other reason

0009 Patient deducted - registered with new practice

Cancellation Reason Vocabulary

If the prescription is in a cancellable state, i.e. not with dispenser or already complete then the cancellation will be processed immediately and a successful cancellation response returned.

If the prescription is in a state whereby cancellation will never be possible, i.e. all issues are complete, a cancellation failure response will be returned.

If the prescription is in a state whereby it cannot be cancelled at present, but may be cancellable in future, i.e. is with dispenser, but could be returned to Spine, a negative response will be returned, but a pending cancellation will be added to the record to be processed later if the prescription returns to a cancellable state.

If the prescription cannot be found, a negative response will be returned but a skeleton record containing only the pending cancellation will be created so that if the prescription is received later, the pending cancellation can be processed.

The Cancellation Response interaction uses an Application Acknowledgement transmission wrapper, so the Acknowledgement typeCode will be ‘AE’ where cancellation fails. Detail of the cancellation response is available in the Cancel Response part of the message using the Cancellation Response Reason vocabulary:

Code Description Appropriate Action To Take




0001 Prescription/item was cancelled

The cancellation request was successful and the user is notified accordingly, including whether this relates to item or prescription.

0002 Prescription/item was not cancelled – With dispenser

The cancellation request was unsuccessful because the prescription has been transmitted to a pharmacy for dispensing. The cancellation request identifies the prescription/item to be cancelled and sets a flag in the Spine that should that prescription be returned to the Spine by the dispenser, the prescription will be cancelled and a cancel response will be sent to the prescriber indicating that the initial cancel request was successful. The user must be notified accordingly.

0003 Prescription/item was not cancelled – With dispenser active

The cancellation request was unsuccessful because the prescription has been transmitted to a pharmacy for dispensing and the Spine has identified that dispensing events have been recorded against that prescription. The response will notify the prescriber which dispenser has the prescription. The user must be notified accordingly.

0004 Prescription/item was not cancelled – Dispensed to Patient

The cancellation request was unsuccessful because the prescription has been transmitted to a pharmacy for dispensing and the Spine has identified that dispensing events have been recorded against that prescription. The Spine has been updated accordingly. The prescription is recorded as having been dispensed. The user must be notified accordingly.

0005 Prescription/item had expired

The prescription/item cannot be cancelled because the prescription/item has expired. The user must be notified accordingly.

0006 Prescription/item had already been cancelled

The prescription/item cannot be cancelled because a cancellation request from a prescriber has already been received and the prescription has been cancelled. The user must be notified accordingly, including whether the notification relates to prescription or item.

0007 Prescription/item cancellation requested by another prescriber

The prescription/item cannot be cancelled because a cancellation request from a prescriber has already been received and the prescription has been marked for cancellation. The user must be notified accordingly




0008 Prescription/item not found The prescription/item cannot be cancelled because the prescription to be cancelled has not been recorded by the Spine. This situation can occur when:

• The cancel request arrives in the Prescriptions component of the Spine before the prescription that is being cancelled. See below for guidance on this scenario.

• A cancel request is made for a prescription where there is an error in the prescription ID defined in the prescription message.

• The prescription has been claimed and subsequently removed and archived from prescription store by Spine.

In all cases the user must be notified accordingly.

0009 Cancellation functionality disabled in Spine

The Spine cancellation functionality has been disabled at the request of the Authority and the message is rejected. The cancellation request will not be processed. The prescriber should seek other means to cancel the prescription.

0019 Prescription/item was not cancelled. Prescription has been not dispensed.

5000 Unable to process message. [- Additional Information (if any)]

The user should inform their system supplier that a message was rejected by the Spine.

5888 Invalid message The user should inform their system supplier that a message was rejected as invalid by the Spine.

Table 2: Cancellation Response Reason

The asynchronous reliable messaging pattern used by EPS means that order of delivery is not guaranteed. This means that a cancel request may be received by Spine before the prescription to which it refers. In this case Spine will issue a cancel reject response indicating that the prescription was not found within the EPS. Spine will record the prescription ID and reject any subsequent parent prescription message attempting to add this prescription.

The system may fail to receive a cancellation response due to system failure. The System must alert the user that a cancellation response has not been received after an appropriate period of time since the cancellation request was submitted. This period of time should be a configurable to allow for system behaviour to align with typical response times for asynchronous messaging within the live environment. Within this alert the user must be informed that they should assume the cancellation process was unsuccessful and that manual means to cancel the prescription must be undertaken (e.g. contacting the patient).

11.2.1 Subsequent Cancellation Response Interaction

In the case that a pending cancellation is processed after a cancellation failure response has been returned, a subsequent cancellation response will be generated and sent to the system that requested the cancellation.



It is possible to have more than one pending cancellation will be applied to a prescription if they are for different things, though a pending cancellation will not be added if an existing pending cancellation would have the same effect, i.e. a pending prescription cancellation for line item 2 cancellation could be added to an existing pending line item 1 cancellation, but a pending line item 1 cancellation could not be added to a an existing pending prescription cancellation or an existing pending line item 1 cancellation. In these cases, the prescription cancellation failure response is returned with a reason for failure.

Pending cancellations are actioned upon receipt of a Dispense Proposal Return from the dispenser and discarded upon receipt of a Dispense Notification.

Scenarios exist where more than one “Subsequent Cancellation Response” interaction will be received by a prescribing system.

Separate responses are triggered to inform the system depending on whether the original cancellation request referenced the Prescription ID only, or the Prescription ID and separate Item IDs.

The following table gives examples.

Number of items

on prescription

Nature of cancellation request Subsequent responses received

and content

1 item By Prescription ID only 1 - prescription was cancelled

1 item By Prescription ID and Item ID 1 – item was cancelled

2 – prescription was cancelled

2 items By Prescription ID only 1 - prescription was cancelled

2 items By Prescription ID and Item ID for item 1

then

By Prescription ID and Item ID for item 2

1 – item was cancelled

2 – item was cancelled

3 - prescription was cancelled

2 items By Prescription ID and Item ID for item 1 1 – item was cancelled

Ref Requirement

EPMVP-FR-115

The System must implement the Cancel Request - PORX_IN030101UK32 interaction.

6.16.1

EPMVP-FR-116

The system must implement the Cancel Response - PORX_IN050101UK31 interaction.

6.16.1

6.16.3

EPMVP-FR-117

The system must implement the Subsequent Cancel Response - PORX_IN050102UK32 interaction.

6.16.1

6.16.3



Ref Requirement

EPMVP-FR-118

The System must allow for cancellation of a complete prescription that has been sent to the Spine.

6.16.2*

EPMVP-FR-118.1

The system SHOULD allow for cancellation of an individual prescription item that has been sent to Spine

6.16.2*

EPMVP-FR-118.2

The system must make clear to the user whether the requested cancellation relates to a specific item or a complete prescription

Nil

EPMVP-FR-119

The System must require the user to specify the reason for cancellation.

6.16.1

EPMVP-FR-120

The System must identify which prescription, or item, is affected by a cancellation rejection and allow the user to take appropriate action.

6.16.3

EPMVP-FR-121

The System must notify the user of the reason for an unsuccessful cancellation.

6.16.3

EPMVP-FR-122

The System must provide the user with the contact details for the dispenser as contained within the cancellation response message where cancellation is unsuccessful due to the prescription already being with dispenser.

6.16.4

EPMVP-FR-123

Systems must inform users that they must use manual means to cancel the prescription (e.g. by contacting patient) where a cancel response is not received.

6.16.5

EPMVP-FR-124

Systems must populate the author of the cancellation request message with the details of the user requesting the cancellation.

6.16.6

EPMVP-FR-125

Systems must populate the responsibleParty of the cancellation request with the details of the person who electronically signed the prescription.

6.16.6

EPMVP-FR-126

Systems must enable prescriptions to be cancelled after the associated care episode has closed.

Nil

12 Messaging

Spine messaging requirements are defined within the External Interface Specification (ref: CDT D0002).

All system-to-system communication for EPS is implemented using ebXML asynchronous messaging, carrying HL7 messages as defined by the Message



Implementation Manual (MIM) or Domain Message Specification (DMS), collectively known as the message specification.

Health Level 7 (HL7) is an organisation responsible for the production and promotion of the HL7 series of healthcare IT communications standards. In 2002 the NHS Information Standards Board (ISB) approved HL7 Version 3 as the strategic standard for NHS clinical messaging.

HL7 Version 3 ensures consistency in the definition of different information objects and their representation in messages, thus allowing for easier implementation and the definition of clearer conformance requirements. HL7 V3 standards are developed using XML schema to define the information model. These schemas are one of the the key elements of the message specification.

12.1.1 Message Specification

HL7 message specifications for prescription messaging are defined in Message Implementation Manuals and Domain Messaging Specifications. Prescription interactions are defined in MIM 4.2.02 in the Medication Management domain. Demographics interactions, where these are being implemented by the system, are defined in MIM 6.2.02 in the PDS domain. Generic messaging elements such as wrappers and Application Acknowledgements are defined in the Infrastructure domain of the respective messaging specification.

Implementers must ensure that all outbound messages are valid against the respective XML schema as provided in the messaging specification.

12.1.2 Use of Spine Directory Service for Messaging

The System is required to obtain messaging parameters (i.e. ASIDs and CPA IDs) from the Spine SDS. The System is required to obtain these parameters on a regular basis as these values could be subject to change. Implementers are advised to check messaging attributes returned from SDS to ensure they are valid, for example to ensure they are non-blank.

12.1.3 Timestamps

Suppliers are reminded of the CFH Standards Consulting Group clarification for timestamp representation, “NPFIT-FNT-TO-SCG-0005 SCG clarification on time zone v1.0”. The System must adhere to this guidance for Spine 2 compliance.

Ref Requirement

EPMVP-FR-130

The System must populate all mandatory elements and attributes as defined by the appropriate XML schemas published in the message specification and all mandatory and required fields as defined within the message specification tabular views.

6.2.2

EPMVP-FR-131

The System must not allow outbound HL7 messages which are not valid against the respective schema to be sent.

6.2.3*



EPMVP-FR-132

The System must format timestamp data as per the “NPFIT-FNT-TO-SCG-0005 SCG clarification on time zone” guidance paper.

6.2.24

EPMVP-FR-133

The System must receive and handle HTTP transport layer acknowledgements sent from Spine together with the relevant interactions from the ‘TMS Infrastructure’ specification within the message specification.

6.2.5

EPMVP-FR-134

The System must obtain messaging parameters from SDS. 6.2.6*

EPMVP-FR-136

The System must cache messaging parameters obtained from SDS for a reasonable time as these values may be updated.

6.2.6

13 Controlled Drugs

Changes in legislation in 2015 permitted the prescribing of Schedule 2 and 3 controlled drugs using an Advanced Electronic Signature (AES), thus such prescriptions could be prescribed via the EPS.

Schedule. EPS Scope Expiry Date

1

Out of scope N/A

2

In scope 28 days

3

In scope 28 days

4

In scope 28 days

5 In scope 6 months

Not controlled In scope 6 months

Table 3 - EPS Requirements for the Controlled Drug Schedules

Systems must include the quantity expressed in words in all prescriptions of Schedule 2 or 3 controlled drugs, to include both new prescriptions and reauthorisations of old prescriptions. These must be in one of two formats as controlled by the Authority. In the short term the quantity in words must be included in additional information relating to the controlled drug, and must be delineated by the

string ‘CD: ‘ and a linebreak, as indicated by ↲ in the example below:

<pertinentAdditionalInstructions classCode="OBS" moodCode="EVN">

<code code="AI" codeSystem="2.16.840.1.113883.2.1.3.2.4.17.30"/>



<value>CD: Three hundred and fifty↲

Dosage has been increased upon advice from Specialist</value>

</pertinentAdditionalInstructions>

In the longer term the quantity in words must be included within an originalText element within the quantity, for example:

<quantity value="28" unit="capsule">

<translation value="28" code="428641000"

codeSystem="2.16.840.1.113883.2.1.3.2.4.15" displayName="capsule”>

<originalText>twenty eight</originalText>

</translation>

</quantity>

The switch between these two configurations must be controlled by the authority, to ensure that configuration is changed only when all dispensing systems are configured to expect the appropriate format.

Ref Requirement

EPMVP-FR-140

The System must ensure that schedule 1 controlled drugs are not prescribed using the EPS on NHS prescriptions.

6.11.1

EPMVP-FR-141

The System must allow the prescribing of schedule 2, 3, 4 and 5 controlled drugs and non controlled drugs using the EPS, via acute prescribing

6.4.20*

6.11.7

EPMVP-FR-142

The System may prescribe schedule 2, 3, 4 or 5 controlled drugs on the same prescription, together with non-controlled drugs.

6.11.2

EPMVP-FR-143

Systems MUST be configurable to populate the quantity expressed in words when prescribing a Schedule 2 or 3 controlled drug EITHER within an <originalText> element inside the quantity expressed in figures using the “alternative units” HL7 flavour OR as the first item of any instructions relating to the line item

6.11.6

6.11.8

EPMVP-FR-144

Systems must prefix the quantity expressed in words with the string “CD: ” and separate the quantity expressed in words from any other instructions with a line break when populating instructions relating to the line item.

6.11.8

EPMVP-FR-145

Systems must permit configuration of quantity expressed in words only under the control of the Authority.

6.11.10

EPMVP-FR-146

Systems must not allow the user to edit the quantity expressed in words and shall only allow the user to edit the quantity expressed numerically, which must then update the quantity expressed in words.

6.11.8

EPMVP-FR-147

Systems must include the quantity expressed in words in all prescriptions of Schedule 2 or 3 controlled drugs.

6.11.8



Ref Requirement

EPMVP-FR-148

Systems prescribing a Schedule 2 or 3 controlled drug medication with a quantity prescribed as a decimal value (e.g. 12.5 ml) must use the word “point” (e.g. “twelve point five”) for the amount in words.

6.11.9

EPMVP-FR-149.1

The System must include the means to enable and disable the functionality to prescribe schedule 2 and 3 controlled drugs via the EPS.

6.11.5

EPMVP-FR-149.2

Systems must permit enabling and disabling prescribing of schedule 2 and 3 controlled drugs via the EPS only under the control of the Authority.

6.11.5

14 14 14

14 Section removed

{Section removed}

15 Reporting and Information Requirements

This section defines reports and/or information that must be obtainable from within the system to support day-to-day processes within the practice in response to queries about prescriptions, from patients, pharmacists or other parties.

15.1 Electronic Prescriptions Report The System must be able to generate a report in a machine readable file format, for example to view as a spreadsheet, for all EPS R2 electronic prescriptions generated by the practice within a given date/time range. Such a report must be available to end users to generate and use. The output must contain the following minimum information;

• Prescription ID

• Patient NHS Number

• Patient Name

• Patient Date of Birth

• Prescription Authorisation Date/Time

• Prescription Submission Date/Time

• Prescription Treatment Type (e.g. Acute, Repeat prescribing, Repeat Dispensing)

15.2 Prescription Workflow/Status Visibility The current status of a prescription, in relation to EPS workflow, must be visible to the end user. The following workflow statuses, using either the terms defined below or equivalents currently in use within the System, must include at least the following;

• Submitted to the EPS



• Rejected by the EPS

• Cancellation requested

• Cancellation rejected by the EPS

• Cancelled


EPMVP-FR-165

The System must provide a report on electronic prescriptions generated by the prescribing organisation including: Prescription ID, Patient NHS Number, Patient Name, Patient Date of Birth, Prescription Authorisation Date/Time, Prescription Submission Date/Time, Prescription Treatment Type

6.20.1

EPMVP-FR-167

The system must make current status of an electronic prescription visible to the user.

6.20.5



Appendix A: Messaging Vocabularies Maintained Outside the Messaging Specification

B1: PrescriptionType Description: Describes the prescribing location and prescriber type of the prescription

Assigned OID: 2.16.840.1.113883.2.1.3.2.4.17.25

Version: 8.0

Date: 2017-10-06

Code Description Note

0101 General Practitioner Prescribing – Medical Prescriber

0104 General Practitioner Prescribing - Practice employed Nurse Independent/Supplementary prescriber

0105 General Practitioner Prescribing - Practice employed Community Practitioner Nurse prescriber

0108 General Practitioner Prescribing - Practice employed Pharmacist prescriber

0113 General Practitioner Prescribing - Practice employed Optometrist

0114 General Practitioner Prescribing - Practice employed Podiatrist/Chiropodist

0116 General Practitioner Prescribing - Practice employed Radiographer

0117 General Practitioner Prescribing - Practice employed Physiotherapist

0123 General Practitioner Prescribing - Hospital prescriber

Currently out of scope for EPS

0124 General Practitioner Prescribing - Practice employed Independent/Supplementary Dietician prescriber

0607 Dental Prescribing - Dentist Currently out of scope for EPS

0901 Private prescribing - GP Currently out of scope for EPS

0904 Private prescribing - Nurse prescribing Currently out of scope for EPS

0908 Private prescribing - Pharmacist prescribing Currently out of scope for EPS

0913 Private prescribing - Optometrist Currently out of scope for EPS

0914 Private prescribing - Podiatrist/Chiropodist Currently out of scope for EPS

0915 Private prescribing - Physiotherapist Currently out of scope for EPS

0916 Private prescribing - Radiographer Currently out of scope for EPS



B2: PrescriberEndorsement Description: Specific set of codes for describing endorsements that a prescriber may apply to a prescription

Assigned OID: 2.16.840.1.113883.2.1.3.2.4.16.32

Version: 3.0

Date: 2013-09-26

Code Description Note

CC No Charge Contraceptive No further information required

SLS Selected List Scheme No further information required

ACBS Advisory Committee Recommended No further information required

AF Assorted Flavours No further information required



Appendix B: Prescriber Codes

NHS Prescription Services (NHSRxS) is a service provided by the NHS Business Services Authority (NHSBSA) and uses codes for prescribers and organisations to identify where the prescription costs should be assigned and to provide data about who has prescribed what products.

• Medical prescribers require a single prescriber code on a prescription that identifies both them and the practice or cost

centre that they are working in

• Non-medical prescribers need two codes on a prescription one to identify them as an individual prescriber and another to

identify the practice or cost centre

Medical Prescriber Codes If a doctor chooses to enter general practice in England a 6 digit number is allocated by NHS Digital. This number is referred to as the Doctor Index Number or DIN. The DIN is passed to the requesting CCG or organisation acting on their behalf where the authorised signatory will then inform NHSRxS using the appropriate notification form.

• The 6 digit DIN will be used as the prescriber code in the ‘Responsible party - AgentPerson.Person.id field’ in an EPS

Release 2 prescription.

A DIN can only be used in one practice at any given time so where a GP is working in an additional practice or cost centre then the authorised signatory will ask for a spurious code. (Please note NHSRxS prefix the DIN with a G and add a check digit to create the General Medical Practitioner PPD code that is extracted and supplied to NHS Digital for use within the NHS. This 8 character GMP PPD code must never be used as a prescriber code in an EPS Release 2 prescription).



Spurious codes Spurious codes are only issued for use by medical prescribers as they identify that the prescriber is a medical prescriber. A non-medical prescriber should never use a spurious code. They are issued for a variety of reasons, including:

• As a prescribing code where a GP is working in two or more practices/cost centres and their DIN is being used in their first

practice. This allows the monitoring and the correct allocation of ‘costs’ of the GPs prescribing in each practice/cost centre.

• A locum doctor working in a practice where the GP has resigned (normally single-handed practices)

• Special exercises, projects or initiatives running in the CCG and funded from the CCG prescribing budget. i.e.

Dermatology Centres, Hospices etc where prescribing data is not required at individual medical prescriber level

A spurious code will only be issued to GPs whose DIN code is already in use at another practice/cost centre, or for hospital doctors who are not issued with a DIN code. Locum doctors should use the prescribing code of the doctor for whom they are providing locum services (unless there are no GPs left in the practice/cost centre). Spurious codes like DINs are 6 digit codes and begin with the number 6

Non-Medical Prescriber Codes A non-medical prescriber uses their professional registration or personal identification number issued by their relevant regulatory body to identify them as an individual prescriber and the practice or cost centre code.

• In an EPS Release 2 prescription the professional/PIN code should be used as the ‘Responsible party’ field and the

practice/cost centre code as the ‘organization’ field

Pooled list codes A pooled list code is a 6 digit code beginning with a 7 and is issued to a GP practice for the purpose of holding the practice’s patient list against one central code. This code is not a prescriber code and should never appear in an EPS Release 2 prescription.



Code Formats Code Format Example

GP/medical prescriber NNNNNN 954000

Nurse prescriber NNANNNNA 71A2998E

Pharmacist prescriber NNNNNNN 2033467

Optometrist prescriber NN-NNNNN* 01-09491

Podiatrist prescriber AANNNNNN** CH029821

Physiotherapist prescriber AANNNNNN** PH095159

Radiographer prescriber AANNNNNN** RA088262

Dietician prescriber AANNNNNN** DT012345

CCG code NNA 15A

NHS Trust XXX RAT

NHS Trust Site XXXNN RAT89

Independent Sector Healthcare Provider/Social Enterprise

XXX NAA

Practice/cost centre ANNNNN Y05001

* Optometrist prescriber codes may be 7 or 8 characters long. ** NHSBSA systems require these prescriber codes to be 8 characters long. Additional zeroes (0) should be inserted immediately following the first 2 alpha characters to extend the code to 8 characters as necessary. N = any number A = any alpha X = any number or any alpha or a space



Appendix C: Cross reference of “Prescription Type” code and prescriber codes

Below is a cross reference of examples of non-deprecated “Prescription Type” codes that are currently in-scope for EPS R2 prescribing together with the relevant mapping to Author and Responsible Party id.

Code Description Author

‘person.id’ Responsible Party

‘person.id’

0101 General Practitioner Prescribing – Medical Prescriber GMC DIN or Spurious Code


NMC NMC


NMC NMC

0108 General Practitioner Prescribing - Practice employed Pharmacist prescriber

GPhC GPhC

0113 General Practitioner Prescribing - Practice employed Optometrist

GOC GOC

0114 General Practitioner Prescribing - Practice employed Podiatrist/Chiropodist

HCPC HCPC

0116 General Practitioner Prescribing - Practice employed Radiographer

HCPC HCPC

0117 General Practitioner Prescribing - Practice employed Physiotherapist

HCPC HCPC

0124 General Practitioner Prescribing - Practice employed Independent/Supplementary Dietician prescriber

HCPC HCPC

Appendix D: Cross reference of EPS “Prescription Type” code and FP10 “Paper Type” and Prescriber Initiative

EPS Prescription Type Code

Description FP10 paper type

FP10 Prescriber Initiative

Note

0101 General Practitioner Prescribing – Medical Prescriber

FP10 SS


FP10 SS

PN


FP10 SS

PN

0108 General Practitioner Prescribing - Practice employed Pharmacist Independent/Supplementary prescriber

FP10 SS

SP



0113 General Practitioner Prescribing - Practice

employed Independent/Supplementary Optometrist prescriber

FP10 SS

SP


employed Independent/Supplementary Podiatrist/Chiropodist prescriber

FP10 SS

SP


employed Independent/Supplementary Radiographer prescriber

FP10 SS

SP


employed Independent/Supplementary Physiotherapist prescriber

FP10 SS

SP

0123 General Practitioner Prescribing - Hospital prescriber

FP10 SS

HP Hospital unit prescribers prescribing on ‘FP10’ prescriptions for dispensing in the community – not yet in scope for EPS


employed Supplementary Dietician prescriber

FP10 SS

SP New code to support Dietician Supplementary Prescribers