EPSPrescribing!SystemMVP J!NonJFunctional! Requirements! · EPSPrescribing!System!MVPF!NonFFunctional!Requirements! v0.2!! Page!7!of!36! !Copyright!©2015!Health!and!Social!Care!Information!Centre!

Copyright ©2017 Health and Social Care Information Centre

Document filename: EPS Prescribing System MVP Non Functional Specification.docx

Directorate / Programme Domain E

Project Digitising Community Pharmacy & Medicines

Document Reference

Project Manager Jo Lambe Status Draft

Owner Aled Greenhalgh Version 0.2

Author Aled Greenhalgh Version issue date 29th Jun 2017

EPS Prescribing System MVP - Non-Functional Requirements

EPS Prescribing System MVP - Non-Functional Requirements v0.2

Page 2 of 36 Copyright © 2015 Health and Social Care Information Centre

Document Management Revision History Version Date Summary of Changes 0.1 19/05/17 Branched from EPS Prescribing Systems Compliance Specification

0.2 29/06/17 Reformatted to use NHS Digital EA NFR template

Included requirements relating to NHS Digital EA policies

Reviewers This document must be reviewed by the following people:

Reviewer name Title / Responsibility Date Version DCPM Programme Manager Not reviewed 0.2

Domain B Clinical Lead Not reviewed 0.2

Domain B Lead Architect Not reviewed 0.2

Domain E Clinical Lead Not reviewed 0.2

Domain E Lead Architect Not reviewed 0.2

Implementation Manager Not reviewed 0.2

NHS BSA Not reviewed 0.2

NHS Digital Solutions Assurance Non Functional Test Team Not reviewed 0.2

NHS Digital Operational Security Team Not reviewed 0.2

NHS Digital Service Management Lead Not reviewed 0.2

Approved by This document must be approved by the following people:

Name Signature Title Date Version

Mohammed Hussein, Domain E Clinical Lead Not

Approved 0.2

NHS Digital Technical Design Authority Not

Approved 0.2

Rich Cole, DCPM Programme Manager Not

Approved 0.2

Rob Gooch, Domain E Lead Architect Not

Approved 0.2



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

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 the NCRS Spine to allow dispensing via ETP

Electronic Prescription Service (EPS)

Electronic Prescription Service delivered by the ETP programme

Electronic Transmission of Prescriptions (ETP)

Electronic Transmission of Prescriptions programme, part of the HSCIC.

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 medication, appliance or device 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) is provided by the HSCIC. 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 Medication administered directly by a healthcare professional to a 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

EA Enterprise Architect

HSCIC Health and Social Care Information Centre

NFR Non-Functional Requirement

NFRS Non-Functional Requirements Specification

NHS National Health Service



SAD System Architecture Document

SME Subject Matter Expert

TAID Technical Architecture & Infrastructure Directorate

UI User Interface

WAI Web Accessibility Initiative

Document Control: The controlled copy of this document is maintained in the NHS Digital 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.



Contents 1 Introduction 6

1.1 Purpose 6 1.2 Audience 6 1.3 Requirements Categories 7 1.4 System Scope 7 1.5 Approach 8

2 Non-Functional Requirements 9

2.1 Accessibility 9 2.2 Availability and Resilience 9 2.3 Infrastructure 12 2.4 Evolution 15 2.5 Performance and Scalability 19 2.6 Regulations 21 2.7 Security 22 2.8 Usability 30

3 Release Summary 33 4 Guide to Non-Functional Requirement Statuses 35 5 References 36



1 Introduction 1.1 Purpose The Non-Functional Requirements of a system (also known as the supplementary requirements or system quality requirements) are those requirements that constrain the form of the system in order to meet its functional requirements. The purpose of this artefact is to formally capture the non-functional requirements of the EPS Prescribing System Minimum Viable Product (MVP). This artefact should be read alongside the System Requirements document that describes the corresponding functional requirements of the EPS Prescribing System Minimum Viable Product (MVP). This artefact is produced in an iterative manner, each release clearly states which non-functional requirements of the previous version have been deprecated, issued with no change, issued with change or are waiting for review. Each document revision is distributed throughout interested parties in NHS Digital and external implementers.

1.2 Audience This section lists the audience at which this artefact is aimed. For each role, it describes the benefit to be gained from reading the document.

Table 1 – Document Audience Audience Reason

DCMP Programme To understand and validate the interpretation of the business non-functional requirements that the solution must support.

Solution Architects To understand the business non-functional requirements that constrain system design.

Developers To understand the business non-functional requirements that the system must be developed to meet.

System Testers To understand the business non-functional requirements and ensure system testing is designed and carried out to validate these correctly.

Solutions Assurance To understand the business non-functional requirements that they must assure the system against.

Service Operations Teams

To understand and validate the interpretation of the business non-functional requirements that the solution must support.

Live Service Support Suppliers

To ensure the components of the solution that they are contracted to provide support for meet the requirements as set out within this artefact.



1.3 Requirements Categories The requirements captured herein are predominantly related to the externally visible behaviour of the system;; for example performance and availability. Table 2 – Requirements Categories

Category Desired Characteristic Accessibility The ability of the system to be used by people with disabilities.

Availability and Resilience The ability of the system to be fully or partly operational as and when required and to effectively handle failures that could affect system availability.

