NHSmail 2 Requirements

Transcription

1 Document filename: NHSmail2 Requirements 1.13 Directorate / Programme Programmes Delivery Project NHSmail 2 Document Reference Status Final Programme Manager Mark Reynolds Version 1.13 Author Clive Star Version issue date 29/07/2014 NHSmail 2 Requirements Page 1 of 49

2 Document Management Revision History Version Date Summary of Changes 0.5 For internal review /11/2012 Major revision incorporating the following: Review comments from v0.5 of this document. Requirements from NHSmail 2 Initial User Engagement v0.5. User feedback sent to the NHSmail 2 mailbox. User feedback posted on the NHS Networks site /12/2012 Major revision incorporating the following: Review comments from v0.7 of this document. All detailed requirements, mostly from NHSmail 2 Initial User Engagement, are now in another document NHSmail 2 Requirements Change Log. More user feedback sent to the NHSmail 2 mailbox. More user feedback posted on the NHS Networks site /12/2012 Major revision incorporating the following: Review comments from v0.8 of this document. More user feedback sent to the NHSmail 2 mailbox. More user feedback posted on the NHS Networks site /12/2012 Minor changes. Up-issued and approved for release /01/2103 Minor changes to clarify requirements /01/2013 Minor changes to clarify requirements /01/2013 Up-issued and approved for release /01/2013 Changes from review comments and supplier workshops /01/2013 Major document re-structure, now split into individual components and common components. Some requirements reworded and/or moved between sections /02/2013 Up-issued and approved for release /03/2013 Minor updates, for internal review (including by User Council as part of validation process) /03/2013 Simplified service management section. Added in essential criteria. Added nhs.uk relay. 1.8a Interim update to reflect Fax at IL3 instead of IL /04/2013 Clarifications added to a number of sections to help suppliers understand NHS context better /07/2013 Additional clarifications. Security requirements updated to reflect security risk assessment and inclusion of the independent security review following HMG methodology. Further updates to the security sections including data location and baseline control sets Change log added to summarise changes from the previous version Page 2 of 49

3 /10/13 Updates following extensive PSN customer consultation adding additional clarification and updates to existing service figures. SMS and Fax sections removed as these are being procured separately /01/14 Updates to Requirement 3 of Secure , Mobile management, Router and Onboarding and Offboarding requirements /07/14 More detail added to the requirements Reviewers This document must be reviewed by the following people: Reviewer name Title / Responsibility Date Version User Council Supplier Council NHSmail 2 Project team Approved by This document must be approved by the following people: Name Signature Title Date Version Mark Reynolds NHSmail 2 Programme Director 1.13 Glossary of Terms Term / Abbreviation Active Session Administrator Anonymous User Archiving Service Automatic Password Reset What it stands for The period during which a User is logged on to the Services, determined from the moment when the User s credentials are authenticated by the Services until the moment when that User ceases to use the Services by either logging out or, after an agreed period of inactivity, the User is automatically logged out for security reasons. A User who has access to special tools to administer User accounts and other aspects of the Services received by their Organisation or group of Organisations. A User who has not authenticated themselves to the Services using authentication credentials such as to access the directory or training/guidance material from a secure network. A service to enable each User to archive their own and/or calendar data. Functionality which enables a User to reset their password through the supply of several factors known only to that User. 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 3 of 49

4 Contents 1 Overview Vision Current Situation Requirements 6 2 Breakdown of Core Components Secure Secure Gateway Mobile Device Management White Pages & Directory Service 17 3 Breakdown of Optional Components Insecure Gateway Instant Messaging and Collaboration Remote Storage 26 4 Common Components Access Administration Onboarding and Offboarding Information Security Service Management Customer Service Data Retention and Compliance Reporting 44 5 Appendix 1 - NHSmail Service Levels 46 6 Appendix 2 Security Level Review 49 Page 4 of 49

