NHSmail 2 Solution Architecture

Transcription

1 Document filename: NHSmail 2 Solution Architecture Directorate / Programme NHSmail Project NHSmail 2 Document Reference Status Approved Programme Manager Mark Reynolds Version 1.2 Author Clive Star Version issue date 10/09/2014 NHSmail 2 Solution Architecture

2 Document Management Revision History Version Date Summary of Changes /03/2014 Initial Draft 1 10/03/2014 Updated following review /04/2014 Updated to show alignment with HSCIC Enterprise Architecture /09/2014 Updated to reflect insecure gateway as core. Approved by This document must be approved by the following people: Name Signature Title Date Version Mark Reynolds NHSmail 2 Programme Director 10/09/ Glossary of Terms Term / Abbreviation AGG AVAS DH GDS GSi HSCIC OBC PSN TDA What it stands for HSCIC Architecture Governance Group Anti-virus Anti-Spam Department of Health Government Digital Service Government Security intranet Health & Social Care Information Centre Outline Business Case Public Services Network Technical Design Authority Document Control: The controlled copy of this document is maintained in the HSCIC 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 2 of 31

3 Contents 1 Introduction Purpose Audience Background 5 2 Strategy Organisation Context Vision Alignment Future Expansion Opportunities and Localism Principles Requirements 10 3 Breakdown of Core Components Secure Secure Gateway Mobile Device Management White Pages & Directory Service Insecure Gateway 17 4 Breakdown of Optional Components Instant Messaging and Collaboration Remote Storage 19 5 Common Components Access Networking Administration Onboarding and Offboarding Information Security Identity Management Service Management Customer Service Data Retention and Compliance Reporting 25 6 Alignment to ICT Principles 27 Page 3 of 31

4 7 Governance 30 8 Risks 31 Page 4 of 31

5 1 Introduction 1.1 Purpose This document provides the high level solution architecture for the NHSmail 2 service. It outlines the conceptual scope of the solution and the logical services the solution will provide. The physical architecture is outside of the scope of this document as that will be provided by the solution vendor(s). This document excludes the SMS and fax services as these will no longer be provided centrally from 1 st April 2015 and are architecturally distinct and atomic. 1.2 Audience HSCIC NHSmail Team. HSCIC Architectural Governance Group. Technical Design Authority. Government Digital Services. NHSmail suppliers. NHSmail users from health, public health and social care. 1.3 Background NHSmail was launched in October 2004 as a secure (departmentally accredited IL3) service. It is widely used by the NHS in England and Scotland (approx 631,000 regularly used accounts). Its security means that it is the only system in use in the NHS today that is endorsed by professional bodies as well as the DH for use to transmit patient identifiable information and provides a mechanism for secure interchange of across the Public Sector. NHSmail is currently stable, safe and secure. Increasing numbers of organisations continue to wish to join NHSmail. User numbers are currently growing at approximately 8,000 per month 12% per annum. In short, NHSmail is a successful service provided by HSCIC. It is a key and positive part of HSCIC s overall customer proposition. The service has been provided by Vodafone since The service was initially delivered on MiraPoint Messaging Service and in 2008 underwent a technology refresh to Microsoft Exchange Page 5 of 31

6 The contract with Vodafone must end by June 2016 at the latest by which point all existing users must have been migrated to a new solution. A project was therefore established in October 2012 to prepare for this migration. At the time of writing: The Outline Business Case (OBC) to confirm the continuation of NHSmail until June 2019 has been approved. This incorporates substantial input from the stakeholder community (users, suppliers, professions) with whom considerable engagement has already taken place as part of the delivery strategy phase of the project to deliver the future NHSmail service. Details of the anticipated future service have been published openly to the NHS and supplier community. It is expected that procurement of the new solution will take place between February 2014 and December 2014; and that the migration to the new solution will take place between March 2014 and December 2015 NHS Scotland may purchase their own new solution. Page 6 of 31

7 2 Strategy 2.1 Organisation Context NHSmail is consumed by health, public health and social care organisations delivered by both the public and private sector. As the diagram below shows this is a complex organisation environment. Organisations choose to take NHSmail. The service is not mandated. This means that the NHSmail service has genuine users who can vote with their feet. Communication frequently flows across public sector boundaries into local authorities, prisons, police, schools, Defence Medical Services, Department of Work and Pensions and others. 2.2 Vision Information is the lifeblood of the public sector, but is only useful if available to the right person in the right place, at the right time. Patient records for example are the primary source of clinically rich information for Healthcare Professionals, but clinical information needs to be shared, and in a variety of different ways. A fundamental way to share information is by . In addition to , the way that individuals share information has changed significantly over the past decade, adopting instant messaging, cloud storage, web conferencing, video messaging, and other technologies. There are real opportunities for the public sector to take the best of this technology and mould it to its own needs. The service needs to not only achieve its business objectives, it also needs to reflect national strategy and policy. This includes: Information Sharing Page 7 of 31

