EPS Prescribing System MVP - Non-Functional Requirements

Transcription

1 Document filename: EPS Prescribing System MVP Non Functional Specification.docx Directorate / Programme Document Reference Domain E Project Project Manager Jo Lambe Status Draft Owner Aled Greenhalgh Version 0.4 Digitising Community Pharmacy & Medicines Author Aled Greenhalgh Version issue date 26 Jan 2018 EPS Prescribing System MVP - Non-Functional Requirements Copyright 2018 Health and Social Care Information Centre

2 Document Management Revision History Version Date Summary of Changes /05/17 Branched from EPS Prescribing Systems Compliance Specification /06/ /01/18 Reformatted to use NHS Digital EA NFR template Included requirements relating to NHS Digital EA policies Reduced level of mandation for a number of requirements in order to focus assurance /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 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 Rich Cole, DCPM Programme Manager Rob Gooch, Domain E Lead Architect Not Approved Not Approved Not Approved Page 2 of 36

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

4 NFR NFRS NHS SAD SME TAID UI WAI Non-Functional Requirement Non-Functional Requirements Specification National Health Service System Architecture Document Subject Matter Expert Technical Architecture & Infrastructure Directorate User Interface 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, attachment), are considered to have passed out of control and should be checked for currency and validity. Page 4 of 36

5 Contents 1 Introduction Purpose Audience Requirements Categories System Scope Approach 8 2 Non-Functional Requirements Accessibility Availability and Resilience Infrastructure Evolution Performance and Scalability Regulations Usability 30 3 Release Summary 33 4 Guide to Non-Functional Requirement Statuses 35 5 References 36 Page 5 of 36

6 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 nonfunctional 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 DCMP Programme Solution Architects Developers System Testers Solutions Assurance Service Operations Teams Live Service Support Suppliers Reason To understand and validate the interpretation of the business non-functional requirements that the solution must support. To understand the business non-functional requirements that constrain system design. To understand the business non-functional requirements that the system must be developed to meet. To understand the business non-functional requirements and ensure system testing is designed and carried out to validate these correctly. To understand the business non-functional requirements that they must assure the system against. To understand and validate the interpretation of the business non-functional requirements that the solution must support. To ensure the components of the solution that they are contracted to provide support for meet the requirements as set out within this artefact. Page 6 of 36

7 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 Accessibility Category Availability and Resilience Evolution Performance and Scalability Regulations & Auditing Usability Desired Characteristic The ability of the system to be used by people with disabilities. 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. 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. The ability of the system to execute within its mandated performance profile and to handle processing volumes now and in the future. The ability of the system to conform to all applicable laws, regulations, company policies, and other rules and standards. 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. 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 Page 7 of 36

8 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 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 Page 8 of 36

9 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 Service availability Maintenance Periods Second Review EPMVP-NF-1 Service Availability Originator: - Requirement: Implementers should define regular maintenance periods during which users may expect all or part of the system to be unavailable Communication of planned outages Second Review EPMVP-NF-2 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 Data Retention Data Retention Periods EPMVP-NF-3 Availability and Resilience Originator: GPSoC Schedule 1.7, 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) Page 9 of 36

10 A further 20 years off-line, recoverable within 1 working week (Years 11 to 30 inclusive) Backup & Recovery Regular backup EPMVP-NF-4 Availability and Resilience 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 Backup validation EPMVP-NF-5 Availability and Resilience Originator: - Subsystem: Data store Requirement: Implementers should validate backups by conducting a recovery from backup exercise at least annually and at least once prior to initial deployment Time to Repair Hardware maintenance contract EPMVP-NF-6 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 RTO 4 hour EPMVP-NF-7 Infrastructure Originator: Page 10 of 36

11 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 RTO 1 day Originator: EPMVP-NF-8 Infrastructure Requirement: Systems should meet the Recovery Time Objective of 24 hours for the following datasets and systems: All client data and systems 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 Business Continuity Redundant network EPMVP-NF-9 Infrastructure 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 Network in scope of DR/BC EPMVP-NF-10 Infrastructure 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 Page 11 of 36