5 1 Overview 1.1 Vision Information is the lifeblood of health and care, but is only useful if available to the right person in the right place, at the right time. Patient records 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 health and care to take the best of this technology and mould it to its own needs. The investment will satisfy the following business objectives: Information Sharing 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 replacement for NHSmail will allow communication and data exchange between health and care users and their patients as part of this infrastructure. Best Value The public sector uses its substantial buying power to effectively and in a joined up fashion negotiate the best value for money when it buys a service. Technology That Just Works Consumer technology has set the expectation that it just works. This is a fundamental aspiration for the new service. 1.2 Current Situation In May 2014 NHSmail had a total of 938,592 registered mailboxes and generic accounts with 618,806 person accounts in regular (daily) use within the NHS of which 91,029 were in Scotland. 445 organisations and many thousands of GP Practices use it as their sole service (more than 70% of their accounts active), with another 723 organisations using it to a lesser extent as detailed at NHSmail and domain are trusted throughout the NHS and government services as a secure system. The system currently comprises , calendaring, directory, hygiene (spam and malware protection), SMS, fax, monitoring, and a mail relay service to connect non-nhsmail users. It is an service through which NHSmail sender and receiver can be assured that information is secured in the creation, delivery and receipt of the message. The SMS and Fax services will be decommissioned prior to Page 5 of 49

6 migration to NHSmail2. The service continues to grow, with an average growth of 19,936 new accounts each month and many new organisations in the pipeline. 1.3 Requirements The requirements are broken down into three sections: Core Components Optional Components Common Components The components have been broken down to open up the opportunity for small and large service providers to provide solutions and services. 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. 3.1 nhs.uk Gateway Internet N3/PSNH GSi 2.1 Secure 2.2 Secure Gateway 3.2 Collaboration 2.3 Mobile Device Management 2.4 White Pages & Directory Service 3.3 Remote Storage 3.2 Instant Messaging Areas applicable to all components: 4.1 Access 4.2 Administration 4.3 Onboarding and Offboarding 4.4 Information Security 4.5 Service Management 4.6 Customer Service 4.7 Data Retention and Compliance 4.8 Reporting 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. Page 6 of 49

7 Optional Components include services that are used by Health and Social Care Organisations to complement the Core service. While it is not essential for suppliers to provide these services, this document provides guidance on the Requirements of Health and Social Care Organisations in relation to some of the most commonly used Optional Components. Suppliers may wish to complement their services by including additional Optional Components, either as part of their core offering, or as additional Options to be procured directly by Health and Social Care organisations. Optional Components contained in these requirements are not an exhaustive list, and proposals containing additional optional elements will be welcomed. Please note that the essential column is defined as follows: requirement is essential T essential that this is offered as a top up service Blank not essential Page 7 of 49

8 2 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 4 below. 2.1 Secure Outcome Secure Health and care staff will have access to secure, reliable that allows them to safely share s containing confidential patient information within domain, and also with other parties outside the domain. (For example: patients, health and social care, the police, social services, law firms, etc.). The 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 services offered will be selected by and appropriate to health and care 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/tablet 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 healthcare applications can leverage the service. Address for Life and Local Address Every account is provided with an address for their life in the NHS to support re-organisation, organisation transfer and transitional assignments (national address). During a high period of change between April and September ,000 accounts were transferred to different Organisations ensuring seamless continuity of service during reorganisation. addresses containing 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 delivered to the active addresses with configurable behaviour on sent to a deactivated address. Page 8 of 49

9 2.1.2 Current Situation The current service uses Microsoft Exchange 2007 at its core, with a customised web application to provide the entire additional web based components. The portal does not provide a customised version of Outlook Web Access although it does through Outlook Web Access Web Parts provide access to mailbox folders and delegation. Two-thirds of users access their primarily via the web browser. Peak messages in an hour on the Exchange infrastructure can exceed 8 million Requirements # Requirement Essential 1 The Secure Service must provide multi-tenant across health and care organisations using domain which will contain sub domains as well as the hscic.gov.uk domain. The service must support the inclusion of additional secure domains should other organisations wish to bring their own secure domain e.g. organisation.gsi.gov.uk. The process of adding, changing (renaming) domains used by different customers can be performed by the service provider on behalf of the tenant or via the tenant administrator. The Secure Service must route to and from the internet and provide the infrastructure to support it. to and from other secure domains is via the Secure Gateway provided by the supplier. 2 The Secure Service must provide two types of account: Personal. Generic: o Shared generic accounts. o Resource accounts (e.g. room bookings) o System accounts (e.g. for applications that send s) Both types of accounts must have typical account lifecycle functionality and commodity capabilities e.g. renaming and multiple aliases. Shared generic accounts should have some additional capability/function over and above personal accounts e.g. ability to send from the generic account using shared account credentials or leverage a resource booking capability in the commodity product. 3 The Secure Service must provide industry standard , calendar, contacts and tasks functionality, such as: Reports for delivery and non-delivery of s in an easily understandable format, an internal/external out of office message facility, and automatic forwarding (only to approved secure domains) e.g. auto forwarding to *.yahoo.com is blocked. Delegation and Sharing 4 The Secure Service must provide the ability to share, and delegate access to, an account s , calendar, tasks, and contacts with other users of the service whether in the same Organisation or another Organisation subject to local Organisation control/policy, as well as across tenants where the service is multi tenanted. In the case of personal accounts, this functionality should only be available to the user who is the owner. In the case of generic (i.e. shared) Page 9 of 49