Evolution The ability of the system to be flexible in the face of the change that all systems experience post deployment, balanced against the costs of providing such flexibility.

Performance and Scalability The ability of the system to execute within its mandated performance profile and to handle processing volumes now and in the future.

Regulations The ability of the system to conform to all applicable laws, regulations, company policies, and other rules and standards.

Security & Auditing The ability of the system to reliably control, monitor, and audit who can perform action on which resources and the ability to detect and recover from security breaches.

Usability The ease with which people who interact with the system can work effectively.

1.4 System Scope EPS starts at the point where a decision to prescribe has been taken and ends when medication is dispensed and reimbursed (or prescription is cancelled, expires etc.).

EPS covers all prescribing for any patient with a known and valid NHS number for supply of medicines, drugs, appliances and chemical reagents by NHS prescribers in primary or secondary care in England 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

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 as ‘extemp orders’

• Personal administration • Private prescriptions



1.4.1 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

1.5 Approach The requirements in this document are derived from NHS Digital Enterprise Architecture Policies and the non-functional requirements specified for GPSoC systems, which include EPS prescribing systems, and by reference to the EPS Dispensing Systems requirements and framework agreement. Requirements have been refined and prioritised based on associated clinical risk as defined by the DCPM clinical team.

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.



2 Non-Functional Requirements The following non functional requirements are required to be met by implementing systems.

2.1 Accessibility This category describes how the system is to be used by people with disabilities. There are currently no NFRs specific to EPS Prescribing systems in this category.

2.2 Availability and Resilience This category describes the ability of the system to be fully or partly operational as and when required and its ability to handle failures that could affect availability.

2.2.1 Service availability 2.2.1.1 Maintenance Periods Status: To be Reviewed

ID: EPMVP-NF-1

Category: Service Availability

Originator: - Subsystem: Entire system Requirement: Implementers must define regular maintenance periods during which users may expect all or part of the system to be unavailable.

2.2.1.2 Communication of planned outages Status: To be Reviewed

ID: EPMVP-NF-2

Category: Service Availability

Originator: - Subsystem: Entire system Requirement: Implementers must communicate any planned maintenance activities falling within or outside defined regular maintenance periods, and define which elements of the system can be expected to be unavailable.

2.2.2 Data Retention 2.2.2.1 Data Retention Periods Status: To be Reviewed

ID: EPMVP-NF-3

Category: Availability and Resilience

Originator: GPSoC Schedule 1.7, 730.40.8 Subsystem: Entire system Requirement: Systems must retain audit logs with the following availability:

• 3 years on-line (Years 1 to 3) • A further 7 years off-line, recoverable within 1 working day (Years 4 to 10 inclusive)



• A further 20 years off-line, recoverable within 1 working week (Years 11 to 30 inclusive)

2.2.3 Backup & Recovery 2.2.3.1 Regular backup Status: To be Reviewed

ID: EPMVP-NF-4


Originator: - Subsystem: Data store Requirement: Systems must back up data sufficiently to meet the RPO’s and RTO’s outlined below.

Further information: - 2.2.3.2 Backup validation Status: To be Reviewed

ID: EPMVP-NF-5


Originator: - Subsystem: Data store Requirement: Implementers must validate backups by conducting a recovery from backup exercise at least annually and at least once prior to initial deployment.

Further information: -

2.2.4 Time to Repair 2.2.4.1 Hardware maintenance contract Status: To be Reviewed

ID: EPMVP-NF-6

Category: Infrastructure

Originator: NHS Digital EA policy ‘All hardware must be under hardware break-fix /maintenance contract’

Subsystem: All system hardware Requirement: Implementers must ensure all connected hardware is provided under a break-fix / maintenance contract with a Service Level Agreement with the provider appropriate to meet requirements outlined in this specification.

2.2.4.2 RTO 4 hour Status: To be Reviewed

ID: EPMVP-NF-7


Originator: Subsystem: Entire system



Requirement: Systems must meet the Recovery Time Objective of 4 hours for the following datasets and systems:

• All hosted patient data • All central systems • All central network service

2.2.4.3 RTO 1 day Status: To be Reviewed

ID: EPMVP-NF-8


Originator: Subsystem: Entire system Requirement: Systems must meet the Recovery Time Objective of 24 hours for the following datasets and systems:

• All client data and systems


2.2.5 Whole Site Failure This category describes how the system is to cope with failure of a whole site, including operational requirements to protect against this and the timescales for recovery. There are currently no NFRs specific to EPS Prescribing systems in this category.

2.2.6 Business Continuity 2.2.6.1 Redundant network Status: To be Reviewed

ID: EPMVP-NF-9


Originator: NHS Digital EA policy ‘Network service provision must include robust Business Continuity and Disaster Recovery’

Subsystem: Network services Requirement: Networks hosting the system must be fully redundant Further information: - 2.2.6.2 Network in scope of DR/BC Status: To be Reviewed

ID: EPMVP-NF-10


Originator: NHS Digital EA policy ‘Network service provision must include robust Business Continuity and Disaster Recovery’

Subsystem: Network services Requirement: Networks hosting the system must be included in the scope of business continuity and disaster recovery analysis, plans and testing