8 The Information Strategy, The Power of Information (May 2012) sets out that health and care information will flow freely, safely and securely around the system to the right person, in the right place at the right time. It will not be constrained by organisation or care setting boundaries. The service allows communication and data exchange between health and care users and their patients as part of this infrastructure and aligns to DH and NHS England s commitment towards a paperless NHS. Best Value Leading the development of the Crown Commercial Services (CCS) Managed Services Framework on behalf of other government departments reflecting a key priority underpinning the Information Strategy which wants an information system built on innovative and integrated solutions Technology That Just Works Consumer technology has set the expectation that it just works. This is a fundamental aspiration for the new service. 2.3 Alignment The service has been designed from the outset to align to applicable elements of the Government Digital Services Technology Code of Practice. Applicable elements that relate to the solution architecture include: Ensuring systems, information and processes are designed around the needs of the service user with as simple and as integrated an experience as possible. Ensuring a level-playing field for open source software Using open standards and common government platforms (e.g. recipient authentication integration with Government Identity Assurance Programme credentials) where available. Making data open by default, while minimising and securing personal data Establishing the sensitivity of information held in accordance with the Security Classification Policy, establishing legal responsibilities, developing user friendly, proportionate and justifiable security controls according to the Security Policy Framework. Separating commodity from niche needs through the requirements and aligning them to commodity and niche capabilities. Objectively evaluating potential public cloud solutions first. Following the guidelines laid out in the EUD strategy, design and implementation guidance to ensure the solution will work agnostically across many commonly used devices. Ensuring best environmental practices with requirements for suppliers to comply with Greening Government ICT. No requirement for enterprise licence deals or specification of products or brands. Page 8 of 31

9 Share resources by making what was initially a health and care procurement available across all of public sector in order to encourage reuse, avoid duplication and prevent redundant investments. Ensuring adequate capability is available for strategic decision-making or service accountability. In parallel to Government Digital Services alignment, the service has also been designed to align with version 0.6 of the HSCIC Technology Office EA: Architectural Principles, where applicable to the procurement: The HSCIC Enterprise Architecture has also been designed to align with the Government principles. 2.4 Future Expansion Opportunities and Localism The service has been designed around the needs of the service user following extensive public sector user consultation and support a principle of both centrally and locally funded elements allowing each public sector customer to align to their own investment strategy. Collaboration capabilities are an excellent example of this where different organisations are at different stages of digital evolution with some organisations readily using these capabilities day in day out and others at an earlier stage of their digital journey. 2.5 Principles In addition to the alignment to Government Digital Services Technology Code of Practice suppliers should apply the following principles to their solutions: Keep it simple Good enough is good enough Good enough not best of breed Use industry standards and don t over complicate Avoid over-configuration and over-engineering Best of breed mindsets can lead to over complication Page 9 of 31

10 Buy not build Use don t bend Do not develop niche/bespoke capabilities when there is no need to do so Use products in their sweet spot ; do not extend products beyond their normal boundaries 2.6 Requirements The requirements have been formed through extensive public sector consultation 1 and are broken down into three sections: Core Components Optional Components Common Components The components have been broken down to help separate commodity from niche 2 and to open up the opportunity for competition 3 from small and large service providers to provide solutions and services while at the same time ensuring a levelplaying field for open source software 4. Some suppliers may therefore find that they have a commodity product that is able to fulfil the requirements of a number of the individual components e.g. Secure , Secure Relay and Mobile Device Management. The common components describe the areas that apply in full to each individual component. This approach ensures the maximum reuse of components to avoid duplication and redundant investments 5 The requirements deliberately focus on business outcomes and user needs not solutions or products and support disaggregation principles if these need to be executed 6. 1 GDS Technology code of practice control 1 2 GDS Technology code of practice control 8 3 GDS Technology code of practice control 9 4 GDS Technology code of practice control 8 5 GDS Technology code of practice control 15 6 GDS Technology code of practice control 9 Page 10 of 31

