EPS Prescribing System Minimum Viable Product Functional Requirements

Transcription

1 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. Page 1 of 55 The Health and Social Care Information Centre is a non-departmental body created by statute, also known as NHS Digital.

2 Document Management Revision History Version Date Summary of Changes /06/2017 Branched from EPS Prescribing Systems Compliance Specification, split out NFRs & functionality reduced to MVP /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 /08/17 Replaced references to MIM & DMS with message specification unless a specific version. Reduced FR-7 to SHOULD. Clarified wording in FR-47. Removed section as only relevant to repeats. Requirement trace added to cancellation requirements Added requirement FR-117 requiring token destruction when prescription rejected Amended requirement FR-158 to prevent tokens being printed for unsigned EPS prescriptions Added requirement FR mandating page number where token spans several forms Added requirement 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 FR-90 to refer to new nomination supplementary specification Amended FR-2 to allow PDS v2 or v3 or ITK PDS mini service Updated appendices to remove deprecated codes and add information from NHSBSA /09/17 Updated wording of FR-1 to clarify Spine demographics may be read only Updated FR-91 to require nomination of only community dispenser Removed FR-92 as DACs not supported in MVP Amended FR-147 to remove reference to reauthorisation Removed section 14 and FR-150 to FR-162 removing requirement for printed token Removing requirement FR-117 removing requirement relating to printed tokens Added FP & FP allowing whole-prescription only cancellation Page 2 of 55

3 Renumbered first instances of FP-115 & FP-116 to FP-111 & FP-112 respectively avoiding duplicate requirement IDs /10/17 Removed patient-level additionalinformation, removing FR-60, FR-61 & FR-62, FR-64 & section Updated 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 Page 3 of 55