2.2.7 Data Loss 2.2.7.1 RPO 1 hour Status: To be Reviewed

ID: EPMVP-NF-11


Originator: Subsystem: Data store Requirement: Systems must meet the Recovery Point Objective of 1 hour for the following datasets:

• Prescriptions issued • Audit data

Further information: - 2.2.7.2 RPO 1 day Status: To be Reviewed

ID: EPMVP-NF-12


Originator: Subsystem: Data store Requirement: Systems must meet the Recovery Point Objective of 24 hours for the following datasets:

• Cancellation data


2.2.8 Record Corruption There are currently no NFRs specific to EPS Prescribing systems in this category.

2.3 Infrastructure 2.3.1 Warranted Environment Status: To be Reviewed

ID: EPMVP-NF-20


Originator: Spine WES Subsystem: Client Requirement: Implementers must specify a supported client environment which must be a subset of the Authority’s Warranted Environment Specification


2.3.2 Local Hardware Status: To be Reviewed



ID: EPMVP-NF-21


Originator: EPS Infrastructure Requirements Subsystem: Client Requirement: Implementers must meet the local infrastructure requirements as set out in the document EPS Infrastructure Requirements NPFIT-ETP-EDB-0278.03.


2.3.3 Hardware tagging & configuration management ID: EPMVP-NF-22


Originator: NHS Digital EA policy ‘All IT hardware must be asset tagged and recorded in the HSCIC CMDB’

Subsystem: All hardware Requirement: Implementers should ensure that all connected hardware is tagged and recorded in a configuration management database


2.3.4 Types of storage ID: EPMVP-NF-23


Originator: NHS Digital EA policy ‘permitted types of storage’ Subsystem: Data store Requirement: Systems should use only the following types of storage:

• Direct Attached Storage • Network Attached Storage • SAN storage


2.3.5 Hosting 2.3.5.1 Use approved hosting provider Status: To be Reviewed

ID: EPMVP-NF-24


Originator: NHS Digital EA policy ‘programmes must only utilise HSCIC approved Hosting Partners’

Subsystem: Hosted systems Requirement: Implementers should use only the Authority’s approved hosting provider Further information: -



2.3.5.2 Host PID in England Status: To be Reviewed

ID: EPMVP-NF-25


Originator: NHS Digital EA policy ‘Systems holding PID or allowing N3 access must be located in England’

Subsystem: Hosted systems Requirement: Systems holding Patient Identifiable Data must be hosted in England Further information: - 2.3.5.3 Host in a DC Status: To be Reviewed

ID: EPMVP-NF-26


Originator: NHS Digital EA policy ‘All systems must be hosted in a Data Centre’ Subsystem: Hosted systems Requirement: All hardware components of the system not requiring direct access or providing direct connectivity to the user must be hosted in a data centre.

Further information: - 2.3.5.4 Separate resilience servers Status: To be Reviewed

ID: EPMVP-NF-27


Originator: NHS Digital EA policy ‘Servers that are used to provide resilience should be housed in different chassis and cabinets’

Subsystem: Hosted systems Requirement: Implementers should house servers that are used to provide resilience in separate chassis and cabinets.

Further information: - 2.3.5.5 Production hardware less than 5 years old ID: EPMVP-NF-28


Originator: NHS Digital EA policy ‘All production hardware must be less than 5 years old’ Subsystem: Hosted systems Requirement: Implementers should ensure that all production hardware for hosted components remains less than 5 years old.

Further information: - 2.3.5.6 Hardware cabinets must have two power supplies ID: EPMVP-NF-29




Originator: NHS Digital EA policy ‘Hardware cabinets must have 2 discrete power supplies’

Subsystem: Hosted systems Requirement: Implementers should ensure that hardware cabinets hosting system components have two discrete power supplies.


2.4 Evolution This category describes the ability of the system to be flexible in the face of change post deployment, balanced against the costs of providing such flexibility.

2.4.1 Data Migration 2.4.1.1 Data Migration Extract Status: To be Reviewed

ID: EPMVP-NF-30

Category: Evolution

Originator: EPS Prescribing Systems Compliance Specification 6.16.8 Subsystem: Data store Requirement: The system must make available a data migration extract containing at a minimum data for the previous six months of a given date including:

• Prescription form (electronic or handwritten) • Prescription treatment type (acute) • Prescription ID • Prescription Message UUID • Prescribed date • Patient NHS number • Prescriber / Signer Name • Additional instructions to the patient • Nominated dispenser ODS code • For each prescribed medication item:

o Medication item UUID o Medication dm+d name o Medication dm+d concept ID o Prescribed quantity (included representation in words for Schedule 2/3 controlled drugs)

o Prescribed unit of measure (name and dm+d concept ID) o Dosage instructions o Additional instructions to the patient o Additional instructions to the dispenser o Prescriber endorsements o Cancellation date (if cancelled)




2.4.1.2 Data Migration Extract Availability Status: To be Reviewed

ID: EPMVP-NF-31

Category: Evolution

Originator: EPS Prescribing Systems Compliance Specification 6.16.8 Subsystem: Data store Requirement: The system must make the data migration extract available to the requesting user within 24 hours of the request.

Further information: - 2.4.1.3 Data Migration Extract Format Publication Status: To be Reviewed