11 In addition to all individual components needing to integrate with the common components such as secure needing administration integration for provisioning, some individual components will also need to integrate with other individual components such as secure and mobile device management. This document only provides a summary of the requirements to support a solution architecture overview and does not distinguish between essential and non-essential elements. Please refer to the requirements for a comprehensive list. Page 11 of 31

12 3 Breakdown of Core Components The following components are all individual core components of the service. Each of these individual components is accompanied by all of the common components in Section 5 below. 3.1 Secure Outcome Secure Public sector staff will have access to secure, reliable that allows them to safely share s containing confidential/sensitive information within the secure domains they use such or organisation@gsi.gov.uk and also with other parties outside the service (for example: citizen, health and social care, the police, social services, law firms, etc). The secure service should integrate with clients on a wide variety of end user devices. It should be available both on and offline and give safe ubiquitous (internet) access supported by the access and security requirements. The secure services offered will be selected by and appropriate to public sector organisations and users. This may mean that some users have access to using a mail client on a PC; others will prefer browser-based access or mobile device access, whilst the remainder will prefer a full groupware service. One size does not fit all. The service will also need to support application integration so that local public sector applications can leverage the service. Health and Social Care Address for Life and Local Address Every Health and Social Care account is provided with an address for their working life to support re-organisation, organisation transfer and transitional assignments (their national address). During a high period of change between April and September ,000 accounts were transferred to different Organisations and the use of a national address ensured seamless continuity of business operations during reorganisation. addresses containing the organisation name are critical to health and care organisations who value and/or rely on their branding. All users should have address for life, as is the case now, but also have the ability to have an alias containing the local organisational abbreviation (local address) that all deliver to the same mailbox. For example: john.smith@nhs.net as the address for life, and john.smith@examplehospital.nhs.net as an alias. If John Smith moved organisations at some point, john.smith@nhs.net would continue to work, john.smith@examplehospital.nhs.net would be deactivated and a new alias for the new organisation would be created. Generic addresses (medical.director@examplehospital.nhs.net) will be permitted, and can be transferred between users as people start and leave positions. Over time organisations will be renamed or merge. The user will build up a history of address aliases but the service will manage this ensuring is only Page 12 of 31

13 delivered to the active addresses with configurable behaviour on sent to a deactivated address Solution Capabilities The requirements for secure are aligned to the capabilities of commodity /collaboration systems. Requirements include: Multi-tenant and multi domain support. Personal and non-personal accounts. Industry standard , calendar, contact and task functionality. Standard delegation and sharing capabilities. Static and dynamic distribution list capabilities. Quota and archiving capabilities. Integration capabilities. Search capabilities. hygiene and data loss prevention capabilities. exchange within the system, to the internet and the insecure gateway Interfaces The secure service should be multi-tenanted, accessible to other parts of the public sector. This encourages reuse. Data should be shared across tenants where agreed, for example enabling diary sharing. Currently only sharing is possible with open standards as of today. Adding sharing of diaries & tasks is an additional level of benefit. 3.2 Secure Gateway Outcome There will be a central gateway between other secure services (specifically GSi) and the Secure Service. It will also provide a secure capability to send bulk from authorised applications and an encryption gateway to support to non secure systems. Page 13 of 31

14 3.2.2 Solution Capabilities The requirements for secure gateway are aligned to the capabilities of commodity gateways, anti-virus/anti-spam products, mail hygiene services, filtering services, relay services and encryption services. Requirements include: exchange and connectivity between other secure services such as GSi, GCF, GCSX, CJSM, PNN and MoD including non delivery and S/MIME support. A lightweight secure relay for application traffic generated by accounts on the platform including access controls (SMTP authentication and IP address authorisation) as well as encryption in transit. hygiene and data loss prevention capabilities. Bidirectional encryption to non secure systems/accounts such as to citizens Interfaces The secure gateway will interface with the GSi/PSN gateway for secure communications with the rest of government. hygiene will most likely be provided by a cloud AVAS service, minimising load on the network. 3.3 Mobile Device Management Outcome Mobile device access is becoming the primary method of accessing services for many users. For others, it is their secondary method but is critical when away from their desks or the office. Therefore, compatibility and support for a wide range of mobile operating systems and devices is critical, especially for organisations operating or considering a Bring Your Own Device (BYOD) arrangement with their users. Enforcement of the mobile device policy is critical too, for the security of the service and the confidentiality of sensitive public sector information such as patient data. Page 14 of 31