10 accounts, this functionality should be available to the account s owner(s). Distribution Lists 5 The Secure Service must provide tools for users to create and manage centralised static and dynamic distribution lists based on local and central directory information that are available to all users of the service e.g. user selects directory entries, user builds a rule based on directory content using any of the directory fields (job role) or types in external addresses.. Dynamic distribution lists should be able to leverage the fields of the directory service e.g. all Nurses in a Clinical Commissioning Group working in Paediatrics. This includes: Rules support many complex include/exclude rules and allows the owner to see the dynamic rules results (check rules). Allows for bulk membership management (bulk import/export) Supports permissions (owners, authorised senders) Supports privacy (hide membership and possibly visibility in the directory) May or may not operate across tenants Supports a standard naming format (<org short name>.<dl- Name>@<domain> 6 The Secure Service must provide tools for users to create and manage personal distribution lists that are available only to themselves. Quota and Archiving 7 The Secure Service must provide an account quota per user for each and every account in an organisation, for both personal and generic accounts. This must include and be shared between s, calendar appointments, tasks, and contacts. The quota should be set at a per service and per Organisation level and support a variety of per user quota sizes across the Organisational average. This includes: Set a tenant default e.g. 25 GB average per user Set an organisation override to the tenant default e.g. 5 GB average per user for Org A Set a default quota for all newly registered accounts e.g. 1 GB Different quota bands or sizes (at least 4) that local administrators can then allocated accounts within their organisation mailbox average size Ensuring quota applies to all mailbox content ( , calendar, contacts and tasks) for both personal and generic accounts. Reallocating quotas at a tenant, organisation and user level Prohibit send at quota used and receive at quota used plus 200 MB (configurable at a tenant level) 8 The Secure Service should give organisations the option of directly purchasing larger and archive quotas (if separate products), for both personal accounts and generic accounts. The capability should complement the quota usage reports and tools and allow for quota uplifts at an organisation and user level. 9 The Secure Service should provide an archiving solution that is seamlessly integrated with the service and completely transparent to T Page 10 of 49

11 users e.g. no additional login required. The archive should support per service and per Organisation retention polices/archiving rule sets with a variety of archive quota sizes across the Organisational average archive size e.g. age rules and mailbox size rules. The service may or may not support offline access by all client types subject to the commodity capability. Integration 10 The Secure Service must integrate with any other components of the service that deliver the overall capability. The user experience with different components provides an integrated experience. Switching to the Directory using it for distribution lists for example feels integrated Address for Life 11 All users must have address for life and the ability to have an alias containing the organisational abbreviation that all deliver to the same mailbox. For example: john.smith@nhs.net as the primary address, and john.smith@examplehospital.nhs.net as the alias (the value for the alias is the organisation short name stored in the directory). If John Smith moved organisations at some point, john.smith@nhs.net would continue to work, john.smith@examplehospital.nhs.net would be de-activated and a new alias for the new organisation would be created by automated workflow based on the properties of the account in the directory. This is necessary because there is no national work flow that tracks a user moving from one organisation to another. Search The Organisation should have the ability to set the default reply address at a per account level for both personal and generic accounts. Over time organisations will be renamed or merge and users may change their name. The user will build up a history of address aliases but the service will manage this ensuring is only delivered to the active addresses with configurable behaviour on sent to a deactivated address. 12 The Secure Service should provide an overarching search function that searches all parts of a user s account ( , contacts, tasks, calendar, etc.) and their centrally provided archive in a single search. 13 The Secure Service must allow a user to enter advanced search criteria such as narrowing the time/date range of the search, specifying a particular sender, or limiting the search to an individual part of a user s account such as or calendar only. Hygiene 14 The Secure Service must provide industry leading anti-virus and antispam filtering capabilities. In addition to commodity content management such as attachment blocking, maximum attachment size, profanity checking, virus/spam filtering capabilities and data leakage prevention e.g. encrypt protectively marked destined for the Internet or a non-secure PSN connected domain. There should also exist options for managing spoofed/forged and items that cannot be checked such as S/MIME encrypted or password protected attachments. Rules should work at SMTP domain levels e.g. block s containing NHS number to a specified internet domain or allow a single customer of the service to block s containing profanities. This includes: Content management e.g. mark as spam if subject contains V1agra Page 11 of 49

12 Virus/spam filtering capabilities e.g. reject all messages to unknown recipients Data leakage prevention that is standard in the commodity product. This could be encrypt Official-Sensitive destined for the Internet Managing spoofed/forged e.g. insert a warning saying the message is reported to be from an account on the service but has been sent from somewhere else (list from address). Managing items that cannot be checked such as password protected attachments e.g. insert a warning saying the content of the attachment is password protected and could not be virus scanned. Per domain filtering e.g. block encrypted attachments to gsi.gov.uk domains and allow them to nhs.net domains 2.2 Secure Gateway Outcome There will be a central gateway between other secure services (specifically GSi) and NHSmail 2. It will also provide a secure capability to send bulk from applications and an encryption gateway. The Secure Gateway typically aligns with the capabilities commodity gateways, anti-virus/anti-spam products, mail hygiene services, filtering services, relay services and encryption services Current Situation There is currently a central gateway between NHSmail and GSi which securely transmits small volumes of . Exchanging sensitive to insecure addresses such as internet or nhs.uk recipients is currently achieved via S/MIME which is both cumbersome and difficult to use and identified by users as an area needing improvement Requirements # Requirement Essential 1 The Secure Gateway provided by the service provider must transfer messages securely between the service and: The Government Secure Intranet (*.gsi.gov.uk, *.gsx.gov.uk, *.gse.gov.uk, Secure domains in Local Government/Social Services (*.gcsx.gov.uk) Criminal Justice/Police National Network (*.pnn.police.uk, *.scn.gov.uk, *.cjsm.net). Secure domains in the Ministry of Defence (*.mod.uk) Other secure networks or organisations as from time to time specified by the Customer. 2 The Secure Gateway must provide a lightweight relay service for bulk (application generated) s. This must not support services outside the nhs.net domain e.g. rejects from.nhs.uk domains which attempt to Page 12 of 49

13 disguise themselves (use an nhs.net address). 3 The Secure Gateway must provide: SMTP authentication. Encryption of data in transit to and from the gateway. Access from authorised IP addresses To prevent the lightweight relay being misused there should be an easily accessible console or helpdesk capability to manage SMTP authentication and IP address access. Ability to operate enforced TLS outbound and reject inbound connections that are not encrypted by domain/network. 4 The Secure Gateway must provide non-delivery reports for messages which are unable to be delivered by it. 5 The Secure Gateway must contain functionality to support S/MIME standards. Hygiene 6 The Secure Gateway must provide industry leading anti-virus and antispam filtering capabilities. In addition to commodity content management such as attachment blocking, maximum attachment size, profanity checking, virus/spam filtering capabilities and data leakage prevention e.g. encrypt protectively marked destined for the Internet or a non-secure PSN connected domain. There should also exist options for managing spoofed/forged and items that cannot be checked such as S/MIME encrypted or password protected attachments. Rules should work at SMTP domain levels e.g. block s containing NHS number to a specified internet domain or allow a single customer of the service to block s containing profanities. This includes: Content management e.g. mark as spam if subject contains V1agra Virus/spam filtering capabilities e.g. reject all messages to unknown recipients Data leakage prevention that is standard in the commodity product. This could be encrypt Official-Sensitive destined for the Internet Managing spoofed/forged e.g. insert a warning saying the message is reported to be from an account on the service but has been sent from somewhere else (list from address). Managing items that cannot be checked such as password protected attachments e.g. insert a warning saying the content of the attachment is password protected and could not be virus scanned. Per domain filtering e.g. block encrypted attachments to gsi.gov.uk domains and allow them to nhs.net domains Security 7 The Secure Gateway must provide bi-directional user friendly encryption (including attachments) to any insecure addresses. This is to support exchange to Organisations and individuals operating outside of the secure domains provided for in requirement 1 of this section. This method of encrypting content should support both configurable Page 13 of 49

14 automated and manual methods e.g. encrypting based on protective marking, content or user action. Encryption/de-encryption should not prevent data being searched/discovered for compliance purposes. There should be no additional cost associated with recipients of encrypted replying or generating a new message to a platform recipient address. Recipient authentication should support either Government Gateway credentials or a locally registered and validated identity. This includes: Complying with the customer encryption standards e.g. 256 bit encryption. Supporting different encryption trigger methods e.g. specific text in the subject line ([Secure]), destination domain (public- .com) or protective marking of the (official-sensitive) Inspiring public confidence over the integrity of the service against tampering/ interference Not encrypting outbound until after it has gone into the forensic message archive and ensuring inbound is sent to the forensic archive after gateway decryption. Offering self-service support to recipients Supporting mixed recipients e.g. those on the platform not needing the message encrypted and those not on the platform. 2.3 Mobile Device Management Outcome Mobile device access is becoming the primary method of accessing NHSmail accounts 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 BOD (Bring our Own Device) arrangement with their users. Enforcement of the mobile device policy is critical too, for the security of the service and the confidentiality of patient information. 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 but they are not essential for the replacement service. Organisations are particularly keen to prevent devices that have been rooted or jailbroken from connecting to the service as in many cases this disables many of the security features and preventing devices that do not meet the minimum security requirements. Page 14 of 49

15 2.3.2 Current Situation services are accessed using a variety of mobile devices via the Exchange ActiveSync protocol only. Blackberry devices are used with an Exchange ActiveSync client and not through Blackberry Enterprise/Internet services. A range of standard mobile device policies are applied to minimise the risk of data loss and data aggregation such as requesting device encryption, requiring a device password and limiting the amount of data that can be sent/received to 30 days of and messages up to 500 KB There is currently no restriction on types of mobile operating system or devices. The table below gives the breakdown of usage in May 2014: Device Type Percentage iphone 55% ipad 25% Android 10% Blackberry 2% Nokia 1% Windows 6% Other 1% Usage of mobile devices is small but growing over time Requirements # Requirement Essential 1 The Mobile Device Management service must support the most popular mobile/tablet device operating systems. As a minimum: Page 15 of 49

16 Apple ios. Android (secure app e.g. TouchDown). Android (insecure app) Windows RT. Windows Phone. BlackBerry OS. 2 The Mobile Device Management service must remotely enforce each Customer s mobile device policy on all devices, and must reject any device that: Does not meet the minimum security requirements. Does not enforce the minimum security requirements. Does not report to the service on either of the above. Additionally it is important that sensitive data is safeguarded on the device and not accessible by other applications. Where a device does not implement data caging that device must be blocked also. 3 The Mobile Device Management service must provide organisation administrators with a Mobile Device Management capability, to manage all of an organisation s mobile devices remotely, including: Central and local policies (local policy cannot override central policy). Functions to allow/deny/quarantine by device type, organisation or groups of users. Remove device, expire password, and wipe any data associated with the service. Reporting functions/ capabilities. This includes: Ideally setting a per tenant default security policy e.g. 20 minute auto lock period Setting an organisation override to the tenant default security policy for auto lock e.g. 10 minutes but reject a 30 minute policy Allowing device manufacturer A to connect for all users Blocking device manufacturer B o all users in a specific organisation Allowing an administrator to remote wipe any device in their organisation and a user to remote wipe their own device Reporting capabilities such as allowing an administrator to run a near real time report of devices that have connected in their organisation in the last 24 hours (or time specified), the current central/local policy and rejected/quarantined devices (reports to include relevant information e.g. username, device type last sync date/time) 4 The Mobile Device Management service should optionally provide organisation administrators with a Mobile Device Management capability to detect and block rooted (i.e. jail broken) devices. This should integrate into the other mobile components for customers that purchase this additional service. 5 A fully featured mobile device management capability to provide additional functionality over and above that required for the NHSmail service may be offered as a locally funded top up service. T Page 16 of 49

17 This should integrate into the other mobile components for customers that purchase this additional service. 2.4 White Pages & Directory Service Outcome Health and care covers a vast range of organisations and a large number of staff in the public and private sector. Good quality care depends upon finding the correct person and communicating with them. A central White Pages has the ability to help deliver this as long as it is trusted, accurate and up to date. The directory and white pages provides contact details for people in all health and care organisations, not just nhs.net users. Users will be able to find contact information for a user, group or organisation. This should cover all aspect 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 local administrators being able to easily operate on a large number of entries. Consideration needs to be given to segmentation approaches in the event of the service being used by non-health and care organisations. This will be considered when evaluating role based access controls Current Situation There are a large number of directories that identify users and their contact information: Spine Directory Services (using smart cards for access control). Electronic Staff Record. NHSmail directory. Local directories. Whilst many of these share information between them there is not a single consolidated view of contact information. Local organisations are able to use connectors to provide manual and automatic updates to the current directory. The graph below shows the total number from Jan 2013 to Sep Page 17 of 49

18 2.4.3 Requirements 1.5 Requirement Essential Content 1 The White Pages and Directory Service must provide a directory of people (health and social care/ public sector staff members), organisations, distribution lists, and generic mailboxes. This includes: Separate containers for people, organisations (including sites, practices and departments), distribution lists and generic accounts. Support for territories and then organisation types e.g. all Scottish Local Authorities and all English Hospital Trusts. Ensuring all tenants have access to an aggregated directory of all the individual tenants. 2 The White Pages and Directory Service must provide contact information for each of the entities, as determined by the customer to be useful, for health and care which may include public sector staff/organisations and necessary to support the national NHS network and services. Contact information for individuals is stored on the person record and organisations stored on the relevant organisation record e.g. HQ, site and department. addresses should reflect current and previous such as through a name change, multiple telephone numbers (landline, VOIP, mobile, fax, pager, home, helpdesk), SIP address, website address, social media addresses (organisations Facebook page or twitter account) 3 The White Pages and Directory Service must be for use by and contain information on all health and care organisations and relevant public sector organisations, not just those using NHSmail. 4 The White Pages and Directory Service may cater for users who work for more than one organisation, making it clear that they are a single person working in multiple organisations. Page 18 of 49

19 Access 5 The White Pages and Directory Service must be accessible by all health and care staff (public and private and third sector) and other public sector staff through role and location based access controls. It must not be publicly available on the internet. It should support limited attribute access in the case for example of use by authorised third parties. This includes: A public sector user seeing all user facing fields anonymously over a public sector network A public sector user seeing all user facing fields after authenticating over a public network. A public sector user seeing after authentication additional information only visible to members of their organisation A private company only seeing a small subset of fields after authenticating e.g. not seeing mobile number or home phone number An administrator seeing non user facing fields after authentication e.g. local unique identifier Administration 6 The White Pages and Directory Service must support an extensible schema to allow additional attributes to be added for users. This includes: The ability/capability to add additional directory fields usable across the tenant. The capability for each organisation to have a small number of fields uniquely available to them. This could be simply some additional fields available to all organisations e.g. custom attribute 1, custom attribute 2 etc. which are visible to all organisations or if supported by the directory service per organisation unique fields only visible to members of that organisation. 7 The White Pages and Directory Service must support the Customer s organisation hierarchy and be sufficiently flexible to accommodate regular restructuring. This includes: The capability to support hierarchy at least ten levels deep (e.g. territory > public sector category (Health) > Top level (local area team) > sub level 1 (clinical commissioning groups, acute trusts) > sub level 2 (GP Practices, Pharmacies) > sub level 3 (top level department) > sub level 4 10 (subordinate departments). Flexible hierarchy configuration/management e.g. a mapping table/business rules function where relationships are maintained. The ability to change the hierarchy e.g. acute trusts in sub level 1 change their parent from a Strategic Health Authority to a Local Area Team or change a Primary Care Trust to a Clinical Commissioning Group. 8 The White Pages and Directory Service must allow users to update elements of their individual entries where permitted by their organisation. Each organisation should be able to specify which fields are self-service and how the organisation sets validation rules for them with helpful user feedback Page 19 of 49

20 when validation rules fail e.g. when trying to put a home telephone number and including letters a helpful error message is displayed. 9 The White Pages and Directory Service must allow health and care administrators to maintain data quality on both individual entries and in bulk e.g. using advanced search criteria and applying changes to the result set through the web interface or a programmatic interface. The Directory Service must support administrators to maintain data quality e.g. a reporting capability that all user and non-user facing fields are available e.g. local unique key and highlights data errors and what needs to be done to correct them. Integration 10 Health and care has a number of national directory services, for example the Electronic Staff Record and Spine. Local organisations will have others. Still more may be provided by the Public Services Network. The Directory Service must integrate with these directories through industry standard interfaces. Authoritative updating of fields will be on a per Organisation basis from nominated authoritative data sources. The ability/capability to set up and manage different data sources to update the white pages/directory through an industry standard programmatical interface for person entries and organisation entries. Examples of the types of likely updates are as follows: User directory entry creation Creating a new account on the directory User directory entry deletion Removing an account no longer needed immediately in the case of a deceased person if an account or in the case of a contact its immediate removal. User directory entry modification - A user changes their surname and the record is updated plus the primary address is changed to the new name and the old address is made a secondary address with changes as required to distribution lists. - A group of users move to a new office and their location details are updated - A user is marked as a leaver and retains temporary access to their account until it is joined to another organisation or deleted after a specified period of being in a leaver state. - An address is changed and that change is reflected in any dependant distribution lists. - Possibly account status such as suspend and reinstate. Support for multi mastering where a person entry is updated from multiple data sources e.g. some attributes authoritatively maintained by a national HR system that populates data (person and employer details), some maintained Page 20 of 49

21 by a local organisation system that populates data (VOIP number) and some by the user directly on the portal (phone number). Organisation data batch process support adding, changing and closing a range of entries: - When adding validate data and alert an administrator where action is required before the activity can be completed e.g. set an organisation shortname, incorrect County value identified or duplicate organisation code - When closing an organisation (close date is in the past) mark as a leaver all dependant objects (mailboxes, generic mailboxes and distribution lists) and remove all other objects. Supporting pick list data (job roles, work areas, specialties, organisation types) Supporting industry standard interfaces being offered such as LDAP/LDUP, SQL and CSV and a bi directional capability (sending back processed changes to update local systems). The ability to run in report and run mode with reports detailing potential and actual changes. 11 The White Pages and Directory Service must provide the ability for local health and care organisations to query the directory using standards-based methods. Examples include a local web based staff search system, a local VOIP phone system being able to query phone numbers or a local presence based service able to leverage the directory. Migration 12 The White Pages and Directory Service must seamlessly take over from the existing NHSmail directory. This will include migration and co-existence capabilities. Search 13 The White Pages and Directory Service must provide a powerful advanced search and browse function, with the ability to search (and filter search results) by organisation, role and other criteria. Examples include a basic and advanced search capability: By type (person, generic mailbox, distribution list and organisation) and then common search fields (name, address, practice, site, department, job role and specialty) with an advanced search capability to search for additional multiple fields and use more complicated search operators (contains, begins, not like). Organisation has sub categories such as sites, departments and practices. Hierarchical browse Territory > public sector category (Health) > Top level (local area team) > sub level 1 (clinical commissioning groups, acute trusts) > sub level 2 (GP Practices, Pharmacies) > sub level 3 (top level department) > sub level 4 10 (subordinate departments). Organisational type browse and drill down to subordinate e.g. select Clinical Commissioning Groups, see a list of them all and then select one to drill right down to an individual GP within a GP Practice. Page 21 of 49

22 Page 22 of 49

23 3 Breakdown of Optional Components The following optional components are all individual components of the service. These are components that the Supplier has an option to incorporate as part of their solution, or make available for purchase by Health and Care organisations. The Essential and Top Up elements of Optional Components indicate the minimum requirement that must be satisfied for Health and Social Care Organisations to use these services. Each of these individual components is accompanied by all of the common components in Section 4 below. 3.1 Insecure Gateway Outcome There is a central gateway for nhs.uk services operating on PSN Current Situation A number of NHS organisation run their own local nhs.uk service. These systems operate at no security level or accreditation and in some cases utilise internet routing. For those services operating on the N3 network the central nhs.uk gateway (referred to in the NHS as the Relay Service) checks all messages sent and received for spam and viruses. In February 2013 the service checked for just over 1,800 systems supporting just over 3,000 nhs.uk domains. The service utilises its own internet gateway to send/receive for non nhs.uk addresses and the N3 network to send/receive for nhs.uk addresses. The nhs.uk gateway does not process any sensitive data as if any sensitive data needs to be exchanged it is the responsibility of the sender to encrypt the content prior to transmission. The service relies completely on the N3 DNS service for routing and maintaining an internal (N3) and internet facing set of mail routing records. It is currently assumed that this service will continue to be provided in the future. The service does not need to provide any service for those Organisations running their nhs.uk service over the Internet. It should be noted that many of the common requirements do not apply to the nhs.uk gateway. The decision to replace this service is currently under review and once confirmed the applicable commodity elements for this service will be explicitly listed Requirements # Requirement Essential 1 The nhs.uk gateway must accept from any N3/PSN connected nhs.uk service verified by reverse DNS lookup and relay it via the private DNS service for nhs.uk addresses and the internet DNS service for all other . for the Internet will be routed via the Page 23 of 49

24 service providers own Internet connection. Where a connection is authenticated with a username/password the service should disregard the credentials and accept the connection anyway. 2 The nhs.uk gateway will receive destined for nhs.uk addresses via its own internet connection and relay it via the private DNS service. 3 The nhs.uk gateway must provide non-delivery reports for messages in an easily understandable format which are unable to be delivered by it. 4 The nhs.uk gateway must contain functionality to support S/MIME standards. Hygiene 5 The nhs.uk gateway must provide industry leading anti-virus and anti-spam filtering capabilities. In addition to commodity virus/spam detection the service should also support attachment blocking, maximum attachment size and profanity checking. Data Retention and Compliance 9 The service should only retain 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. Reporting 10 The service should provide a capability to support local billing should it be introduced in the future providing monthly volume reports by domain. 3.2 Instant Messaging and Collaboration Outcome Users across health and care have access to an instant messaging and collaboration service 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 NHSmail users. Suppliers should recognise the need to collaborate beyond the service. Page 24 of 49

25 3.2.2 Current Situation Each health and care organisation has chosen its own instant messaging solution, or chosen not to have one. Some organisations have bought their own conferencing facilities, especially for uses such as MDT (Multi-Disciplinary Team) meetings. In many cases there is no integration between organisations or indeed different vendor solutions Requirements # Requirement Essential 1 The Instant Messaging and Collaboration Service should include: Instant messaging including location, availability and presence information. Audio conferencing. Video conferencing. Shared workspaces / documents. VoIP (Voice over Internet Protocol) integration. A basic instant messaging capability is desirable for all users. If available in the vendor s commodity product at no additional licensing cost this should be made available to all, thus providing the most rich user experience possible. If the vendor cannot provide a commodity product at no additional cost then they should detail what they can offer and how this can be incorporated in the solution. 2 The Instant Messaging and Collaboration Service should work across health and care organisations, and integrate with the relevant service components. Standard based integration with other services such as XMPP is preferable. 3 The Instant Messaging and Collaboration Service should integrate with the directory service. It should provide directory information on its users and organisations to the directory service. It should use the directory service to look up addresses, distribution lists, phone numbers, and other entities. Ideally this should support different presence/availability statuses across the service e.g. a consultant appears available in their hospital but not to other organisations that use the service. 4 The Instant Messaging and Collaboration Service should provide shared spaces for users during a conversation, such as shared whiteboards, shared documents, and shared device desktops. 5 The Instant Messaging and Collaboration Service may, where safely available and where possible, provide 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. Content Protection 6 The Instant Messaging and Collaboration Service must provide industry leading anti-virus protection. In addition to commodity content management such as attachment blocking and virus detection there should also exist options for data leakage prevention and items that cannot be checked such as password protected attachments. Page 25 of 49