ID: EPMVP-NF-32

Category: Evolution

Originator: EPS Prescribing Systems Compliance Specification 6.16.8 Subsystem: Data store Requirement: Implementers must make the technical specification of their data extract format available to the Authority for release to other implementers and users

Further information: - 2.4.1.4 Data Migration Import Status: To be Reviewed

ID: EPMVP-NF-33

Category: Evolution

Originator: EPS Prescribing Systems Compliance Specification 6.16.8 Subsystem: Data store Requirement: Systems must be able to import the minimum data provided within an EPS data migration extract such that the system is able to search, view and cancel imported prescriptions.

Further information: - 2.4.1.5 Data Migration Import Format Publication Status: To be Reviewed

ID: EPMVP-NF-34

Category: Evolution

Originator: EPS Prescribing Systems Compliance Specification 6.16.8 Subsystem: Data store Requirement: Implementers must make the technical specification of their data import format available to the Authority for release to other implementers and users




2.4.2 Release 2.4.2.1 Use of CAP Status: To be Reviewed

ID: EPMVP-NF-35

Category: Evolution

Originator: CAP Subsystem: Entire system Requirement: Implementers must meet the process and material requirements of the Common Assurance Process as agreed with the Authority for each release.

Further information: 2.4.2.2 Test Environments Status: To be Reviewed

ID: EPMVP-NF-36

Category: Evolution

Originator: CAP Subsystem: Entire system Requirement: Systems must provide at least one logically separate environment which can contain a separate release from that in the live environment, and which can be configured to connect to the Authority’s test environments.

Further information: Test environment is required by CAP. 2.4.2.3 Limited Deployment of Releases Status: To be Reviewed

ID: EPMVP-NF-37

Category: Evolution

Originator: CAP Subsystem: Entire system Requirement: Systems must permit a limited rollout of a release to a limited number of user organisations as agreed with the Authority.

Further information: Limited rollout to Live environment is required in reference testing stage in CAP.

2.4.2.4 Technology Refresh & Revision 2.4.2.4.1 Hardware vendor support Status: To be Reviewed

ID: EPMVP-NF-38

Category: Evolution

Originator: NHS Digital EA policy ‘hardware must be and remain in full vendor support’ Subsystem: System hardware



Requirement: Implementers should ensure that all hardware is in full vendor support when deployed and remains in full vendor support throughout the lifetime of the system

2.4.2.4.2 Operating system vendor support Status: To be Reviewed

ID: EPMVP-NF-39

Category: Evolution

Originator: NHS Digital EA policy ‘operating system must be and remain in full vendor support’

Subsystem: Operating system Requirement: Implementers should ensure that all operating system used in the system is in full vendor support when deployed and remains in full vendor support throughout the lifetime of the system.

2.4.2.4.3 Hypervisor and virtualisation service vendor support Status: To be Reviewed

ID: EPMVP-NF-40

Category: Evolution

Originator: NHS Digital EA policy ‘The hypervisor and associated virtualisation service must be in full vendor support and be kept current’

Subsystem: Operating system Requirement: Implementers should ensure that all hypervisors and associated virtualisation services used in the system are in full vendor support when deployed and remain in full vendor support throughout the lifetime of the system.

2.4.2.4.4 Security updates available Status: To be Reviewed

ID: EPMVP-NF-41

Category: Evolution

Originator: CAP Subsystem: Entire system Requirement: Systems must not include any third-party supplied element for which security updates are no longer provided by the supplier/manufacturer.

Further information: 2.4.2.4.5 User input minimal Status: To be Reviewed

ID: EPMVP-NF-42

Category: Evolution

Originator: NHS Digital EA policy ‘The operating system must be securely patched using an automated tool’

Subsystem: Entire system



Requirement: Implementers must deploy software updates and patches with minimal input required by the user

Further information: - 2.4.2.4.6 Automated deployment Status: To be Reviewed

ID: EPMVP-NF-43

Category: Evolution


Subsystem: Entire system Requirement: Implementers must deploy software updates and patches using an automated or largely automated system.

Further information: - 2.4.2.4.7 Deployment of critical patch Status: To be Reviewed

ID: EPMVP-NF-44

Category: Evolution


Subsystem: Entire system Requirement: Implementers must be able to deploy a critical patch to all connected systems within 24 hours

Further information: - 2.4.2.5 Network impact assessment Status: To be Reviewed

ID: EPMVP-NF-45

Category: Evolution

Originator: NHS Digital EA policy ‘Network impacts must be assessed’ Subsystem: Network Requirement: Implementers must assess the impact of the service on existing services and users of the network prior to deployment of the service and ensure that there will be no undue effect.

Further information:

2.5 Performance and Scalability This category describes the ability of the system to predictably execute within its mandated performance profile and to handle processing volumes now and in the future.

2.5.1 Use of QoS Status: To be Reviewed



ID: EPMVP-NF-50

Category: Performance & scalability

Originator: NHS Digital EA Policy ‘Procure Solutions that Support QoS’ & ‘Use QoS traffic markings’

Subsystem: Network service Requirement: Networks hosting the system must correctly employ Quality of Service marking and traffic shaping in accordance with the Authority’s published QoS policy in order to appropriately prioritise network traffic.