15 This requirement is primarily about protecting the data a user could hold on their device from any component of the service. Data needs to not only be protected at rest and in transit but also when in use to ensure other applications on a device for example cannot access the contents of . Any additional management capabilities will of course be welcomed by public sector customers but they are not essential Solution Capabilities The essential requirements for mobile device management are aligned to the capabilities of commodity services that support mobile device management. The non-essential elements align with the capabilities of dedicated mobile device management solutions. Requirements include: Support for the most popular mobile/tablet device operating systems Remotely enforce the customer s mobile device policy, rejecting devices that do not meet, enforce or report the policy Providing commodity management capabilities such as remote wipe, encryption and device locking Providing additional locally funded capabilities such as detecting rooted (jail broken) devices and a full mobile device management capability Interfaces Access will be delivered via the Internet/mobile telecommunication network, not N3 or PSN. As mobile devices are purchased by user organisations, they will vary in device type and security controls. 3.4 White Pages & Directory Service Outcome Public sector care covers a vast range of organisations and a large number of staff. Good quality communication depends upon finding the correct person and communicating with them. A central white pages & directory service has the ability to help deliver this as long as it is trusted, accurate and up to date. The directory & white pages provides contact details for people in all public sector organisations, not just the users of the secure service. Users will be able to find contact information for a user, group or organisation. This should cover all aspects of communication, for example address, phone number, teleconferencing details. They will have access to features now standard in social networks, for example a photograph, status and location, with appropriate security controls around this. The white pages should be maintained by authoritative data sources with organisations able to select a combination of system and self-service updating dependant on their local approach to data management. There will be appropriate tools to ensure that data quality and consistency is maintained, with data transformation/re-mapping capabilities to support local administrators being able to easily operate on a large number of entries. Page 15 of 31

16 Consideration needs to be given to segmentation approaches in the event of the service being used by non-public sector organisations. This will be considered when evaluating role based access controls Solution Capabilities The requirements for the white pages & directory service typically align with the capabilities of commodity directory services. Requirements include: Providing a capability to support a directory of people, organisations, distribution lists, and generic mailboxes across public sector with contact information for each of the entities useful to the public sector. Flexible role and location based access controls e.g. authenticated access over the internet, non authenticated access over PSN and limited attribute access by authorised authenticated third parties. Supporting an extensible flexible schema to allow additional attributes to be added for users. Supporting the Customer s organisation hierarchy and be sufficiently flexible to accommodate regular restructuring. Allowing users to update elements of their individual entries where permitted by their organisation. Allowing public sector administrators to maintain data quality on both individual entries and in bulk with data transformation/validation tools. Integrating with other directories through industry standard interfaces Supporting authoritative updating of fields on a per Organisation basis from nominated authoritative data sources. Providing the ability for public sector organisations to query the directory using standards-based methods. Seamlessly take over from the existing NHSmail directory. Providing a powerful advanced search and browse function, with the ability to search (and filter search results) by organisation, role and other criteria Interfaces The NHSmail directory covering health and social care will interface with: Page 16 of 31

17 Spine 2 directory covering NHS staff with smartcards. Electronic Staff Record covering permanent NHS staff who work in organisations that use this service. GSI directory covering central government. Trust contacts directories. 3.5 Insecure Gateway Outcome There is a central gateway for nhs.uk services operating on PSN Solution Capabilities The requirements for the insecure gateway are aligned to the capabilities of commodity relay services, anti-virus/anti-spam products, mail hygiene services and filtering services, relay services and encryption services. Requirements include: Accepting from any N3, PSN or Internet connected nhs.uk service verified by reverse DNS lookup and relays it via the N3/PSN private DNS service for nhs.uk addresses and the internet DNS service for all other addresses noting: o an increasing number of nhs.uk domains are now internet hosted. o Where a connection is authenticated with a username/password the service should disregard the credentials and accept the connection anyway. Supporting non delivery reports and S/MIME Providing mail hygiene services Retaining data necessary to support message delivery tracking in the event of delivery issues for up to 3 days as local nhs.uk systems retain any data needed for compliance purposes. Supports the capability to for local billing should it be introduced in the future providing monthly volume reports by domain. Page 17 of 31