12 2.2.7 Data Loss RPO 1 hour Originator: EPMVP-NF-11 Infrastructure Subsystem: Data store Requirement: Systems should meet the Recovery Point Objective of 1 hour for the following datasets: Prescriptions issued Audit data RPO 1 day Originator: EPMVP-NF-12 Infrastructure Subsystem: Data store Requirement: Systems should meet the Recovery Point Objective of 24 hours for the following datasets: Cancellation data Record Corruption There are currently no NFRs specific to EPS Prescribing systems in this category. 2.3 Infrastructure Warranted Environment EPMVP-NF-20 Infrastructure 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 Local Hardware Page 12 of 36

13 EPMVP-NF-21 Infrastructure 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 Hardware tagging & configuration management EPMVP-NF-22 Infrastructure 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 Types of storage EPMVP-NF-23 Infrastructure 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 Hosting Use approved hosting provider EPMVP-NF-24 Infrastructure 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 Page 13 of 36

14 Host PID in England Deprecated EPMVP-NF-25 Infrastructure 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 Host in a DC EPMVP-NF-26 Infrastructure 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 should be hosted in a data centre Separate resilience servers EPMVP-NF-27 Infrastructure 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 Production hardware less than 5 years old EPMVP-NF-28 Infrastructure 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 Hardware cabinets must have two power supplies EPMVP-NF-29 Page 14 of 36

15 Infrastructure 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 Make use of public cloud in accordance with the Authority s guidance EPMVP-NF-29.1 Infrastructure Originator: NHS Digital, DH, NHS England & NHS Improvement joint policy NHS and social care data: off-shoring and the use of public cloud services Subsystem: Hosted systems 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 [ NHS Digital Health and Social Care Cloud Good Practice Guide [ NHS Digital Health and Social Care Cloud Risk Framework [ 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 Data Migration Data Migration Extract EPMVP-NF-30 Evolution Originator: EPS Prescribing Systems Compliance Specification Subsystem: Data store 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) Page 15 of 36

16 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) Data Migration Extract Availability EPMVP-NF-31 Evolution Originator: EPS Prescribing Systems Compliance Specification Subsystem: Data store Requirement: The system should make the data migration extract available to the requesting user within 24 hours of the request Data Migration Extract Format Publication EPMVP-NF-32 Evolution Originator: EPS Prescribing Systems Compliance Specification Subsystem: Data store Requirement: Implementers should make the technical specification of their data extract format available to the Authority for release to other implementers and users Data Migration Import EPMVP-NF-33 Evolution Page 16 of 36

17 Originator: EPS Prescribing Systems Compliance Specification Subsystem: Data store 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 Data Migration Import Format Publication EPMVP-NF-34 Evolution Originator: EPS Prescribing Systems Compliance Specification Subsystem: Data store Requirement: Implementers should make the technical specification of their data import format available to the Authority for release to other implementers and users Release Use of CAP EPMVP-NF-35 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. Further information: Test Environments EPMVP-NF-36 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 Limited Deployment of Releases EPMVP-NF-37 Page 17 of 36

18 Originator: CAP Evolution 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 Technology Refresh & Revision Hardware vendor support EPMVP-NF-38 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 Operating system vendor support EPMVP-NF-39 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 Hypervisor and virtualisation service vendor support EPMVP-NF-40 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 updates available EPMVP-NF-41 Page 18 of 36

19 Originator: CAP Evolution Requirement: Systems must not include any third-party supplied element for which security updates are no longer provided by the supplier/manufacturer. Further information: User input minimal EPMVP-NF-42 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 Automated deployment EPMVP-NF-43 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 using an automated or largely automated system Deployment of critical patch EPMVP-NF-44 Evolution Originator: NHS Digital EA policy The operating system must be securely patched using an automated tool Requirement: Implementers must be able to deploy a critical patch to all connected systems within 24 hours Network impact assessment Page 19 of 36

20 EPMVP-NF-45 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 Use of QoS EPMVP-NF-50 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 Network monitoring & management EPMVP-NF-51 Performance & scalability 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: Network reporting EPMVP-NF-52 Performance & scalability Originator: NHS Digital EA Policy Network reporting Page 20 of 36

21 Subsystem: Network Requirement: Networks hosting the system must be monitored by tools which provide reporting including latency, jitter, peak & average utilisation and packet loss. Further Information: Volumetric model EPMVP-NF-53 Performance & scalability 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. Further Information: Design for expansion Originator: - EPMVP-NF-54 Performance & scalability 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). Further Information: Regulations This category describes the ability of the system to conform to all applicable laws, regulations, NHS policies, and other rules and standards Precedence of legislation & professional standards Originator: EPMVP-NF-60 Regulations 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. Page 21 of 36