2.5.2 Network monitoring & management Status: To be Reviewed

ID: EPMVP-NF-51


Originator: NHS Digital EA Policy ‘Provide a comprehensive network management and monitoring system’

Subsystem: Network Requirement: Networks hosting the system must be actively monitored by automated systems to ensure correct operation and which must provide alarms where a device or group of devices has a fault.

Further Information: -

2.5.3 Network reporting Status: To be Reviewed

ID: EPMVP-NF-52


Originator: NHS Digital EA Policy ‘Network reporting’ Subsystem: Network Requirement: Networks hosting the system must be monitored by tools which provide reporting including latency, jitter, peak & average utilisation and packet loss.


2.5.4 Volumetric model Status: To be Reviewed

ID: EPMVP-NF-53


Originator: NHS Digital EA Policy ‘A volumetric model has been created’ Subsystem: Entire system Requirement: Implementers must produce a volumetric model covering at the minimum transactional throughput, concurrent user connections, storage volumes and details of where headroom must be maintained.




2.5.5 Design for expansion Status: To be Reviewed

ID: EPMVP-NF-54


Originator: - Subsystem: Entire system Requirement: Systems must permit expansion to meet increased capacity requirements. Implementers must define which system elements will have capacity increased by adding to existing resources (vertical scaling/scaling up) and which will have more nodes added (horizontal scaling/scaling out).


2.6 Regulations This category describes the ability of the system to conform to all applicable laws, regulations, NHS policies, and other rules and standards.

2.6.1 Precedence of legislation & professional standards Status: To be Reviewed

ID: EPMVP-NF-60

Category: Regulations

Originator: 5.0.1 Subsystem: Entire system Requirement: Where implementers identify conflicts between this specification and legal or professional rules (e.g. due to changes in the law) they MUST notify the Authority. The authority SHALL review and agree with the implementer how to comply with legislation/rules.


2.6.2 NHS Information Standards Status: To be Reviewed

ID: EPMVP-NF-61


Originator: Subsystem: Entire system Requirement: Systems must comply with all relevant information standards as defined in the Health and Social Care Act 2012 as: "a document containing standards that relate to the processing of information".

Further information: Information standards are available through https://digital.nhs.uk/information-standards

2.6.3 IG Toolkit Status: To be Reviewed



ID: EPMVP-NF-62


Originator: NHS Digital EA policy ‘IGSOC’ Subsystem: Entire system Requirement: Implementers must ensure that all organisations connecting to the system have carried out the IG Toolkit assessment as required by the Authority.

Further information: Information on the IG toolkit is available from https://www.igt.hscic.gov.uk

2.6.4 Service support Status: To be Reviewed

ID: EPMVP-NF-63


Originator: NHS Digital EA policy ‘SM3 – Engagement with National Service Management will take place’

Subsystem: Entire system Requirement: Implementers must meet the Authority’s Service Management Requirements Further information: -

2.7 Security This category describes the ability of the system to reliably control, monitor and audit who can perform action on which resources and the ability to detect and recover from security breaches.

2.7.1 Authentication 2.7.1.1 Implement Smartcard Authentication Status: To be Reviewed

ID: EPMVP-NF-70

Category: Security

Originator: Prescribing system specification 5.1.2 Subsystem: Entire system Requirement: The System MUST implement smartcard-based Spine user authentication as defined by the Authority’s Information Governance requirements.

Further information: - 2.7.1.2 Authentication status available to User Status: To be Reviewed

ID: EPMVP-NF-71

Category: Security

Originator: Prescribing system specification 5.1.2 Subsystem: User interface



Requirement: The System should provide a means whereby the user can identify when they are authenticated with Spine.

Further information: - 2.7.1.3 Endpoint authentication Status: To be Reviewed

ID: EPMVP-NF-72

Category: Security

Originator: NHS Digital EA policy ‘All Functional Access must be made secure’ Subsystem: Entire system Requirement: The System must require all connecting endpoints to be authenticated. Further information: - 2.7.1.4 Implement 2FA Status: To be Reviewed

ID: EPMVP-NF-73

Category: Security

Originator: NHS Digital EA policy ‘Service security architectures must be documented’;; NHS Digital Operational Security Policy

Subsystem: Entire system Requirement: Implementers should require that all system access not requiring smartcard authentication is protected using two factor authentication.


2.7.2 Authorization 2.7.2.1 Implement RBAC Status: To be Reviewed

ID: EPMVP-NF-74

Category: Security

Originator: EPS Prescribing Systems Compliance Specification 5.1.5 Subsystem: Entire system Requirement: The System SHALL implement the Role Based Access requirements defined by the Authority.

Further information: 2.7.2.2 Implement RBAC EPS Baseline Status: To be Reviewed

ID: EPMVP-NF-75

Category: Security

Originator: EPS Prescribing Systems Compliance Specification 5.1.6 Subsystem: Entire system



Requirement: The System must implement the EPS Baseline defined within the National RBAC Database (NRD) including subsequent updates and amendments to the baseline.

Further Information: The National RBAC baseline is defined in NRD27.2-0512. Guidance for how to interpret the activities listed within the EPS Baseline is published within the document “RBAC Implementation Guidance for the EPS” (ref: NPFIT-ETP-EIM-0110).