18 4 Breakdown of Optional Components The following optional components are all individual components of the service. Each of these individual components is accompanied by all of the common components in Section 5 below. 4.1 Instant Messaging and Collaboration Outcome Users across public sector have access to an instant messaging and collaboration solution that just works, and includes: Instant messaging. Audio conferencing. Video conferencing. Shared workspaces, documents, and device desktops. VoIP (Voice over Internet Protocol) integration. This may be delivered within an service or alongside it. Suppliers should comply with open standards to ensure seamless integration between services. Suppliers should recognise the need for users to have a different availability status e.g. appearing available to all staff in their Organisation, available to some staff in another Organisation and not available to all other service users. Suppliers should recognise the need to collaborate beyond the service Solution Capabilities The requirements for Instant Messaging and Collaboration typically align with the capabilities of commodity services in this area. Requirements include: Supporting: o Instant messaging including location, availability and presence information o Audio conferencing o Video conferencing o Shared workspaces / documents o VoIP (Voice over Internet Protocol) integration Integration with the relevant service components. Integration with the directory service. Where safely available and where possible, provide open standard interoperability with other instant messaging and collaboration solutions. When federating with other systems through open standards consideration should be given to reflecting different availability/presence within and outside the Organisation as well as an ability to allow access by invitation. Relevant hygiene services. Page 18 of 31

19 4.2 Remote Storage Outcome Users across public sector have access to a remote storage capability that they can use to store and share documents in a secure manner. The service will ensure that they are not infected by viruses or other malware. Public sector organisations will be able to manage the remote storage of their users to ensure they are used appropriately; manage quotas, comply with access requests, etc Solution Capabilities The requirements for Remote Storage typically align with the capabilities of commodity services in this area. Requirements include: Allowing users to store and retrieve files from their own personal area with ubiquitous access. Allowing users to share files with other named users or groups determined by entries in the directory. Seamlessly integrates into other applications through the use of standardsbased methods. Allowing shared working on documents, spreadsheets, etc. Allowing administrators to manage user remote storage accounts (e.g. create, suspend, delete, password reset and manage quotas). Recovering files from a user s remote storage area. Monitoring usage, including serving regulatory requests (e.g. Freedom of Information). Searching capabilities. Relevant hygiene services. Page 19 of 31

20 5 Common Components All of the following components are common to each of the individual components in Section 3 and 4 above. The table below shows how they apply 5.1 Access Outcome To offer a full service regardless of whether users are accessing the services using a desktop client or web browser. For some organisations, a web browser will be the only way for users to access the services. Many of the devices will not be security accredited Solution Capabilities The requirements for Access typically align with the capabilities of commodity services in this area. Requirements include: Allowing users and applications agnostic access (up to the previous three versions) broken down into the following 4 categories: o Desktop clients including but not limited to Microsoft Outlook and Mozilla Thunderbird o Web clients including but not limited to Internet Explorer, Firefox, Google Chrome and Safari o Mobile device clients (smartphones, tablets, etc) o Applications Allowing access to content based on the integrity of the device connecting. Fully secure managed endpoints are given full service access with the ability to locally download and cache content, endpoints with no assured protection of data in use or at rest only get limited browser access with no locally cached content. Ensuring all client server communications are encrypted. Providing browser access compliant with the appropriate web standards including HTML 5. Complying with the appropriate accessibility standards and guidelines including but not limited to WCAG 2.0 AA compliance. Ideally has really rich browser access that may provide all of the functionality of desktop clients. Ensuring browser access prevents documents being downloaded to non managed unsecure devices, such as public access computers and instead allow commonly used file formats to be displayed/rendered in the session. If branding is supported then ideally it should comply with departmental branding requirements. A portal providing seamless access to all of the individual components that have web components associated with them e.g. training & guidance pages, administration tools and reports. Page 20 of 31

21 5.2 Networking Outcome To offer a service that is accessible wherever the user needs it to be. This could be from a hospital ward, an ambulance in a field or a social care worker at a citizen s home Solution Capabilities Accessible from the NHS wide area network (N3 and its successors), the Government secure wide area network (GSi/GCSX and its successors), the Public Services Network (PSN) and the Internet. The service must meet the accreditation requirements of the networks it connects to. The N3/PSN for Health data centre connection will be provided by the Department of Health as part of that programme of work. The secure provider will provide the Internet gateway. 5.3 Administration Outcome Public sector organisations can easily administer their organisation and users on the services. They can also administer child organisations, e.g. for health and social care a Clinical Commissioning Group administering the GP practices aligned to them Solution Capabilities Depending on the richness of underlying commodity products administration capabilities the requirements for Administration may or may not require some niche/bespoke development to provide a user friendly front end that calls the underlying services administration functions. Requirements include: Supporting full lifecycle administration including creation, deletion and suspension of accounts. Page 21 of 31