22 2.6.2 NHS Information Standards EPMVP-NF-61 Regulations 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 IG Toolkit EPMVP-NF-62 Regulations 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 Service support EPMVP-NF-63 Regulations 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 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 Authentication Implement Smartcard Authentication EPMVP-NF-70 Page 22 of 36

23 Originator: Prescribing system specification Requirement: The System MUST implement smartcard-based Spine user authentication as defined by the Authority s Information Governance requirements Authentication status available to User EPMVP-NF-71 Originator: Prescribing system specification Subsystem: User interface Requirement: The System should provide a means whereby the user can identify when they are authenticated with Spine Endpoint authentication EPMVP-NF-72 Originator: NHS Digital EA policy All Functional Access must be made secure Requirement: The System must require all connecting endpoints to be authenticated Implement 2FA EPMVP-NF-73 Originator: NHS Digital EA policy Service security architectures must be documented ; NHS Digital Operational Policy Requirement: Implementers should require that all system access not requiring smartcard authentication is protected using two factor authentication Authorization Implement RBAC EPMVP-NF-74 Page 23 of 36

24 Originator: EPS Prescribing Systems Compliance Specification Requirement: The System SHALL implement the Role Based Access requirements defined by the Authority. Further information: Implement RBAC EPS Baseline EPMVP-NF-75 Originator: EPS Prescribing Systems Compliance Specification 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 NRD 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) Implement assured access model EPMVP-NF-76 Originator: NHS Digital EA policy Systems must implement assured access models ; NHS Digital Operational Policy Requirement: The System should implement an assured access model compliant with the Authority s Operational Policy, Control 9 Managing User Privilege. This must apply to all user access including for operational administration and management purposes. Further Information: Information Governance Implement IG Baseline EPMVP-NF-77 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) Page 24 of 36

25 Further Information: Network Firewalls EPMVP-NF-78 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 Further Information: Hardened System Configuration EPMVP-NF-79 Originator: NHS Digital EA Policy System configurations must be hardened/locked down Requirement: The system must comply with the Authority s Operational Policy Appendix 1 Subcontrol 6.1: lockdown, and must provide detail of how each component of the system has been locked down Further Information: Risk assessment EPMVP-NF-80 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 Physical security EPMVP-NF-81 Originator: NHS Digital EA policy All hosting must be in Secure Physical Locations Subsystem: System Hosts; network service Page 25 of 36

26 Requirement: The system must be hosted in a secure physical location, secured to the standard appropriate to the risk identified by the risk assessment. Further information: Protective monitoring EPMVP-NF-82 Originator: NHS Digital EA policy Services must incorporate appropriate protective monitoring functionality ; NHS Digital Operational 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 Further information: Audit Logs of audit log EPMVP-NF-83 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 Auditable events EPMVP-NF-84 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 Page 26 of 36

27 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 07 1 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 firewall 2. 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 high 3 volume of OSSEC level 04 alerts (or higher). High volume of unexpected connection attempts on any external firewall Malicious intent Malware protection EPMVP-NF-85 Originator: NHS Digital EA policy Service security architectures must be documented ; NHS Digital Operational Policy Requirement: The system must incorporate protection from malware, including the verification of data at points on ingress & egress Patch management 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 Page 27 of 36