2.7.2.3 Implement assured access model Status: To be Reviewed

ID: EPMVP-NF-76

Category: Security

Originator: NHS Digital EA policy ‘Systems must implement assured access models’;; NHS Digital Operational Security Policy

Subsystem: Entire system Requirement: The System must implement an assured access model compliant with the Authority’s Operational Security Policy, Control 9 “Managing User Privilege”. This must apply to all user access including for operational administration and management purposes.


2.7.3 Information Governance 2.7.3.1 Implement IG Baseline Status: To be Reviewed

ID: EPMVP-NF-77

Category: Security

Originator: EPS Prescribing Systems Compliance Specification 5.1 Subsystem: Entire system Requirement: The System must implement the authority’s IG requirements as defined in the document IG v3 Foundation Module (ref: NPFIT-FNT-TO-TIN-1383)


2.7.4 Network Security 2.7.4.1 Firewalls Status: To be Reviewed

ID: EPMVP-NF-78

Category: Security

Originator: NHS Digital EA Policy ‘the central network service must be protected through appropriately configured firewalls in line with the requirements of the central security policy’

Subsystem: Network Requirement: Networks hosting the system must be protected at the edge by appropriately configured firewalls




2.7.5 Hardened System Configuration Status: To be Reviewed

ID: EPMVP-NF-79

Category: Security

Originator: NHS Digital EA Policy ‘System configurations must be hardened/locked down’ Subsystem: Entire system Requirement: The system must comply with the Authority’s Operational Security Policy Appendix 1 Subcontrol 6.1: lockdown, and must provide detail of how each component of the system has been locked down


2.7.6 Risk assessment Status: To be Reviewed

ID: EPMVP-NF-80

Category: Security

Originator: NHS Digital EA policy ‘Programmes must perform security risk assessments’ Subsystem: Entire system Requirement: Implementers must carry out a threat and risk assessment following a recognised risk assessment methodology

Further information: Appropriate methodologies include HMG IS1 and ISO/IEC 27005

2.7.7 Physical security Status: To be Reviewed

ID: EPMVP-NF-81

Category: Security

Originator: NHS Digital EA policy ‘All hosting must be in Secure Physical Locations’ Subsystem: System Hosts;; network service Requirement: The system must be hosted in a secure physical location, secured to the standard appropriate to the risk identified by the risk assessment.


2.7.8 Protective monitoring Status: To be Reviewed

ID: EPMVP-NF-82

Category: Security

Originator: NHS Digital EA policy ‘Services must incorporate appropriate protective monitoring functionality’;; NHS Digital Operational Security Policy

Subsystem: System Hosts;; network service



Requirement: The system must incorporate a level of audit and protective monitoring equal or beyond the business impact level identified within the risk profile identified within the risk assessment. Monitoring must include:

• User Activity • System Commands • ‘Significant’ Commands • Privilege Commands • Information exchanges initiated outside of the organization • Information releases to outside of the organization


2.7.9 Audit Logs 2.7.9.1 Security of audit log Status: To be Reviewed

ID: EPMVP-NF-83

Category: Security

Originator: NHS Digital EA policy ‘Service security architectures must be documented’ Subsystem: Entire system Requirement: Systems must secure the audit trail such that it is tamper proof, events are uniquely attributable and non repudiable by both system and user.

Further information: - 2.7.9.2 Auditable events Status: To be Reviewed

ID: EPMVP-NF-84

Category: Security

Originator: NHS Digital EA policy ‘Services must incorporate appropriate protective monitoring functionality’

Subsystem: Entire system Requirement: Systems must include at least the following events in audit logs:

• High priority events

• Repeated TLS authentication failures from a single IP address.

• Any forbidden access attempt recorded between security tiers

• Account lockouts (due to multiple failures) via the service providing operational access.

• Any OSSEC level 071 alert or higher upon any internal server.

• Detection of any denial of service attack such as XML, DNS, NTP

• Any login failure on a live server.

• Any change in the configuration or code. 1 http://www.ossec.net/doc/manual/rules-decoders/rule-levels.html



• Any unexpected connection attempt on an internal firewall2.

• Any CRITICAL log level raised within the application.

• An attempt to use a revoked certificate or simultaneous use of a certificate from multiple addresses.

• Other interesting events

• Any TLS authentication failure.

• Port scans of external addresses.

• Excessive content lengths to content consumers/listeners.

• A high3 volume of OSSEC level 04 alerts (or higher).

• High volume of unexpected connection attempts on any external firewall.

Further information: Appropriate methodologies include HMG IS1 and ISO/IEC 27005

2.7.10 Malicious intent 2.7.10.1 Malware protection Status: To be Reviewed

ID: EPMVP-NF-85

Category: Security


Subsystem: Entire system Requirement: The system must incorporate protection from malware, including the verification of data at points on ingress & egress

Further information: 2.7.10.2 Patch management Status: To be Reviewed

ID: EPMVP-NF-86

Category: Security

Originator: NHS Digital EA policy ‘Service security architectures must be documented’;; NHS Digital EA policy ‘The operating system must be security patched using an automated tool’;; NHS Digital Operational Security Policy

Subsystem: Entire system Requirement: Implementers must provide a system of patch management for hardware, operating systems and applications for all elements of the system.