22 Allowing for multiple administrators in and across organisations with administrators having a full range of administration capabilities through an authenticated role based web user interface or programmatic interface. Supporting actions on items both individually and in bulk. Administrators may manage more than one related and non-related organisation. In the case of related organisations the service should support delegated/inherited permissions e.g. a territory administrator has admin rights over all accounts in the territory of the tenant they are operating under or a Clinical Commissioning Group over all GP Practice accounts they parent but not GP practice accounts they do not parent. Consideration to providing administrators with the ability to restore deleted accounts up to a specified period, and for account owners to be able to do it themselves through a safe method such as shared pre-registered secrets. Retaining removed and expired accounts for a period to be agreed (can subsequently be changed by configuration in the event of any agreed policy changes). Allowing the availability and scope of administrator functions to be controllable by role and location through all of the interfaces. Supporting platform, organisation and user level rate limiting controls based on for example number of messages sent and/or received per day. Only allowing addresses of deleted accounts to be made available for re-use after an agreed period of time. When transferring an account to another organisation such as when changing organisation or restructuring supports some attributes being transferred (e.g. name, address for life and quota), some attributes being removed (e.g. local address and administration permissions) and some attributes being updated/replaced (e.g. organisation details local address). 5.4 Onboarding and Offboarding Outcome To move an existing service on or off with minimum effort and disruption is also important and should take place with no unexpected data loss. Users will expect that their s, contacts, tasks, documents and calendar appointments will all move with them, and it will be a very significant issue and cost to the business if any of these are lost, or the business is unable to use during the migration. The Customer is looking for tools to enable the easy migration of accounts. This includes the migration from the existing service used by health and social care (NHSmail). Ancillary data such as permissions, passwords and audit information all needs consideration to support a great transition experience. There may be some items that by prior agreement are not migrated which would qualify as expected data loss during transition e.g. attachments with viruses that cannot be disinfected by the mail hygiene services (user would be notified). The timescale expectation for transition is currently 3 months planning and 6-9 months to complete the transition. Page 22 of 31

23 5.4.2 Solution Capabilities The migration requirements for onboarding and offboarding are aligned to the capabilities of commodity products/capabilities in this area. Co-existence capabilities may require some niche/bespoke development depending on the capabilities of the source and destination systems to co-exist with each other. Requirements include: Moving specified accounts and associated data (e.g. s, contacts, tasks, calendars, distribution lists, ancillary data, address or cloud storage content) between other suppliers of secure with minimal disruption and no unexpected data loss. Migration capabilities that have minimal impact on organisations, their users and their administrators. Migration capabilities to move from the previous national service to the new service that provides the ability for an organisation to move all its specified accounts and associated data (e.g. s, contacts, tasks, calendars, distribution lists, ancillary data, addresses and directory content) as well as capabilities to migrate from a local service all with minimal disruption and no unexpected data loss. Co-existence capabilities to ensure business continuity is maintained as much as possible to the fullness of co-existence capabilities supported between services. While this may not extend to folder sharing between services users will have an expectation of looking up addresses and corresponding with users regardless of the service they are on during transition. Mail hygiene services to support onboarding/offboarding capabilities to ensure the integrity of source and destination systems is maintained. 5.5 Information Security Outcome The information held within the services is held securely in accordance with industry and public sector standards. The security mechanisms do not inhibit legitimate uses for the information. The services are accredited to an appropriate level of security for OFFICIAL-SENSITIVE based upon a risk assessment. There is a suitable accreditation framework for sensitive personal data in health and care Solution Capabilities The functional elements of information security are aligned to the capabilities of commodity information security products/capabilities. Functional requirements include: Providing organisation administrators with tools to set per user and per client type access to individual components to support their local information governance policies. Identifying personally owned equipment (automatically or through self declaration) so that administrators they can manage the risk and if need be block access to personally owned devices that do not comply with local information governance policies. Compliance with the open standards policy for all parts of the service such as Page 23 of 31