28 EPMVP-NF-86 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 Policy Requirement: Implementers must provide a system of patch management for hardware, operating systems and applications for all elements of the system Execution control EPMVP-NF-87 Originator: NHS Digital EA policy Service security architectures must be documented ; NHS Digital Operational Policy Requirement: The system should ensure that only trusted applications are able to run Secure build and configuration EPMVP-NF-88 Originator: NHS Digital EA policy Service security architectures must be documented ; NHS Digital Operational Policy Requirement: Implementers should ensure that devices connected to the system are built with only the minimum functionality required for the business to function enabled Automatic deployment of OS EPMVP-NF-89 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 Policy Requirement: Implementers should ensure that operating systems for all devices connected to the system are deployed and configured automatically Page 28 of 36

29 Access to sensitive date EPMVP-NF-90 Originator: NHS Digital EA policy Service security architectures must be documented ; NHS Digital Operational Policy Requirement: Systems must provide tiered access to sensitive data Further information: Penetration testing EPMVP-NF-91 Originator: NHS Digital EA policy Service security architectures must be documented ; NHS Digital Operational Policy Requirement: Implementers must appoint and undergo penetration testing of both infrastructure and application by one of the Authority s approved providers Accidental Release Encrypted data at rest in mobile devices EPMVP-NF-92 Originator: NHS Digital EA policy Service security architectures must be documented ; NHS Digital Operational Policy Subsystem: Clients Requirement: Implementers must ensure that all mobile clients connecting to the system have encrypted storage Remote wipe of mobile devices EPMVP-NF-93 Originator: NHS Digital EA policy Service security architectures must be documented ; NHS Digital Operational Policy Subsystem: Clients Page 29 of 36

30 Requirement: Implementers should ensure that all mobile clients connecting to the system can be remotely wiped in case of loss Session timeout EPMVP-NF-94 Originator: NHS Digital EA policy Service security architectures must be documented ; NHS Digital Operational Policy Subsystem: Clients Requirement: Implementers must ensure that all clients connecting to the system have an appropriately set session timeout Lock on smartcard removal EPMVP-NF-95 Originator: NHS Digital EA policy Service security architectures must be documented ; NHS Digital Operational Policy 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 Use NHS CUI standard EPMVP-NF-100 Usability Originator: - Subsystem: User interface Requirement: The System should use the NHS Common User Interface standards to present clinical and demographic information. Further Information: Use user centred design EPMVP-NF-101 Page 30 of 36

31 Usability Originator: Subsystem: User interface Requirement: Implementers should use user-centred design principles when designing user interface Further Information: Training material availability EPMVP-NF-102 Usability Originator: Subsystem: User interface Requirement: Implementers must provide user training materiel specific to each release Further Information: Design and research roles EPMVP-NF-103 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: Completion rate reporting EPMVP-NF-104 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: Plan for ongoing user research and testing EPMVP-NF-105 Page 31 of 36

32 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: Page 32 of 36

33 3 Release Summary : 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 Page 33 of 36

34 EPMVP-NF-40: Hypervisor and virtualisation service vendor support EPMVP-NF-41: 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: 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 Page 34 of 36

35 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 Issued No Change Issued Changed Deprecated Second Review An NFR extracted from existing documentation and added to the NFRS prior to any analysis. The NFR has not been issued. The NFR has been reviewed with no material changes made. The NFR has been reviewed with material changes made, or a new NFR has been created to replace one or more existing NFRs. An existing NFR is no longer applicable or has been replaced. 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 Second Review None None None Issued No Change Issued Change Deprecated Page 35 of 36

36 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 v 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 & 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 [ NHS Digital Health and Social Care Cloud Good Practice Guide [ NHS Digital Health and Social Care Cloud Risk Framework [ Page 36 of 36