2 The internal firewalls should be configured with silent drop rules to cover all expected failures (e.g. known multicast/broadcast activity) 3 Threshold to be defined by experience



2.7.10.3 Execution control Status: To be Reviewed

ID: EPMVP-NF-87

Category: Security


Subsystem: Entire system Requirement: The system should ensure that only trusted applications are able to run Further information: - 2.7.10.4 Secure build and configuration Status: To be Reviewed

ID: EPMVP-NF-88

Category: Security


Subsystem: Entire system Requirement: Implementers must ensure that devices connected to the system are built with only the minimum functionality required for the business to function enabled.

Further information: - 2.7.10.5 Automatic deployment of OS Status: To be Reviewed

ID: EPMVP-NF-89

Category: Security

Originator: NHS Digital EA policy ‘Service security architectures must be documented’;; NHS Digital EA policy ‘The operating system must be deployed (and configured) automatically to the target devices ’;; NHS Digital Operational Security Policy

Subsystem: Entire system Requirement: Implementers should ensure that operating systems for all devices connected to the system are deployed and configured automatically

Further information: - 2.7.10.6 Access to sensitive date Status: To be Reviewed

ID: EPMVP-NF-90

Category: Security


Subsystem: Entire system Requirement: Systems must provide tiered access to sensitive data



Further information: 2.7.10.7 Penetration testing Status: To be Reviewed

ID: EPMVP-NF-91

Category: Security


Subsystem: Entire system Requirement: Implementers must appoint and undergo penetration testing of both infrastructure and application by one of the Authority’s approved providers.


2.7.11 Accidental Release 2.7.11.1 Encrypted data at rest in mobile devices Status: To be Reviewed

ID: EPMVP-NF-92

Category: Security


Subsystem: Clients Requirement: Implementers must ensure that all mobile clients connecting to the system have encrypted storage.

Further information: - 2.7.11.2 Remote wipe of mobile devices Status: To be Reviewed

ID: EPMVP-NF-93

Category: Security


Subsystem: Clients Requirement: Implementers must ensure that all mobile clients connecting to the system can be remotely wiped in case of loss

Further information: - 2.7.11.3 Session timeout Status: To be Reviewed

ID: EPMVP-NF-94

Category: Security




Subsystem: Clients Requirement: Implementers must ensure that all clients connecting to the system have an appropriately set session timeout

Further information: - 2.7.11.4 Lock on smartcard removal Status: To be Reviewed

ID: EPMVP-NF-95

Category: Security


Subsystem: Clients Requirement: Implementers should ensure that client applications are locked on removal of the smartcard.


2.8 Usability This category describes the ease with which people who interact with the system can work effectively.

2.8.1.1 Use NHS CUI standard Status: To be Reviewed

ID: EPMVP-NF-100

Category: Usability

Originator: - Subsystem: User interface Requirement: The System should use the NHS Common User Interface standards to present clinical and demographic information.

Further Information: - 2.8.1.2 Use user centred design Status: To be Reviewed

ID: EPMVP-NF-101

Category: Usability

Originator: Subsystem: User interface Requirement: Implementers should use user-centred design principles when designing user interface

Further Information: - 2.8.1.3 Training material availability Status: To be Reviewed

ID: EPMVP-NF-102



Category: Usability

Originator: Subsystem: User interface Requirement: Implementers must provide user training materiel specific to each release Further Information: - 2.8.1.4 Design and research roles Status: To be Reviewed

ID: EPMVP-NF-103

Category: Usability

Originator: NHS Digital EA policy ‘Design and Research roles are part of the delivery team’

Subsystem: User interface Requirement: Implementers should include design and research roles within their delivery team

Further Information: 2.8.1.5 Completion rate reporting Status: To be Reviewed

ID: EPMVP-NF-104

Category: Usability

Originator: NHS Digital EA policy ‘Test the solution meets the required completion rate in all 4 GDS stages’

Subsystem: User interface Requirement: Implementers should record and report on user transaction completion rates during CAP. Completion rates shall be calculated by identifying the number of completed transactions divided by the number of started transactions expressed as a percentage.

Further Information: 2.8.1.6 Plan for ongoing user research and testing Status: To be Reviewed

ID: EPMVP-NF-105

Category: Usability

Originator: NHS Digital EA policy ‘Put a plan in place for ongoing user research and usability testing’

Subsystem: User interface Requirement: Implementers should plan to provide ongoing user research and usability testing with appropriately skilled resources in place.

Further Information:





3 Release Summary To be Reviewed: EPMVP-NF-1: Maintenance Periods

EPMVP-NF-2: Communication of planned outages

EPMVP-NF-3: Data Retention Periods

EPMVP-NF-4: Regular backup

EPMVP-NF-5: Backup validation

EPMVP-NF-6: Hardware maintenance contract

EPMVP-NF-7: RTO 4 hour

EPMVP-NF-8: RTO 1 day

EPMVP-NF-9: Redundant network

EPMVP-NF-10: Network in scope of DR/BC

EPMVP-NF-11: RPO 1 hour

EPMVP-NF-12: RPO 1 day

EPMVP-NF-20: Warranted Environment

EPMVP-NF-21: Local Hardware

EPMVP-NF-22: Hardware tagging & configuration management