24 Keeping all Patient Identifiable, DPA sensitive, RESTRICTED and Official- Sensitive data at all times in the UK. Other data not in that category that the supplier elects to hold outside of the UK in specified Countries within the European Economic Area (EEA) subject to DPA compliance e.g. non sensitive content used in a collaboration meeting is properly segregated e.g. walled garden architectures. Supporting the ability to protectively mark content and allow the application of data leakage prevention rules to be applied/reported based on the protective marking applied. Protective markings may include Private, Personal, NHS CONFIDENTIAL, RESTRICTED (may include sub markings like MEDICAL), OFFICIAL and OFFICIAL-SENSITIVE. 5.6 Identity Management Outcome Users of the service are authenticated once reliably using common methods Solution Capabilities The functional elements of identity management are aligned to the capabilities of commodity information security products/capabilities. Functional requirements include: Consideration when accessing the service from the Internet of: o A recognised form of two-factor authentication. o A mechanism that augments the strength of username and password. Providing users with an ability to safely perform self-service password resets from any network utilising either a recognised form of two-factor authentication or a mechanism that augments the strength of username and password. Supporting logins from other sign-on solutions e.g. the NHS Spine, or integration with an organisations existing solution, e.g. using SAML 2.0 integration. Supporting logins from the ID Assurance service if authentication of citizens is required. This is a possible solution to the challenge of passing encrypted information to insecure services. 5.7 Service Management Outcome Each supplier shall provide industry standard levels of service management to its customers. Each supplier will provide a Service Desk which is accessible to both end users and the local service desk of all consuming Health and Care organisations. A relationship should exist between the two suppliers to enable appropriate incident handoffs. The Customer s Service Management Team will manage supplier s performance through appropriate Service Levels and will facilitate cross supplier working where service interdependencies exist. Page 24 of 31

25 5.7.2 Solution Capabilities The functional elements of service management are aligned to the capabilities in this area. Please refer to the requirements for details in this area. 5.8 Customer Service Outcome The services must provide excellent customer service to health and care organisations, their users and the Customer. This must be measured regularly and acted upon. If a service Supplier does not maintain excellent customer service then ultimately they will be replaced Solution Capabilities The functional elements of customer service are aligned to the capabilities in this area. Please refer to the requirements for details in this area. 5.9 Data Retention and Compliance Outcome Data is managed in accordance with legal, policy and good practice. This covers the Data Protection Act and the Freedom of Information Act Solution Capabilities The requirements for data retention and compliance typically align with the capabilities of commodity services in this area. Requirements include: User able to themselves recover deleted items (minimum of 30 days) Retaining easily accessible discoverable copies of: o all sent and received (minimum of 180 days) o the message summary (in essence mail headers) of all s sent and received (minimum of 2 years) o system Audit logs (minimum of 6 months) Retained data is captured and made available robustly enough to support evidential use such as an internal disciplinary hearing or through the criminal justice system. It should also be recognised that there may be occasions that require very rapid (near real time) access to audit data. Automated audit analysis tools that assist auditors in the detection and prevention of system misuse Reporting Outcome User organisations and the Customer have sufficient information to easily administer the service in a user-friendly manner. Page 25 of 31

26 Solution Capabilities The requirements for reporting typically align with the capabilities of commodity services in this area. Requirements include: Providing reports to allow individual user organisations and the Customer to administer the service. Individual component reporting that allows organisation administrators to run regular reports of the usage statistics of the service components that can be exported in a variety of open formats. Page 26 of 31

27 6 Alignment to ICT Principles The table below lists the technical elements of the GDS Technology Code of Practice and responds to each point. Item Ensure systems, information and processes are designed around the needs of the service user, providing as simple and as integrated an experience as possible. Be very clear who the users are and how to engage with them and ensure their needs are met. Demonstrate value for money in your business case and articulate the options considered in a full and objective appraisal. 1. All new or redesigned digital services meet the Digital by Default Service Standard. 2. Ensure a level-playing field for open source software. Demonstrate an active and fair consideration of using open source software taking account of the total lifetime cost of ownership of the solution, including exit and transition costs. 3. Use open standards, and common government platforms (eg GOV.UK, identity assurance, shared services) where available. 4. Make data open by default, while minimising and securing personal data, or data restricted for national security reasons. Public data should be made available by default in both human and open machine readable formats. Users should have access to, and control over, their own personal data. 5. Establish the sensitivity of information held in accordance with the Security Classification Policy, establish legal responsibilities, develop user friendly, proportionate and justifiable security controls according to the Security Policy Response The NHSmail requirements were developed with the user community and agreed with them. They include the feedback from the annual survey. The project runs a quarterly stakeholder council which reaches out to ~ 100 IM&T Director level users. NHSmail is an existing service and so there is a high level of maturity about user expectations. The SRO is committed to users being delighted with the service. VFM is demonstrated in the Full Business Case. There is substantial evidence that buying at scale reduces the costs, has described in the SOC and OBC. The project has delivered the procurement as specified in the OBC. NHSmail is not considered a digital service as it is not used by citizens. The requirements were written to ensure that there as a level playing field for open source software. No technologies are mandated. Whole life costs formed part of the procurement evaluation. The requirements & evaluation criteria required the use of open standards and the IDA platform. NHSmail is a shared service for health & social care in England and Scotland. NHSmail uses one proprietary standard activesync. This is the predominant way of mail client/server connectivity used globally and is unavoidable. This was identified to Cabinet Office at SOC stage for inclusion in wider Microsoft discussions but not progressed. Over time we see a move to HMTL 5 which will reduce the need for Activesync. NHSmail contains personal and sensitive data which should not be open by default. Users have fill control over their mailbox and directory entry. Information classification follows the security classification policy with 60% of falling within OFFICIAL SENSITIVE. Security controls were developed in the requirements in line with the Security Policy Framework and CESG Page 27 of 31