4 From: HUSSAIN, Mohammed (NHS DIGITAL) Subject: RE: FOR REVIEW & APPROVAL: EPS Prescribing System MVP - Functional Requirements Date: 29 August :13 To: GREENHALGH, Aled (NHS DIGITAL) aled.greenhalgh@nhs.net Cc: COLE, Rich (NHS DIGITAL) rich.cole@nhs.net, FRENZ, Kerry (NHS DIGITAL) k.frenz@nhs.net, WATERS, Martha (NHS DIGITAL) martha.waters@nhs.net Hi Aled Thank you for taking the time on Thursday 24 th August, to walk me through the spec and the changes proposed. I agree to the specification with these additional comments as we discussed: 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 will be one item prescriptions. This will simplify the messaging needed and will also help to evaluate if the approach to each item being a prescription has advantages for the workflow 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 other than 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 the existing 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 rapid response (akin to amazon fresh, same day service) at which point we will need to include. Hope this helps. Come back to me if you need anything further Kind regards Mohammed Mohammed(Hussain(FRPharmS Senior(Clinical(Lead,(Domain(E Digital(Medicines Code4Health(Pharmacy(Lead Health(Digital(Services NHS(Digital 8 th (floor,(bridgewater(place,(water(lane,(leeds,(ls11(5dr ( Telephone:( ( Please(note:(Libby.Pink@nhs.net(is(the(new(interim(Programme(Head(for(IPaCS ( General(enquiries: From: Greenhalgh Aled (HEALTH AND SOCIAL CARE INFORMATION CENTRE) aled.greenhalgh@nhs.net Subject: FOR REVIEW & APPROVAL: EPS Prescribing System MVP - Functional Requirements Date: 11 August :31 To: COLE, Rich (NHS DIGITAL) rich.cole@nhs.net, GOOCH, Robert (NHS DIGITAL) rob.gooch@nhs.net, HUSSAIN, Mohammed (NHS DIGITAL) mohammed.hussain3@nhs.net Cc: Implementation Eps (NHS DIGITAL) epsimplementation@nhs.net, Matthew Stibbs m.stibbs@nhs.net, GOOCH, Robert (NHS DIGITAL) rob.gooch@nhs.net, HUSSAIN, Mohammed (NHS DIGITAL) mohammed.hussain3@nhs.net, FRENZ, Kerry (NHS BUSINESS SERVICES AUTHORITY) kerry.frenz@nhs.net, HAGAN, Martin (NHS BUSINESS SERVICES AUTHORITY) martin.hagan@nhs.net, WHITE, Shaun (NHS DIGITAL) shaun.white@nhs.net, Alastair Pickering alastair.pickering@nhs.net, LAMBE, Joanne (NHS DIGITAL) joanne.lambe@nhs.net, MOORE, Candice (NHS DIGITAL) candice.moore@nhs.net, BRANTON, Simon (NHS DIGITAL) simon.branton@nhs.net, Oliver Christie oliver.christie@nhs.net, PIERCE, Rebecca (NHS DIGITAL) rpierce@nhs.net 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 [rpierce@nhs.net] as I ll be away on a course until 20th Aug. Regards, A _Review Log - EPS Presc cation.docx EPS Prescribing System MVP Funct cation.docx!! Aled&Greenhalgh Technical&Architect NHS&Digital t:&0113&397&3294 e:&aled.greenhalgh@nhs.net From: GOOCH, Robert (NHS DIGITAL) rob.gooch@nhs.net Subject: RE: FOR REVIEW & APPROVAL: EPS Prescribing System MVP - Functional Requirements Date: 17 August :59 Aled, To: GREENHALGH, Aled (NHS DIGITAL) aled.greenhalgh@nhs.net Cc: PIERCE, Rebecca (NHS DIGITAL) rpierce@nhs.net 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 :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 [rpierce@nhs.net] as I ll be away on a course until 20th Aug. Regards, A. EPS Prescribing System Minimum Viable Product Functional Requirements 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: Approved 1.0 Rich Cole, DCPM Programme Manager Approved 1.0 Rob Gooch, Domain E Lead Architect Approved 1.0 Page 4 of 55

5 Glossary of Terms Term / Abbreviation Acute prescription AHP Advanced Electronic Signature (AES) Domain Message Specification (DMS) Electronic prescription Electronic Prescription Service (EPS) Electronic Transmission of Prescriptions (ETP) Prescription token FP10 Health & Social Care Information Centre (HSCIC) Health Level 7 (HL7) Medication item Message Implementation Manual (MIM) Organisation Data Service (ODS) NHS Dictionary of Medicines and Devices (dm+d) Nomination of dispenser Patient Medical Record (PMR) Personal administration Prescribe Repeat prescription Repeatable prescription The System Universal Unique Identifier (UUID) What it stands for A one-off prescription generated following a consultation between a prescriber and a patient Allied Healthcare Professional An electronic digital signature standard referenced within DH legislation for signing prescriptions The new name for the MIM. Separate versions are now published per domain. 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 delivered by the ETP programme Electronic Transmission of Prescriptions programme Paper copy of the electronic prescription used to capture the patient s declaration of charge paid or exemption. The paper form that is used to create a paper based NHS prescription. The Health and Social Care Information Centre is the national data, information and technology organisation for the health and care systems in England. Organisation responsible for the production and communication of healthcare IT communications standards ( Any medicine, appliance or reagent that can be prescribed Deprecated term - see Domain Message Specification. A product from the NHS CFH that defines the HL7 messages implemented within the NCRS. 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. Standard for exchange of information on drugs and devices between prescribers, dispensers and reimbursement agencies ( Process by which a patient specifies a dispenser to manage their prescriptions 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. 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. The act of authorising medication items on a prescription. A prescriber-authorised repetition of a prescription A prescription valid for an authorised number of issues The system seeking compliance as an ETP prescribing system An information technology term for a unique identifier, also known as a Globally Unique Identifier (GUID) more specifically a DCE UUID Page 5 of 55

6 Page 6 of 55

7 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, 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 v 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 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 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 Page 7 of 55

8 Contents 1 About this Document Purpose Audience Content 10 2 Background 10 3 Scope EPS Functional Scope MVP Functional Scope EPS National Model 13 4 Patient Demographics Synchronisation of PDS Attributes Demographics restrictions to Prescribing 14 5 Electronic Prescription Generation 15 6 Prescription Attributes Electronic Acute Prescribing Medication Items Prescription IDs Population of Clinician and Patient Details Supplementary Messaging Requirements 28 7 Medication Management 29 8 Prescription Nomination Dispensing Contractors and Nomination 34 9 Electronic Signature Prescription Acknowledgements & Errors Application Acknowledgements Prescription Rejections Prescription Cancellation Update Semantics Prescription Cancellation 38 Page 8 of 55

9 12 Messaging Controlled Drugs Section removed Reporting and Information Requirements Electronic Prescriptions Report 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 Page 9 of 55

10 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 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 Page 10 of 55

11 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 Page 11 of 55

12 DMS 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. Page 12 of 55

13 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 Page 13 of 55

14 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 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 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 Page 14 of 55

15 Ref Requirement Req Trace EPMVP -FR-2 EPMVP -FR-3 EPMVP -FR-4 EPMVP -FR-5 EPMVP -FR-6 EPMVP -FR-7 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 ) OR PDS Compliance Module V2 - Baseline Index (ref: NPFIT-FNT-TO- TIN-1188) 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 The System must not automatically synchronise PDS telecom details, including use attributes. The System must prevent an electronic prescription for a patient who is recorded as deceased from being signed. The System must prevent an electronic prescription for a patient whose demographic record within Spine PDS is flagged as sensitive from being signed. 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 Electronic Prescription Generation An electronic prescription is implemented using the HL7 message Parent Prescription defined in the MIM. Page 15 of 55

16 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. Ref Requirement Req Trace EPMVP -FR-10 EPMVP -FR-11 EPMVP -FR-12 EPMVP -FR-13 The System must implement the Parent Prescription PORX_IN020101UK31 interaction. Systems must allow the user to generate a paper-based hand-signed FP10 prescription instead of an electronic prescription. 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. The electronic prescribing module of the System must pass all signed EPS prescriptions immediately to the Message Handler Service (MHS) module * Prescription Attributes The diagram below shows the business view of an electronic prescription. Page 16 of 55

17 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 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. FR-21 The System must ensure that all electronic prescriptions include at least one medication item Page 17 of 55

18 FR-22 The System must not allow more than 4 items in a single electronic prescription message 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. FR-25 FR-26 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. 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 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. FR-30 The System must permit the prescribing endorsements in the Prescribing Endorsements vocabulary (OID: ) Version: 3.0 to be applied to prescription items Prescription IDs Each prescription and medication item within a prescription is uniquely identified by a locally generated Universal Unique Identifier (UUID) 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; Page 18 of 55

19 Where; <RandomNumber>-<PracticeODSCode>-<PracticeSequence><CheckDigit> <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 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-A W 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="c6aca e-47bc a8bc763fc1c"/> Ref EPMVP -FR-35 EPMVP -FR-36 EPMVP -FR-37 Requirement Systems must represent the Short Form Prescription ID in upper case characters. 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. Systems supporting multiple prescribing organisation must use separate incremental number for each practice to populate the <PrescribingOrgSequence> part of the Short Form Prescription ID Page 19 of 55

20 Ref EPMVP -FR-38 EPMVP -FR-39 Requirement The System must provide a prescription search facility to locate prescriptions by Prescription ID from historic prescription records and prescriptions awaiting electronic signing. 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 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 R_Patient The R_Patient CMET contains data related to a single patient. Page 20 of 55

21 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"/>. Page 21 of 55

22 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 AgentPerson.id AgentPerson.code AgentPerson.telecom author Population Rules The prescriber s SDS Role Profile ID. The prescriber s SDS job role code (returned in the SAML assertion following successful end-user authentication) for example R8003. 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. Page 22 of 55

23 author Required Fields AgentPerson.Person.name AgentPerson.Person.id AgentPerson.Organization.id AgentPerson.Organization. code AgentPerson.Organization. name AgentPerson.Organization. telecom AgentPerson.Organization. addr AgentPerson.Organization. healthcareproviderlicense. Organization.id AgentPerson.Organization. healthcareproviderlicense. Organization.name author Population Rules The name of the prescriber identified by the AgentPerson.Person.id field. 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 The ODS code for the prescriber s organisation. The OID must be 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. The name of the organisation. A valid telephone number for the organisation. The postal address of the organisation. The ODS code for the commissioning organisation for the prescriber s organisation. The OID must be In most cases this with be the ODS code of the Clinical Commissioning Group (CCG). 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 Page 23 of 55

24 responsibleparty Required Fields AgentPerson.id AgentPerson.code AgentPerson.telecom AgentPerson.Person.name AgentPerson.Person.id responsibleparty Population Rules 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. 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. 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. The name of the prescribing/cost centre clinician or organisation as identified by the AgentPerson.Person.id field. 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 format 1 The OID must be Examples include; Prescriber Medic (e.g. any type of GP) Nurse Pharmacist See Appendix B. Code Doctor s Index Number (DIN) or spurious code 2 NMC GPhC 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. Page 24 of 55

25 responsibleparty Required Fields AgentPerson.Organization.id AgentPerson.Organization. code AgentPerson.Organization. name AgentPerson.Organization. telecom AgentPerson.Organization. addr AgentPerson.Organization. healthcareproviderlicense. Organization.id AgentPerson.Organization. healthcareproviderlicense. Organization.name responsibleparty Population Rules The ODS code for the clinically responsible organisation. The OID must be 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. The name of the organisation. A valid telephone number for the organisation. The postal address of the organisation. The ODS code for the commissioning organisation for the clinically responsible organisation. The OID must be In most cases this with be the ODS code of the Clinical Commissioning Group (CCG). 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) R_AgentNPFITOrgSDS This CMET is used to capture the patient s nominated dispensing site. Figure 4 - R_AgentNPFITOrgSDS CMET Page 25 of 55

26 The only required attribute is the OrganizationSDS id containing the ODS code of the dispensing site and the OID 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 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 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 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 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 Page 26 of 55

27 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 Data Types FR-40 FR-41 FR-42 FR-43 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. Systems shall format postal addresses using the AD Unstructured address plus postal code HL7 flavour. Systems shall support all flavours of the Telecommunication Address (TEL) datatype defined within the messaging specification. Systems shall support all ODS and prescriber code formats without truncation Patient FR-45 FR-46 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. Systems must populate patient date of birth in the format YYYYMMDD Page 27 of 55

28 FR-47 FR-48 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. Systems must provide a structured patient name for patients by using the PN Person name structured data type flavour within the R_Patient CMET FR-49 Systems must provide a single patient name and address FR-50 FR-51 The System must provide all telecommunication addresses recorded on the patient demographic record that are valid for the current date/time Systems must provide the patient s gender by populating the person.administrativegendercode within the R_Patient CMET Nil Author & Responsible Party FR-55 FR-56 FR-57 FR-58 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 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. The R_AgentNPFITPerson CMET must be populated as per the business rules within this specification when defining the author of a prescription. The R_AgentNPFITPerson CMET must be populated as per the business rules within this specification when defining the responsibleparty of a prescription Supplementary Messaging Requirements The following sub sections provide supplementary requirements for messaging which add to those requirements defined within the messaging specification Entity: AdditionalInstructions For EPS Release 2 the AdditionalInstructions entity has two purposes. Page 28 of 55

29 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 Section removed {Section removed} 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. Ref Requirement Req Trace EPMVP -FR-63 The System must use the PrescriptionType vocabulary defined within this specification. 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: 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: Page 29 of 55

30 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 ( Where a medication item is not in the dm+d, current FP10 processes must be followed and no EPS prescription message will be generated 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 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 Page 30 of 55

31 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 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=" " code=" " 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 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 3 rd party supplier. To account for those suppliers who use a 3 rd party terminology, a period of 2 months is sufficient for each supplier to process, manipulate and distribute the latest version of the dm+d 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. Ref Requirement Req Trace Page 31 of 55

32 Ref Requirement Req Trace FR-70 FR-71 FR-72 FR-73 FR-74 FR-75 FR-76 FR-77 FR-78 FR-79 FR-80 FR-81 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. The System must ensure that all dm+d content can be handled without string truncation. Systems must not provide a default value for medication item dosage. Systems must present medication item dosage instructions to the user and include in messaging without abbreviation Systems may allow dosage instruction entry and storage in an abbreviated form. 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. The System must not permit prescriptions at the dm+d pack level using the VMPP or AMPP concepts. Systems must include dm+d descriptors in messages with the correct case as defined within dm+d. The System must use the unit of measure associated to the prescribed medication item derived from the related VMPP concepts. 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. 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 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 Page 32 of 55

33 Ref Requirement Req Trace FR-82 FR-83 FR-84 FR-85 FR-86 FR-87 FR-88 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. The system must not use a dm+d release older than 2 months from the latest release as published weekly on TRUD. The system must not allow free-text entry of medication where the medication is defined within the local drug dictionary. The system may allow free-text medication entry when prescribing a medication that is not known within the local drug dictionary. 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. 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. 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 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 oneoff nomination to the electronic prescription. Page 33 of 55

34 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 P1 Description 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 Page 34 of 55