|Requirement ID||Requirement Text||Level|
Authentication - Access using NHS authentication
Any access to Personal Data or sensitive Personal Data within Solutions to be subject to NHS authentication (as per Authentication and authorisation section of Interoperability Standard).
Authentication - General standards
Any access to Personal Data or sensitive Personal Data within Solutions will be subject to authentication at least to standards described in GP-IG-2.2-1.
Authentication - NHS authentication with no additional authentication
Solutions shall ensure that, where NHS authentication (as per Authentication and authorisation section of Interoperability Standard) is used, those users are able to carry out all Solution activities (subject to their access rights) without the need for any additional authentication.
Authentication - Local
Users not using NHS authentication (see GP-IG-2.1-4) can only use local authentication and will not therefore be allowed access to Solution functions for which NHS authentication is required.
Application start-up message
The application shall prominently display the following message upon application start-up to remind users of their responsibilities and the legal constraints on the use of the Solution:
Note that this wording can be updated from time-to-time.
Enable user role and organisation validation
The application shall make it possible – by clearly and continually displaying the user’s name, role and organisation – for users to validate the role and organisation relevant to the access they are being granted so as not to be able to claim ignorance of that role or organisation, or otherwise justify a lack of awareness of the significance of their actions.
Audit authentication activity
All activities associated with requirements in this section will be recorded in the Solution Audit Trail. Such Audit Trail entries can also include end-user device (or Solution) identification information.
Local authentication model
The Solution can provide a local authentication model to provide an alternative method of authentication for users who are unable to use NHS authentication.
Access to records on the Spine will use Authenticator Assurance Level 3 - ref: NIST 800-63-b
Two-factor authentication can be used for local authentication.
Access to records on the Spine will use Authenticator Assurance Level 3 - ref: NIST 800-63-b
Two-factor authentication for Citizens
Two-factor authentication will be used for Citizens to log into Solutions.
Local authentication - unique user identity and password
Any local authentication will be based on a unique user identity which is then authenticated at least through the use of a password.
Local authentication - password strength and management
Local authentication will satisfy the password strength and password management guidance set out in Meeting the Digital Service Standard and Password Guidance
Where passwords are stored in Solution databases, they will be stored salted and hashed, using algorithms and strengths recommended in NIST Cryptography Standards
User access and password Audit Trail
Successful login, unsuccessful login attempts, logouts and password changes will be recorded in the Solution Audit Trail. Data to be included in such an Audit Trail entry:
Successful login, logout:
- User id
- Date and time (to the second)
- Number of attempts
- Date and time
- Access point (if available)
- User id (if available)
- User id
- User whose password was changed
- Date and time
Such Audit Trail entries to also include end-user device (or Solution) identification information.
New user - password creation
New users will be assigned, or will be required to enter, a password matching password-strength requirements in GP-IG-2.2-3.
New user - define own password on first use
If initial password is assigned, the new user will be required to set a password that meets the password-strength requirements in GP-IG-2.2-3, upon first use of the Solution.
Password-reset facilities are provided; the Solution will store additional information associated with each user so as to allow newly-generated passwords to be provided securely to devices previously known to be associated with the user (such as mobile number or NHSmail email address). Any such newly-generated passwords cannot be made visible to Solution-administration staff, and following first use of such passwords, the user will be required to set their own password.
Role-based Access Control
Role-based access control
The Solution will have role-based access control to authorise users’ access to the Solution functions and data.
For NHS authentication requirements see Authentication and authorisation section of Interoperability Standard
Updates to Job Role to Baseline Activities
The Solution will have a process for incorporating updates to the nationally-defined mapping from Job Role to Baseline Activities as published by NHS Digital.
Local role-based access control
Where the Solution supports users who do not use NHS authentication, the Solution shall implement local role-based access controls which support the allocation of access rights. These are in line with the nationally-defined Job Roles and Activities taken from the latest National RBAC Database.
Local RBAC mechanisms will need to:
- Allow users to have different access rights for each of their roles
- Restrict users’ use of the Solution to specific functions, assigned only by the Solution manager(s);
- Not allow any user access to their allocated functions until they have authenticated
Access controls to include the ability to segregate access to the following functions:
- Viewing the Audit Trail
- Accessing inactive staff details
- Accessing the records of Patients/Service Users that are not normally accessible to Solution users (for example, in the case of Catalogue Solutions, to the records of patients that are not currently registered at the practice)
Local authentication - local access rights
Where Solutions provide local authentication (see GP-IG-2.2-1) that can be used by users who are enabled to use NHS authentication, any local access rights to automatically reflect the access rights associated with the user as defined on Spine, i.e. without any manual update mechanism being required and no increased access rights can be locally associated with the local based authentication.
Role-profile and Organisation Context matching
The Solution will ensure that the Organisation Context of the Solution matches the selected role-profile. Where the Solution supports a single organisation, that organisation to match the organisation from the selected role-profile for any user access to proceed. Where a particular Solution supports multiple organisations, the Solution shall set the Organisational Context to that of the selected role-profile (and thus influencing the control as to what Personal Data the user has access).
Organisation Context transparently set based on Patient/Service User
There can be specific circumstances where a user requires access across organisational contexts using the same or different Solutions (where it would be impracticable for that user to explicitly manually change their role-profile selection). Examples would include where more than one Organisation (with their own ODS code) shares a physical location and can share administrative staff where:
- The same instance of a Solution is used by all Organisations, thus the need to switch organisational context without re-authentication, or
- Separate instances of the same, or a different, Solution are used by each Organisation, thus the need to be authenticated in the context of multiple organisations simultaneously.
In such circumstances, the Solution will provide facilities for the user’s organisational context within the Solution(s) to be transparently set according to the Patient/Service User being accessed, subject to all of the following:
- The user to have separate role-profiles (with equivalent rights) for each organisation to which these arrangements apply;
- The Solution will be specifically configured to allow defined users to have “roaming” access across a specifically configured group of organisations;
- The Solution at all times will make it clear to the user which organisational context is in force;
- The Solution's Audit Trail will accurately reflect the organisational context.
Provide local Solution functions to RBAC mappings
Suppliers will provide details of the mapping of their local Solution functions to activities from the National RBAC Database. This is to support the Registration Authority (RA) process (to ensure that RAs have information to enable them to correctly define positions and allocate users to such positions, or by allocating users individual User Role Profiles containing appropriate job roles and any additional activities) and also to support the compliance process.
Support users having multiple roles with own associated activities
The Solution will support the concept of a user having more than one role, each with its own activities.
Activities restricted to logged in user role
The Solution can only support the activities associated with the role that the user has logged in under. The Solution will not combine activities from multiple roles for the purposes of controlling a user’s access to the Solution.
Support non-RBAC roles
The Solution can support roles (e.g. GP, Practice Nurse) and activities that are not part of the National RBAC Database but which extend or elaborate the National RBAC Database. Any such roles or activities will not contradict or conflict with the National RBAC Database.
Specific professional status
The Solution will support the notion of specific professional status for users, to support areas of functionality where there can be, for example, statutory reasons to restrict such functionality to certain professional groups (for example where fitnotes can only be issued by GPs).
Non-RBAC role details
Support definition of the following detail for non-RBAC roles:
- Start date
- End date
- Status (active, inactive)
View local Solution access levels
Ability to view local Solution access levels for all Staff Members (with a list of their roles and activities, detailing start and end dates and any periods of inactivity)
Access to the records of non-active Patients/Service Users
Access to the records of non-active Patients/Service Users can be provided within a grace-period following inactivation (such a period to be configurable per organisation, default 4 weeks).
- Access to records during such a period will generate a notification (a warning, rather than alert) to the user designated as the organisation’s Privacy Officer (see Alerts section)
- Access to records beyond such a period will only be possible after the user has provided a reason for access, and will generate an alert to the user designated as the organisation’s Privacy Officer (see Alerts section)
- If such access is provided to multiple Patients/Service Users as a result of running a report, a single notification or alert will be provided (rather than one per Patient/Service User)
Reactivate Patient/Service User record - alert
The act of making a Patient/Service User record active (from an inactivated or archived state), when carried out without a formal Patient/Service User re-registration, will generate an alert to the user designated as the organisation’s Privacy Officer (see Alerts section).
View information managed in separate organisations - Active Patients/Service Users only
Where the Solution provides the ability to view information managed in separate organisations, these controls are to ensure that information is only made available if it concerns Patients/Service Users with a currently active registration. For example, any cross-organisational data sharing will not take place for inactivated, or archived, Patients/Service Users.
Information Sharing across Organisations for Direct Care
“safe and appropriate sharing in the interests of the individual’s direct care should be the rule, not the exception”
Caldicott review: information governance in the health and care system
There are different ways in which information is commonly shared across Organisations; for example:
- Providing information to accompany, for example, routine referrals of the patient to other care settings; in such circumstances, providing information is an essential part of the process. Solutions will support this type of scenario; requirements are defined as part of the Catalogue Solutions Requirements.
- Allowing information from within the practice to be accessible in other care settings; this might follow an explicit referral (for example, the clinician within an outpatient clinic might feel it is helpful to review parts of the patient’s general practice record that have not been included in an original referral letter) or might be as a result of a patient’s attendance at an unscheduled or urgent care setting.
The requirements in this section are intended to recognise that:
- There is a national system for recording Patient/Service Users’ expression of their “consent-to-share” (a flag held on PDS), but this is a global setting and does not allow Patients/Service Users to specify which information they consent to share, nor in which circumstances.
- Some Patients/Service Users have previously expressed their dissent to information sharing, which is recorded using that mechanism.
Data sharing - recording Patient/Service User expressed preferences
Solutions will provide the capability to record a Patient/Service User’s expressed preferences as to how clinical information about them, can be accessed from other care settings, for their direct care.
Where Solutions are directly used in other care settings, it is expected that such preferences can be managed at the level of individual operational units or settings in which Patients/Service Users would reasonably expect their information to be shared without hindrance, in order to support their direct care.
Organisational change - Patient/Service User preferences carried forward
Organisational structures change over time, for example as practices merge or split. In such circumstances, every Patient/Service User’s expressed preferences will be carried forward into the new organisational structure, on the basis that Patients/Service Users have been made aware of the implications of any such proposed change, prior to it taking place, and that Patients/Service Users had the opportunity to amend their expressed preference.
Practice controlled information sharing
The practice is to have control as to whether information sharing (access to information from other care settings) for any patients is enabled, so as to allow alignment with any practice-wide information campaigns.
See Confidentiality: Good Practice in handling patient information for guidance around information handling.
Respect recorded preferences
The Solution will respect any such recorded preferences, having effect on the sharing of information that might otherwise be technically possible.
Preferences for sharing data into the Organisation from other care settings
If the Solution also supports access to information from other care settings, then it will need to also support the recording (and respect of) expressed preferences whether information about them from specific other organisations can be viewed from within the Organisation.
It is not necessary that an explicit consent to such sharing be recorded within the Solution prior to any such sharing taking place, other than the exception condition described in requirement GP-IG-5-6A.
PDS - express dissent setting
Some Patients/Service Users have an “express dissent” setting (value 2) on the consent-to-share flag held nationally on PDS, to be interpreted that the Patient/Service User has previously expressed concern about potential information sharing for their direct care across different care settings.
For such Patients/Service Users, making their Personal Data available to other care settings will need to be on an “opt-in” basis, rather than the default “opt-out”. Therefore, in that situation, Solutions will have to prevent any access to information from other care settings, unless the Patient/Service User has explicitly consented to such sharing in the local Solution through facilities provided in requirement GP-IG-5-5.
Information sharing prompt
In circumstances where both (i) the Patient/Service User has an ”express dissent” (value 2) setting nationally, and (ii) the Solution has not recorded any expressed decisions from the Patient/Service User, the Solution will prompt the clinician as part of an encounter with the Patient/Service User, to provide an opportunity to confirm the Patient/Service User’s intentions through the facilities described in requirement GP-IG-5-5.
Amending consent to share status on PDS
The Solution to support the amendment of the Patient/Service User’s consent-to-share status held on PDS:
- If the status is not “express dissent” (value 2), but the Patient/Service User has chosen to determine that, using facilities provided under requirement GP-IG-5-5 no information is to be made available for their direct care outside the Organisation, then the consent-to-share flag to be automatically set to “express dissent” (value 2)
- If the status is “express dissent” (value 2), and the Patient/Service User has chosen to take advantage of facilities as described in requirement GP-IG-5-5 to allow access to information from the Organisation, the facility to be provided to support the setting of the consent-to-share flag to “express consent” (value 1). The suggested wording of the prompt to change the setting is:
“It has previously been recorded on a national system that you have expressed concern about information sharing for your direct care. You may leave this in place, in which case you may be asked again for your explicit consent in other care settings, or if you move practice in the future. Alternatively, you can have it changed, indicating that you no longer wish to record any concerns about information sharing nationally for your direct care. Would you like to confirm this?”
Provision of online services - information protection
The provision of online services to Patients/Service Users inevitably requires the exposure of sensitive Personal Data outside previous controls; whilst Patient/Service User Record Solutions have been, and will continue to be, hosted within the controlled environment of HSCN or its successors, there will be additional vectors of attack due to the availability of internet-facing services.
The technical architecture of the interface mechanism and any supporting infrastructure to satisfy the requirements in this document will:
- Satisfy the requirements of IGSoC or equivalent successor
- Be subject to annual penetration testing as a minimum, or to coincide with significant Solution changes
- Continually incorporate best-practice monitoring and intrusion-detection mechanisms
Additional Privacy Controls
Restrict access to entire Patient/Service User Record
It will be possible to restrict access to a Patient/Service User’s entire Record.
It will be possible to apply such restrictions at the level of RBAC user roles and to custom groups of Staff Members
Access not restricted to individual parts of Patient/Service User Record
It will not be possible, over and above the use of RBAC in general, to apply restrictions to individual parts of a Patient/Service User Record.
All restrictions will be as a result of an explicit, audited, action by an authorised user. Local Organisational policy can suggest specific records where restrictions might be appropriate, but restrictions will NOT be automatically applied by the Solution.
Restrictions - not apply to data transfers
Restrictions applied to records will NOT interfere with their inclusion in data transfers (for example as a result of a patient changing practice, or as part of a data migration between Solutions). It is expected that in these circumstances, as described in published guidance, any locally-applied restrictions will be removed.
Workstation Access Controls
User Solution lock facility
The Solution shall provide a facility for the user to lock the Solution with a single action, this action hiding any Personal Data from view and ensuring that re-authentication is required for the application to be resumed.
Session return through re-authentication
When access is denied due to the requirements in this section, the same user can return to their session by re-authenticating, or any other user can log off the previous session (without returning to it) in order to be able to proceed with a new session. Where another user has logged off the previous session, the Solution need not retain the previous session.
Labelled Personal Confidential data hard-copy output
The requirements in this section are not intended to affect the printing specifications for prescriptions or dispensing tokens as specified by the EPS requirements, or for any other outputs that are subject to separate requirements.
Labelled information on screen
The Service shall provide for the protective labelling of information (as described in GP-IG-9-1), which is output to screen rather than hard-copy, to be made known to each user either:
- by being shown on any screen displaying the information; or
- by being displayed to the User upon logging into the Solution (for example as part of an acceptable use policy).
On-screen labelling - standardised location and manner
Where alternative (a) in requirement GP-IG-9-2 above is chosen, the protective labelling of information to be shown in a consistent location and manner on any screen displaying the information.
Hard-copy labelling - standardised location and manner
The Supplier shall ensure that the protective labelling of the information is shown in a consistent location and manner on any hard-copy output displaying the information.
Identify that hard-copies are complete
The Supplier shall ensure that the Solution provides a means for users to verify that hard-copy print-outs are complete (e.g. "page 3 of 5" annotations).
Record provenance details for all Personal and sensitive Personal Data
The Solution will record the following provenance details of all Personal and sensitive Personal Data recorded within the Solution:
- Author details (identified through unique ID), including name and role
- Data entered by (if different from author)
- Date & time (to the second) entered
- Originating organisation
- Encounter context
Record provenance details of information shared across Organisations
The Solution will record provenance details of information being sent, together with provenance details of information that might be entered into the Solution, based on incoming information. For example, a document from a separate, sending Organisation can be sent into the receiving Organisation, and some summarisation activity can then take place within the receiving Organisation. The Solution to record:
- The provenance of the incoming document, and
- The provenance of any information entered locally as a result of the incoming document, and
- The linkage between the locally-entered information and the incoming document.
Make provenance information available to users
The Solution to make access to provenance information available to users. Whilst some details (such as name, role) associated with individual users are likely to change over time, the display of user information will reflect the state of such information as it was at the time of the associated event (such as data entry).
Identify information displayed from outside organisation
Where data is being displayed from outside the organisation, information from other organisations to be made immediately clear to the user. Such visual indications to be the means by which users can access the provenance data for those items.
Data Suppression & Removal
Prevent removal of Personal Data
Other than in the specific circumstances described in subsequent requirements in this section, the Solution will NOT allow any user to remove Personal Data, for example from the electronic Patient/Service User record (whether that be a “logical delete / soft delete” causing information to be hidden from view, or a “physical delete / hard delete” causing information to be physically deleted from the clinical data repository).
The Solution can support a specific reason of “withdrawn”, for example to be used to withdraw a stated diagnosis, and in such circumstances the Solution will ensure that any secondary uses to which the clinical data is put (such as QoF calculations or clinical audit activities) exclude any such “withdrawn” entries. The Solution will also provide a mechanism to allow any such “withdrawn” entries to be filtered from the view of the Patient/Service User Record, in which case it will be clearly visible that the view of the record is a filtered one. The Solution default view can be filtered.
The Solution will provide the ability for users to “logically delete” entries in a record: i.e. resulting in the underlying data being marked in such a way that it is no longer visible to any user of the record.
The requirements associated with this functionality vary, according to whether the information being deleted has been able to be viewed by other users (or accessible by Solution processes).
If such data has not been viewable (for example where a user discovers during the recording of a consultation that they are entering data in the record of a different Patient/Service User, or where the user recognises they have made an error):
- the Audit Trail will record the sequence of events in such circumstances
- the record to be re-constituted to show entries that have previously been logically-deleted, but such functionality will only be available as part of a back-office task, for example to support forensic investigation
- the Solution to ensure that it ignores all logically-deleted data for any secondary uses to which clinical data is put (such as QoF calculations or clinical audit activities)
Alternatively, where data is being logically deleted that has previously existed in the record, and has been accessible to other users (for example where a Patient/Service User feels that information in the record is damaging, that an annotation is not sufficient, and requests that information from the record is deleted; note that this is most likely to be true where information has been previously entered into the record in error):
- the record to be re-constituted to show entries that have previously been logically deleted, but such functionality will only be available as part of a back-office task, for example to support forensic investigation
- the normal view of the record will show the fact that information has been logically deleted; it will be possible for the user to access details of who authorised the logical deletion (including date/time, authoriser, reason)
- an alert – as described in Alerts section – to be generated whenever this functionality is used; where there are multiple uses of this functionality for a particular Patient/Service User’s record, within the same user session, only a single alert is required.
- the Solution will prompt the user to confirm that the Patient/Service User has requested such a logical deletion, that the user has considered the impact on future uses of the record, and has concluded that the benefits to the Patient/Service User of having information logically-deleted outweighs any potential risk associated with an incomplete record
- the Solution will store details – including the user’s acceptance of the request and risk-assessment – of the logical deletion in the Audit Trail
- the Solution to ensure that it ignores all logically-deleted data for any secondary uses to which clinical data is put (such as QoF calculations or clinical audit activities)
The Solution will support the physical deletion of records or parts of records in response to court orders or other legislative circumstances. This functionality NOT be made available to normal users of the Solution , and local Solution administrators will NOT be able to grant access to such functionality to normal users.
Such physical deletions are expected to be rare – the functionality described in requirement GP-IG-11-3 is expected to satisfy the great majority of scenarios. Therefore, physical deletion shall be initiated through a supplier’s service desk facilities, but shall only be carried out in response to a specifically authenticated and validated request from an organisation’s Caldicott Guardian or Privacy Officer, co-signed by a senior clinical representative. Such requests shall be audited and retained by the supplier.
In such circumstances it will NOT be possible for any user, or back-office process, to reconstitute the state of the record to that prior to any such physical deletion.
This functionality will NOT modify the Solution Audit Trail, other than is necessary to support this requirement. The fact of a physical deletion (without referring to data content) will be recorded in the Solution Audit Trail but such entries will NOT be visible to normal users of the Solution.
There are several related mechanisms defined in requirements, which are compared in the following table:
Typically initiated by
Visible marker of use?
Example / use case
Yes, by user
Information Governance#Logical deletion
User (during data entry)
User or Patient for previously-committed data
Yes, by back-office
Yes, for previously-committed data
i) clinician discovers error during data entry
ii) patient wishes damaging information to be hidden from all future users; clinician agrees that this will not impact future care.
Patient wishes damaging information to be hidden from all future users; court so orders.
Solutions to provide Audit Trails, sufficient to support the following purposes:
- To enable and support investigations, e.g. into Solution misuse
- Identifying changes to Patient/Service User related, clinical and administrative data, identifying what changes were made, by who and when
- To monitor whether access controls are operating as intended
- In support of the Care Record Guarantee, to enable fulfilment of requests from Patients/Service Users as to who has accessed or modified their Sensitive Personal Data or Personal Data; when that access or modification occurred and the nature of the information output (that is, displayed or printed).
- Identifying details of any configuration (e.g. a spine service being switched on), Solution updates, data backups and other Solution maintenance activities or reference data changes (e.g. an update to the clinical coding scheme data, drug databases) applied to the Solution.
Application level Audit Trails to be subject to the same level of controls as the electronic Patient/Service User record.
Include all information about exchanges with external Solutions and organisations in Audit Trails
The Solution shall ensure that Audit Trails are kept which record information about all information exchanges with external Solutions and organisations, including but not limited to:
- All attempts to use an SSO Token ID to access to an application – including both successful and failed attempts. “use of a token” is interpreted to mean a call to the SSOTokenManagement API to validate a token.
- All message interactions – sent and received
- All interactions with the Spine SDS
- All data access or presentation from separate organisations or Solutions
Such Audit Trails shall provide a security record for use in analysing breaches of security and policy that might be used as evidence for use in disputes.
Viewing Patient/Service User record as per previous date
A means of viewing or reconstructing any individual Patient/Service User record as it was on any previous date will be supported, taking into account the requirements stated in GP-IG-11-4.
View/filter/sort Audit Trails
The Solution shall provide facilities to allow Authorised Users (e.g. a Caldicott Guardian or Privacy Officer) to view Audit Trails. This is to support commitments made in the Care Record Guarantee.
Such facilities to include the ability to display, filter and sort parts of the Audit Trail based on at least the following parameters (both individually and in combination):
- Patient/Service User id (normally expected to be the NHS Number)
- User id
- Organisation id
- Date & time
Whilst some details (such as name, role) associated with individual users are likely to change over time, the display of user information to reflect the state of such information as it was at the time of the associated event (such as data entry).
Audit Trail minimum information
The Audit Trail records provided for GP-IG-12-1 and GP-IG-12-2B shall include the following minimum information:
- a record of the user identity. This is the User ID, Name, Role profile (including Role and Organisation, URP id when Smartcard authenticated) attribute values, obtained from the user’s Session structure;
- a record of the of the authority – the person authorising the entry of, or access to data (if different from the user);
- the date and time on which the event occurred;
- details of the nature of the audited event and the identity of the associated data (e.g. Patient/Service User ID, message ID) of the audited event.
Audit Trail records to include details of the end-user device (or Solution) involved in the recorded activity.
Restrict access to Audit Trails via RBAC or local access controls
The national set of RBAC roles and activities are published in the National RBAC Database (NRD), and contain activities that are valid for access to Audit Trails. Suppliers will ensure that Solutions are configured to support the most current release of these. If suppliers have not implemented the national RBAC model then the local access controls can demonstrate that only appropriate roles can access the Audit Trail.
See RBAC section for access control requirements
Deleting Audit Trails
The Solution shall ensure that records in the Audit Trail can only be deleted by a privileged user under specific conditions; such as court orders. Note that such deletions are expected to be very rare, and it is important that access to such functionality will be stringently controlled. It will not be possible for any local user to have such rights as a matter of course, and it will not be possible for any local administrator to be able to grant such rights to any local user. Any attempts to manually update or add to the Audit Trail to be prevented as far as is practicable, to ensure the integrity of the Audit Trail, and protect against attempts to tamper.
Audit Trails enabled at all times
All Audit Trails shall be enabled at all times and there shall be no means for users, or any other individuals, to disable any Audit Trail.
Audit Trails included in routine Solution backup
All Audit Trails shall be included as part of the routine Solution backup. This shall include:
- Application-level audit log files – the events defined above.
- Operating-Solution security audit logs – containing events relating to security at the workstation/server level, e.g. login events, changes to security settings, etc.
The Audit Trail can be moved to archive storage as required for efficient Solution operation, but shall be retained in accordance with the audit retention policy as specified in Records Management Code of Practice for Health and Social Care 2016 to allow access as specified above in requirement GP-IG-12-4 .
Where audit data has been previously archived, it will be made clear in audit viewing tools or other arrangements that some audit data might not be immediately available, but that it can be retrieved (with an indication of steps to take to make such archived data visible).
Audit trail copies
Copies of the Audit Trail to support the following:
For forensic purposes, a separate copy of the Audit Trail (in the original live environment format) to be used from the version in the live environment
For other reporting and querying purposes, a different separate copy of the Audit Trail to be used from the version in the live environment
Link archived records to Audit Trail
In a Solution where any Patient/Service User records are archived (made inaccessible to normal Solution access) then a link will be maintained between the archived records and the Audit Trail, to ensure that the audit records associated with archived records remain accessible.
Auditing Solution upgrades
Suppliers to ensure that during upgrades to Solutions, any manual steps are documented in advance and any automated steps to involve the production of one or more logs which describe each step being taken and whether or not it has been processed successfully. Logs that cover a sequence of steps will also indicate whether the overall sequence has been a success or failure.
The timestamps in Audit Trail entries shall be stored in UTC, to the nearest millisecond. When displaying audit entries to authorised users, they shall be displayed by default in local time (with clear indication how this will differ from UTC).
Inform user alert will be generated
There are a number of requirements elsewhere in this document (which reference this alerts section) where it appropriate for specific actions to be permitted, but an alert to a Privacy Officer will be raised to ensure appropriate governance of actions can be maintained. In such circumstances, the Solution shall ensure that the user is made aware that an alert will be raised, and is provided with the ability to enter a reason for their action.
In such circumstances, an alert containing the following information will be made available to the individual within the organisation designated as Privacy Officer:
- Date and time (to the second)
- Context of the Solution at the time the alert was raised (including Patient/Service User identification)
- Reason entered by the user
The alerting mechanism can use the mechanism within the Solution as defined in Workflow Capability.
Levels of alerts
The alerting mechanism shall support at least two levels of alerts: notifications (warnings) and full alerts. Notifications are for occasions when there is a legitimate, but unusual, activity taking place (such as the access to a record of a newly-archived Patient/Service User) whereas alerts are for exceptional conditions (such as accessing record of Patient/Service User that has been deducted for some time).
Privacy Officer notifications
The Solution will allow the designated Privacy Officer to receive notification of each alert, as it is raised, in a timely manner (within 10 minutes), and to view the details (including level, date, time, context, reason) of the alert.
The Solution will allow the designated Privacy Officer to view all alerts.
Record actions associated with alerts
The Solution will allow the designated Privacy Officer to record the actions carried out associated with each alert and to change the status of alerts (e.g. new, in-progress, completed).
The Solution will allow the designated Privacy Officer to filter and/or organise the view of alerts according to (either individually, or in combination):
- User involved
- Patient/Service User involved
Mandate recording of Privacy Officer
The Solution will NOT allow go-live for a specific organisation without a Privacy Officer being configured within the Solution. It is important that there is at least one individual user per organisation designated as Privacy Officer at all times; the Solution shall enforce this, for example by ensuring that an individual designated as the Privacy Officer cannot be removed from the Solution prior to another individual being so designated.
Support Response to Subject Access Requests
The Supplier shall ensure that the Solution supports responding to Subject Access Requests (e.g. by providing the required data) in accordance with the General Data Protection Regulation (GDPR)
Any historical Personal Data, that can be linked to the current active record (for example as a result of a GP2GP transfer) although not normally available to Solution users, falls within the scope of a Subject Access Request.
Also see NHS Digital guidance on GDPR
General Data Protection Regulation (GDPR)
General Data Protection Regulation
Suppliers to ensure that Solutions maintaining Personal Data or sensitive Personal Data adhere to General Data Protection Regulation (GDPR).
See General Data Protection Regulation guidance (NHS Digital) and ICO - Guide to the General Data Protection Regulation (GDPR) for further guidance
Synchronise Internal Clocks
The Solution to ensure that all parts of their Solution synchronise any internal time clocks to within 250 milliseconds, using the NTP protocol. This enables meaningful comparison and sorting of, for example, messages based on timestamps, and of audit entries.
Time-stamped Messaging - UTC(GMT)
All messaging to be time-stamped using UTC(GMT). Whilst applications can display local time when displaying message details, message timestamps shall contain UTC(GMT) values.
Audits Based on Synchronised Time-system
All audit entries, and other timed entries into the Record, shall be based on the synchronised time-system as described in this section. Applications will display local time when displaying audit and timed information to users.
Synchronise Internal Clocks - with HSCN Network DNS Servers
Solutions can synchronise any internal time clocks with HSCN Network DNS Servers – currently at cns0.nhs.uk & cns1.nhs.uk – using the NTP protocol. Alternatively, the Solution will utilise a Stratum 3 time source as a minimum however suppliers can consider the use of Stratum 2 or above.
Protection from Unauthorised Access - compliant Solutions
The confidentiality and integrity of Personal and sensitive Personal Data will be protected from unauthorised access and modification while stored within compliant Solutions, and in backup and archive storage.
These requirements also cover the circumstances where devices or services offered by the Supplier result in the transfer of Personal Data through electronic means or by removable media and devices. Examples of removable media and devices to which the requirements apply include but are not limited to: CD, DVD, tape, USB memory stick, removable hard drives, laptops, tablets, and mobile phones.
These requirements also cover where services offered by the Supplier result in the storage of Personal Data in inherently difficult-to-secure environments. Examples of this include servers or desktops in an Organisation such as a Practice.
Note that prior to any transfer of Personal Data taking place, full consideration will be given to the business need for the transfer, and for any opportunity to de-identify the data.
Protection from Unauthorised Access - Solution's databases and/or files
The Solution shall ensure that all Personal and sensitive Personal Data, and audit logs, are protected from unauthorised access and modification when stored within the Solution's databases and/or files. This applies wherever such data is being processed or stored.
Protection from Loss or Theft
While being processed, stored, and in backup and archive storage, all Personal Data and sensitive Personal Data and audit logs shall be physically protected from loss or theft in line with Records Management Code of Practice for Health and Social Care 2016 published by NHS Digital.
Personal Data and Sensitive Personal Data - retention policy
Personal Data and sensitive Personal Data and audit logs shall be retained in line with Records Management Code of Practice for Health and Social Care 2016 published by NHS Digital.
Data Storage - Location
The location of physical storage of Personal or Sensitive Personal Data shall abide by published Health and Social Care Cloud Security - Good Practice Guide and described in the Records Management Code of Practice for Health and Social Care 2016 or as subsequently amended.
Data - secure deletion
When no longer required to support services, all media and any infrastructure components that have stored data shall be subject to secure deletion to standards NIST Guidelines for Media Sanitization.
Limit Personal Data Transferred to Portable Media
The Supplier shall demonstrate that it has limited any Personal Data transferred to portable media to the minimum required.
Encrypt Portable Media
Where devices or services offered by the Supplier result in the transfer of any Personal Data on any portable media, such media shall be encrypted. The level of encryption used shall conform to the NIST Cryptography Standards to ensure only approved algorithms are used.
Data Transfer - encryption
Where devices or services offered by the Supplier result in the transfer of any Personal Data outside the local physical or virtual network (VLAN), including transfers across VLAN boundaries within a single local network or exporting data to removable data, encryption shall be used. The level of encryption used shall conform to the NIST Cryptography Standards to ensure only approved algorithms are used.
Audit - encryption, decryption, transport, storage and destruction of data
The encryption, decryption, transport, storage and destruction of data which is transferred shall be auditable with the media logged and tracked to ensure all instances are accounted for.
Encryption Accredited to FIPS 140-2
The Supplier shall ensure that the encryption product used is accredited to FIPS 140-2 and have received Augmented Grade Commercial Product Assurance (CPA) accreditation
Encryption Keys - strength and complexity
The supplier shall ensure that the encryption key for each archive is of an appropriate strength conforming to NIST Cryptography Standards to ensure only approved algorithms are used..
Encryption Keys - Provide to Data Controller for Encryption Operations
Where encryption keys are generated by the Solution automatically for transfer of data by portable media, the Solution shall provide the encryption key to the Data Controller for each encryption operation. In such circumstances, cryptographic keys will not be generated by the use of an algorithm or other shared secret that solely combines known or accessible environmental or other context-specific information, without the inclusion of unique, context specific secret information as provided by the user or supplier. Such encryption keys shall be generated using existing libraries. Context specific, secret information to be controlled and managed in line with key management good practice principles (i.e. with audited access controls in place).
Encryption Keys - secure storage
The Supplier shall ensure that any encryption keys generated by the Solution are stored securely to enable data recovery in the event of key loss or corruption by the Data Controller. Encryption keys to be stored separately from the data they protect.
Encryption Keys - unique per data archive
The supplier shall ensure that the encryption key for each archive is unique to that data archive.
Encryption Keys - separate communication mechanism
Where the Supplier Solution provides a mechanism for sending encryption keys to a recipient, either electronic or manually, there are processes in place to ensure that the encryption keys are sent following a separate communication mechanism to the encrypted data or posted separately from the encrypted media.
Transfer of Personal Data - Portable Media
Where a service offered by the Supplier requires the transfer of Personal Data by portable media the media shall be encrypted to the level required by and transported in a secure manner. The transfer of Personal Data shall also be conducted using Secure Courier services following NIST Cryptography Standards.
Transfer of Personal Data - Electronic Means
Where a service offered by the Supplier requires the transmission of Personal Data by electronic means, the data shall be transmitted in an encrypted form to the level required by the NIST Cryptography Standards. This encrypted data can be transmitted via a secure email service such as NHS Mail or over an approved network such as HSCN.
Protect Personal Data - un-trusted networks
The Solution shall protect the confidentiality and integrity of Personal Data in transit across un-trusted networks, including (but not limited to):
- between data centres,
- between data centres and deployment site LANs,
- between HSCN customers and remote access devices,
- between data centres and remote access devices.
Adhere to Statement of Compliance Obligations
The requirements in this section apply where a supplier provides a hosted service (outside of the Organisation premises) supporting deployments – such as a hosted application service or a shared message handling service.
Any requirement stated in this section does not absolve the supplier from adhering to NHS Digital's Statement of Compliance obligations.
Connections to Remote Servers and Applications - authenticated
The Supplier shall ensure that all connections to remote servers and applications are authenticated.
This requirement includes connections via the Internet.
Access to Diagnostic Ports - securely controlled
The Supplier shall ensure that access to diagnostic ports for network and server components is securely controlled.
Segregate Networks and Servers
The Supplier shall segregate the networks and servers that support services under these contractual arrangements from deployments relating to other, unrelated services.
ISO/IEC 27001:2013 Accreditation
A valid ISO 27001:2013 Certificate is required from a UKAS-registered accreditation organisation.
Suppliers to complete the Data Security and Protection Toolkit online self-assessment to provide assurance that they are practising good data security and that Personal Data is handled correctly.
Anti Virus and Malware
The Supplier shall ensure that Anti virus software is deployed on all appropriate endpoints and kept up to date. Where it is deemed inappropriate other protections must be in place to mitigate the risk of malware affecting the operation of the system, such as increased auditing and the use of Intrusion Detection Systems (IDS) and/or Intrusion Prevention Systems (IPS).
See Guide to Malware Incident Prevention and Handling for Desktops and Laptops for further guidance
The Supplier will ensure that applications are appropriately protected using industry standard techniques, such as controlled access to standard ports and APIs, applying Least Privilege, accepting only encrypted connections, input validation, and fail-safe defaults.
The Supplier will be aware of common specific application vulnerabilities and will ensure all appropriate mitigations are incorporated in their architecture.
The Supplier shall ensure that vendor patches are applied as soon as reasonably possible. Where a 3rd party (such as a hosting company) is responsible for patching the supplier shall ensure that they are subscribed to receive all patches in a timely manner.
See Guide to Enterprise Patch Management Technologies for further guidance