eps prescribing system mvp - non-functional …...the non-functional requirements of a system (also...

Copyright ©2018 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.4

Author Aled Greenhalgh Version issue date 26 Jan 2018

EPS Prescribing System MVP - Non-Functional Requirements

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

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

0.3 17/01/18 Reduced level of mandation for a number of requirements in order to focus assurance.

0.4 26/01/18 Updated in the light of policy on Cloud hosting.

Reviewers

This document must be reviewed by the following people:

Reviewer name Title / Responsibility Date Version

DCPM Programme Manager Not reviewed 0.3

Domain B Clinical Lead Not reviewed 0.3

Domain B Lead Architect Not reviewed 0.3

Domain E Clinical Lead Not reviewed 0.3

Domain E Lead Architect Not reviewed 0.3

Implementation Manager Not reviewed 0.3

NHS BSA Not reviewed 0.3

NHS Digital Solutions Assurance Non Functional Test Team Not reviewed 0.3

NHS Digital Operational Security Team Not reviewed 0.3

NHS Digital Service Management Lead Not reviewed 0.3

Approved by

This document must be approved by the following people:

Name Signature Title Date Version

Vishen Ramkisson , Domain E Clinical Lead

Not Approved

0.4

Rich Cole, DCPM Programme Manager

Not Approved

0.4

Rob Gooch, Domain E Lead Architect

Not Approved

0.4



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)

Implementer Implementer refers to any party directly responsible for delivering or managing systems. The identity of implementers will vary per instance according to the technical setup and commercial agreement in place.

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

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

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



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 20

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: Second Review

ID: EPMVP-NF-1

Category: Service Availability

Originator: -

Subsystem: Entire system

Requirement: Implementers should 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: Second Review

ID: EPMVP-NF-2

Category: Service Availability

Originator: -


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


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


ID: EPMVP-NF-4


Originator: -

Subsystem: Data store

Requirement: Systems must back up data sufficiently to meet the RPO’s and RTO’s defined by the clinical and technical risk assessment.

Further information: -

2.2.3.2 Backup validation


ID: EPMVP-NF-5


Originator: -


Requirement: Implementers should validate backups by conducting a recovery from backup exercise at least annually and at least once prior to initial deployment.


2.2.4 Time to Repair

2.2.4.1 Hardware maintenance contract


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 should 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


ID: EPMVP-NF-7


Originator:




Requirement: Systems should 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


ID: EPMVP-NF-8


Originator:


Requirement: Systems should 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


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 should be fully redundant


2.2.6.2 Network in scope of DR/BC


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 should 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


ID: EPMVP-NF-11


Originator:


Requirement: Systems should meet the Recovery Point Objective of 1 hour for the following datasets:

Prescriptions issued

Audit data


2.2.7.2 RPO 1 day


ID: EPMVP-NF-12


Originator:


Requirement: Systems should 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


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




ID: EPMVP-NF-21


Originator: EPS Infrastructure Requirements

Subsystem: Client

Requirement: Implementers must meet the local hardware 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’


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


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




2.3.5.2 Host PID in England

Status: Deprecated

ID: EPMVP-NF-25


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


Requirement: Systems holding Patient Identifiable Data must be hosted in England


2.3.5.3 Host in a DC


ID: EPMVP-NF-26


Originator: NHS Digital EA policy ‘All systems must be hosted in a Data Centre’


Requirement: All hardware components of the system not requiring direct access or providing direct connectivity to the user should be hosted in a data centre.


2.3.5.4 Separate resilience servers


ID: EPMVP-NF-27


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


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


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’


Requirement: Implementers should ensure that all production hardware for hosted components remains less than 5 years old.


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’


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


2.3.5.7 Make use of public cloud in accordance with the Authority’s guidance

ID: EPMVP-NF-29.1


Originator: NHS Digital, DH, NHS England & NHS Improvement joint policy ‘NHS and social care data: off-shoring and the use of public cloud services’


Requirement: Implementers must ensure that any use of public cloud is consistent with the Authority’s guidance on off-shoring and the use of public cloud services

Further information:

Guidance & policy is provided in the documents:

NHS Digital, DH, NHS England & NHS Improvement NHS and social care data: off-shoring and the use of public cloud services [https://www.digital.nhs.uk/article/8499/NHS-and-social-care-data-off-shoring-and-the-use-of-public-cloud-services-guidance]

NHS Digital Health and Social Care Cloud Security – Good Practice Guide [https://www.digital.nhs.uk/article/8491/Health-and-social-care-cloud-security-good-practice-guide]

NHS Digital Health and Social Care Cloud Risk Framework [https://www.digital.nhs.uk/Health-and-social-care-data-risk-model]

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


ID: EPMVP-NF-30

Category: Evolution

Originator: EPS Prescribing Systems Compliance Specification 6.16.8


Requirement: The system should 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


ID: EPMVP-NF-31

Category: Evolution



Requirement: The system should make the data migration extract available to the requesting user within 24 hours of the request.


2.4.1.3 Data Migration Extract Format Publication


ID: EPMVP-NF-32

Category: Evolution



Requirement: Implementers should make the technical specification of their data extract format available to the Authority for release to other implementers and users


2.4.1.4 Data Migration Import


ID: EPMVP-NF-33

Category: Evolution





Requirement: Systems should 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.


2.4.1.5 Data Migration Import Format Publication


ID: EPMVP-NF-34

Category: Evolution



Requirement: Implementers should 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


ID: EPMVP-NF-35

Category: Evolution

Originator: CAP


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


2.4.2.2 Test Environments


ID: EPMVP-NF-36

Category: Evolution

Originator: CAP


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


ID: EPMVP-NF-37



Category: Evolution

Originator: CAP


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


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


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


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


ID: EPMVP-NF-41



Category: Evolution

Originator: CAP


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


2.4.2.4.5 User input minimal


ID: EPMVP-NF-42

Category: Evolution

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


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


2.4.2.4.6 Automated deployment


ID: EPMVP-NF-43

Category: Evolution



Requirement: Implementers should deploy software updates and patches using an automated or largely automated system.


2.4.2.4.7 Deployment of critical patch


ID: EPMVP-NF-44

Category: Evolution



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


2.4.2.5 Network impact assessment




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.


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


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


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


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


ID: EPMVP-NF-53


Originator: NHS Digital EA Policy ‘A volumetric model has been created’


Requirement: Implementers should 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


ID: EPMVP-NF-54


Originator: -


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


ID: EPMVP-NF-60

Category: Regulations

Originator: 5.0.1


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


ID: EPMVP-NF-61


Originator:


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


ID: EPMVP-NF-62


Originator: NHS Digital EA policy ‘IGSOC’


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


ID: EPMVP-NF-63


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


Requirement: Implementers must meet the Authority’s Service Management Requirements


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


ID: EPMVP-NF-70



Category: Security

Originator: Prescribing system specification 5.1.2


Requirement: The System MUST implement smartcard-based Spine user authentication as defined by the Authority’s Information Governance requirements.


2.7.1.2 Authentication status available to User


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.


2.7.1.3 Endpoint authentication


ID: EPMVP-NF-72

Category: Security

Originator: NHS Digital EA policy ‘All Functional Access must be made secure’


Requirement: The System must require all connecting endpoints to be authenticated.


2.7.1.4 Implement 2FA


ID: EPMVP-NF-73

Category: Security

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


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


ID: EPMVP-NF-74



Category: Security



Requirement: The System SHALL implement the Role Based Access requirements defined by the Authority.


2.7.2.2 Implement RBAC EPS Baseline


ID: EPMVP-NF-75

Category: Security



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


ID: EPMVP-NF-76

Category: Security

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


Requirement: The System should 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


ID: EPMVP-NF-77

Category: Security

Originator: EPS Prescribing Systems Compliance Specification 5.1


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


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


ID: EPMVP-NF-79

Category: Security

Originator: NHS Digital EA Policy ‘System configurations must be hardened/locked down’


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


ID: EPMVP-NF-80

Category: Security

Originator: NHS Digital EA policy ‘Programmes must perform security risk assessments’


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


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


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 should 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


ID: EPMVP-NF-83

Category: Security

Originator: NHS Digital EA policy ‘Service security architectures must be documented’


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.


2.7.9.2 Auditable events


ID: EPMVP-NF-84

Category: Security

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


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.

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.


2.7.10 Malicious intent

2.7.10.1 Malware protection


ID: EPMVP-NF-85

Category: Security



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


2.7.10.2 Patch management


1 http://www.ossec.net/doc/manual/rules-decoders/rule-levels.html

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



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


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


2.7.10.3 Execution control


ID: EPMVP-NF-87

Category: Security



Requirement: The system should ensure that only trusted applications are able to run


2.7.10.4 Secure build and configuration


ID: EPMVP-NF-88

Category: Security



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


2.7.10.5 Automatic deployment of OS


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


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




2.7.10.6 Access to sensitive date


ID: EPMVP-NF-90

Category: Security



Requirement: Systems must provide tiered access to sensitive data


2.7.10.7 Penetration testing


ID: EPMVP-NF-91

Category: Security



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


ID: EPMVP-NF-92

Category: Security


Subsystem: Clients

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


2.7.11.2 Remote wipe of mobile devices


ID: EPMVP-NF-93

Category: Security


Subsystem: Clients



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


2.7.11.3 Session timeout


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


2.7.11.4 Lock on smartcard removal


ID: EPMVP-NF-95

Category: Security


Subsystem: Clients

Requirement: Implementers must 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


ID: EPMVP-NF-100

Category: Usability

Originator: -


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


2.8.1.2 Use user centred design


ID: EPMVP-NF-101



Category: Usability

Originator:


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


2.8.1.3 Training material availability


ID: EPMVP-NF-102

Category: Usability

Originator:


Requirement: Implementers must provide user training materiel specific to each release


2.8.1.4 Design and research roles


ID: EPMVP-NF-103

Category: Usability

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


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

Further Information:

2.8.1.5 Completion rate reporting


ID: EPMVP-NF-104

Category: Usability

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


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.


2.8.1.6 Plan for ongoing user research and testing


ID: EPMVP-NF-105



Category: Usability

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


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




3 Release Summary

To be Reviewed:

EPMVP-NF-29.1:

Issued - No Change:

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-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 - Changed:

Deprecated:

EPMVP-NF-25: Host PID in England

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-FNT-TO-DSD-0083 Native use of dm+d Definition Message Implementation Manual v4.2.00 EPS Domain Message Specification v3.4.0 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 NHSBSA Overprint Specification for NHS Prescriptions

Related Guidance Documents:

NPFIT-PC-PMG-DEL-0020 GPSOC-R Data Migration Specification NPFIT-ETP-EDB-0027 EPS Prescription Token Specification NPFIT-ETP-EIM-0110 RBAC Implementation Guidance for the EPS R2 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-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 NHS Digital, DH, NHS England & NHS Improvement NHS and social care data: off-shoring and the use of public cloud services [https://www.digital.nhs.uk/article/8499/NHS-and-social-care-data-off-shoring-and-the-use-of-public-cloud-services-guidance] NHS Digital Health and Social Care Cloud Security – Good Practice Guide [https://www.digital.nhs.uk/article/8491/Health-and-social-care-cloud-security-good-practice-guide] NHS Digital Health and Social Care Cloud Risk Framework [https://www.digital.nhs.uk/Health-and-social-care-data-risk-model]