28 Framework. 6. Separate commodity from niche needs. Use costeffective commodity services for infrastructure and utility business activities like office productivity (word processing, spreadsheets and presentation software, , scheduling and collaboration). Identify and acquire capabilities rather than infrastructure where services required are bespoke/innovative. Ensure that any procurement is designed to encourage competition and follows published Government Procurement Policy. [Competition will be encouraged with no like-for-like extensions to existing contracts. The renewal of incumbent products, services and suppliers, or the stipulation of their brands, is not permitted: there must always be an open and competitive specification and reprocurement process. All requirements must be expressed in terms of business outcomes and user needs not solutions or product feature sets. Programmes will be disaggregated for commercial purposes broken down into components supported by the market to enable many suppliers to bid. There is a presumption that no procurement will have a lifetime cost over 100 million. Contract lengths for services should be kept to the minimum level necessary to ensure commercial flexibility. 7. Purchase networking and telephony services through the Public Services Network frameworks. 8. Objectively evaluate potential public cloud solutions first before you consider any other option. In order to do this you will need to identify the capabilities and services that make up your technology design, and demonstrate that the solution chosen represents best value for money. 9. Follow the guidelines laid out in the EUD strategy, design and implementation guidance to ensure your solution will work for any end user device. 10. Ensure best environmental practices, whether inhouse or via external suppliers, including compliance with Greening Government ICT. Any software licence agreements must evidence actual user needs there should be no default continuation of enterprise licence deals or specification of products or brands. 11. Share resources: services, information, data and software components must be shared in order to encourage reuse, avoid duplication and prevent redundant investments. Reuse includes the use of existing services and capabilities that already exist outside of government where they provide best value for money, eg identity verification, fraud and debt management, cloud-based guidance. This approach was agreed with CESG. Where possible the requirements and evaluation criteria were developed to be as close to industry standard as possible. From the start the service has been procured so it could be joined by other public sector organisations. There has been extensive consultation with other public sector organisations to ensure the NHS does not use a niche service. The procurement was a call off from the CCS Managed framework following OJEU and public sector procurement rules. All efforts we made to ensure a fair and open competition, with extensive market consultation pre-procurement, including operating a supplier council. The contract length has been set to 5 years, reflecting that onboarding takes a year and TUPE costs are substantial (~ 2m-3m). This was documented and agreed with Cabinet Office in the OBC. Not applicable. Public cloud was considered however DH has a requirement for clinical data to reside in the UK to ensure trust in the healthcare system. This necessitated a private cloud solution, as described at SOC and OBC stage. The service has been designed from the start to be used by any device (noting version minimums) as the health & care sector uses all of them. The contract includes a requirement to comply with green standards. Software licencing is provided as part of the managed service, not separately. NHSmail has links to the Spine (for organisation data and staff authentication), IDA (where required for citizen authentication) and the Electronic Staff Record (for staff movements). Page 28 of 31

29 commodity services. Align to the shared services strategy for HR, procurement, finance and payroll. 12. Plan on using an agile process, starting with the user need. Waterfall should only be used by exception and where it can be shown to better meet user need. Projects may need the best of both formal and agile methods, playing to their respective strengths: producing successful IT services is about knowing when to use the right tool at the right time. Demonstrate that adequate capability is available in your organisation you shouldn t outsource strategic decision-making or service accountability. If the necessary capability does not exist in-house, then you need to evidence a plan for developing or recruiting people with the right skills and experience. Implement effective procedures for the use and management of information (both structured and unstructured) through its entire lifecycle. Adhere to The National Archives (TNA) expert guidance on information management. Not applicable. Not applicable. This is not a development project. The capability to deliver is already in place within the HSCIC as it is delivering NHSmail 1. It remains in place for NHSmail 2. The NHSmail service already has published information management policies. These will also apply to NHSmail 2. Page 29 of 31