EPMVP-NF-23: Types of storage

EPMVP-NF-24: Use approved hosting provider

EPMVP-NF-25: Host PID in England

EPMVP-NF-26: Host in a DC

EPMVP-NF-27: Separate resilience servers

EPMVP-NF-28: Production hardware less than 5 years old

EPMVP-NF-29: Hardware cabinets must have two power supplies

EPMVP-NF-30: Data Migration Extract

EPMVP-NF-31: Data Migration Extract Availability

EPMVP-NF-32: Data Migration Extract Format Publication

EPMVP-NF-33: Data Migration Import

EPMVP-NF-34: Data Migration Import Format Publication

EPMVP-NF-35: Use of CAP

EPMVP-NF-36: Test Environments

EPMVP-NF-37: Limited Deployment of Releases

EPMVP-NF-38: Hardware vendor support

EPMVP-NF-39: Operating system vendor support

EPMVP-NF-40: Hypervisor and virtualisation service vendor support



EPMVP-NF-41: Security updates available

EPMVP-NF-42: User input minimal

EPMVP-NF-43: Automated deployment

EPMVP-NF-44: Deployment of critical patch

EPMVP-NF-45: Network impact assessment

EPMVP-NF-50: Use of QoS

EPMVP-NF-51: Network monitoring & management

EPMVP-NF-52: Network reporting

EPMVP-NF-53: Volumetric model

EPMVP-NF-54: Design for expansion

EPMVP-NF-60: Precedence of legislation & professional standards

EPMVP-NF-61: NHS Information Standards

EPMVP-NF-62: IG Toolkit

EPMVP-NF-63: Service support

EPMVP-NF-70: Implement Smartcard Authentication

EPMVP-NF-71: Authentication status available to User

EPMVP-NF-72: Endpoint authentication

EPMVP-NF-73: Implement 2FA

EPMVP-NF-74: Implement RBAC

EPMVP-NF-75: Implement RBAC EPS Baseline

EPMVP-NF-76: Implement assured access model

EPMVP-NF-77: Implement IG Baseline

EPMVP-NF-78: Firewalls

EPMVP-NF-79: Hardened System Configuration

EPMVP-NF-80: Risk assessment

EPMVP-NF-81: Physical security

EPMVP-NF-82: Protective monitoring

EPMVP-NF-83: Security of audit log

EPMVP-NF-84: Auditable events

EPMVP-NF-85: Malware protection

EPMVP-NF-86: Patch management

EPMVP-NF-87: Execution control

EPMVP-NF-88: Secure build and configuration

EPMVP-NF-89: Automatic deployment of OS

EPMVP-NF-90: Access to sensitive date



EPMVP-NF-91: Penetration testing

EPMVP-NF-92: Encrypted data at rest in mobile devices

EPMVP-NF-93: Remote wipe of mobile devices

EPMVP-NF-94 : Session timeout

EPMVP-NF-95: Lock on smartcard removal

EPMVP-NF-100: Use NHS CUI standard

EPMVP-NF-101: Use user centred design

EPMVP-NF-102: Training material availability

EPMVP-NF-103: Design and research roles

EPMVP-NF-104: Completion rate reporting

EPMVP-NF-105: Plan for ongoing user research and testing

Issued - No Change: Issued - Changed: Deprecated: Second Review:

4 Guide to Non-Functional Requirement Statuses The descriptions that may be assigned to indicate the current status of a non-functional requirement are detailed in Table 3.

Table 3 – Non-Functional Requirement Statuses Status Usage Follow On Status

To be Reviewed An NFR extracted from existing documentation and added to the NFRS prior to any analysis.

The NFR has not been issued.

Issued – No Change

Issued – Change

Deprecated

Second Review

Issued – No Change The NFR has been reviewed with no material changes made.

None

Issued – Changed The NFR has been reviewed with material changes made, or

a new NFR has been created to replace one or more existing NFRs.

None

Deprecated An existing NFR is no longer applicable or has been replaced.

None

Second Review The NFR has been reviewed but further elaboration is required. Once amended the item will be put forward for second review.

Issued – No Change

Issued – Change

Deprecated



5 References

Referenced EPS Requirements Specifications: 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

NPFIT-ETP-EDB-0280 Nomination Requirements for System Suppliers

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

Message Implementation Manual v3.1.07

Message Implementation Manual v4.2.00

EPS Domain Message Specification v3.4.0

NPFIT-ETP-EDB-0027 EPS Prescription Token Specification

NPFIT-ETP-EDB-0064 ETP Message Signing Requirements

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-PC-PMG-DEL-0020 GPSOC-R Data Migration Specification

NHSBSA Overprint Specification for NHS Prescriptions

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

NPFIT- ETP-EIM-0132 Guidance for suppliers on the validation script

NPFIT-ETP-EIM-0015 Guidance for Endorsement

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

dm+d Implementation Guide (Primary Care)

NPFIT-ETP-BUS-0017 EPS R2 Training and Guidance Strategy

NPFIT-ETP-EDB-0104 Digital Signature Toolkit Guidance

NPFIT-ETP-EDB-0301 ETP Web Services Client source code

NPFIT-ETP-EDB-0103 MIM 3.1.07 & 4.2.00 Compatibility Guidance

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

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