GP-IG-2.1-3A          

Authentication - Access using NHS authentication

Any access to Personal Data or sensitive Personal Data within Solutions to be subject to NHS authentication.

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.

GP-IG-2.1-4          

Authentication - NHS authentication with no additional authentication 

Solutions shall ensure that, where NHS authentication is used, those users are able to carry out all Solution activities (subject to their access rights) without the need for any additional authentication.

GP-IG-2.1-10

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.

GP-IG-2.1-12       

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:

Access to this computer/Solution and any information it contains is limited to authorised users only. Legal action can be taken against unauthorised use of, or unauthorised access to, this computer/Solution and/or any information it contains, including pursuant to the Computer Misuse Act 1990. If you are an authorised user, by proceeding to access and use this computer/Solution and/or the information it contains, you are accepting any terms of use, notices and policies which are contained or referenced within it or which have otherwise been drawn to your attention as an authorised user.

Note that this wording can be updated from time-to-time.

GP-IG-2.1-13       

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.

GP-IG-2.1-14       

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.

GP-IG-2.2-1          

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, unless otherwise specified by the Authority.

Two-factor authentication

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, unless otherwise specified by the Authority.

Two-factor authentication for Citizens

Two-factor authentication will be used for Citizens to log into Solutions.

GP-IG-2.2-2          

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.

GP-IG-2.2-3          

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.

GP-IG-2.2-4          

Password storage

Where passwords are stored in Solution databases, they will be stored salted and hashed, using algorithms and strengths recommended in NIST Cryptography Standards.

GP-IG-2.2-5          

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)

Unsuccessful login:

• Number of attempts
• Date and time
• Access point (if available)
• User id (if available)

Password changes:

• User id
• User whose password was changed
• Date and time

Such Audit Trail entries to also include end-user device (or Solution) identification information.

GP-IG-2.2-6          

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.

GP-IG-2.2-7          

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.

GP-IG-2.2-8          

Password reset

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.

GP-IG-3-2              

Role-based access control

The Solution will have role-based access control to authorise users’ access to the Solution functions and data.

GP-IG-3-7              

Updates to Job Role to Baseline Activities

Unless otherwise specified, the Solution will have a process for incorporating updates to the nationally-defined mapping from Job Role to Baseline Activities as published by the Authority.

GP-IG-3-8              

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. Unless otherwise specified, 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

GP-IG-3-9              

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.

GP-IG-3-12A           

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

GP-IG-3-16           

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.

GP-IG-3-17           

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 (DSCR)

The Solution will support roles (e.g. Care Worker) 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.

GP-IG-3-19           

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.

GP-IG-03.4-05

Non-RBAC role details

Support definition of the following detail for non-RBAC roles:

• Start date
• End date
• Status (active, inactive)

GP-IG-16-3

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).

GP-IG-4-3

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)

GP-IG-4-4

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).

GP-IG-4-5 

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.

GP-IG-5-1

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.

GP-IG-5-2

Organisational change - Patient/Service User preferences carried forward

Organisational structures change over time, for example as organisations 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.

GP-IG-5-4

Respect recorded preferences

The Solution will respect any such recorded preferences, having effect on the sharing of information that might otherwise be technically possible.

GP-IG-5-5

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.

GP-IG-5-7

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 the DSP Toolkit
• 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

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.

Audit restrictions

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/Service User changing Care Home, 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.

GP-IG-7-2              

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.

GP-IG-7-3              

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.

GP-IG-9-1              

Labelled Personal Confidential data hard-copy output

All Personal Data which are output to hard-copy by the Solution will be labelled "Official – Sensitive". 

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.

GP-IG-9-2              

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)

GP-IG-9-3              

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.

GP-IG-9-4              

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.

GP-IG-9-5              

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).

GP-IG-10-1           

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

GP-IG-10-2           

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

GP-IG-10-3           

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).

GP-IG-10-4           

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.

GP-IG-11-1 

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).

Withdrawal reason

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.

GP-IG-11-3  

Logical deletion

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)

GP-IG-11-4 

Physical deletion

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:

GP-IG-12-1

Audit trails

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 Quality Commission Regulation:17 Good governance, 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.

GP-IG-12-3 

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.

GP-IG-12-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 Quality Commission Regulation:17 Good governance.

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).

GP-IG-12-5 

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 identity 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.

GP-IG-12-6

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.

GP-IG-12-7

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.

GP-IG-12-8

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.

GP-IG-12-9

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.

GP-IG-12-10

Audit retention

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 2021 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).

GP-IG-12-11

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.

GP-IG-12-13

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.

GP-IG-12-14

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.

GP-IG-17-3

Timestamp format

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).

GP-IG-13-1

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.

GP-IG-13-2A

Alert content

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)
• User
• Context of the Solution at the time the alert was raised (including Patient/Service User identification)
• Reason entered by the user

Alerting mechanism

The alerting mechanism can use the mechanism within the Solution as defined in Workflow Capability.

GP-IG-13-3

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).

GP-IG-13-4

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.

GP-IG-13-5A

View alerts

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).

Filter/organise alerts

The Solution will allow the designated Privacy Officer to filter and/or organise the view of alerts according to (either individually, or in combination):

• Level
• Date/time
• User involved
• Patient/Service User involved
• Status

GP-IG-13-6

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.

GP-IG-15.8            

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 although not normally available to Solution users, falls within the scope of a Subject Access Request.

Also see NHS guidance on GDPR.

General Data Protection Regulation

Suppliers to ensure that Solutions processing (including storage of) Personal Data or sensitive Personal Data adhere to General Data Protection Regulation (GDPR).

See NHS guidance on GDPR and ICO - Guide to the General Data Protection Regulation (GDPR) for further guidance.

GP-IG-14.1-1       

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.

GP-IG-14.1-2       

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.

GP-IG-14.1-3       

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 - NTP Synchronisation Requirements

All organisations connected to HSCN, or who deal with Health or Social Care services within the UK, should ensure they configure a time synchronisation service with at least four diverse sources, of stratum three or better. See NHS Network Time Protocol guidance for further detail.

GP-IG-14.2-1       

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 Care Home.

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.

GP-IG-14.2-2       

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.

GP-IG-14.2-3       

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 2021 published by the NHS.

GP-IG-14.2-4       

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 2021 published by the NHS.

GP-IG-14.2-5       

Data Storage - Location

The location of physical storage of Personal or Sensitive Personal Data shall abide by published Cloud security – good practice guide - NHS and described in the Records Management Code of Practice for Health and Social Care 2021 or as subsequently amended.

GP-IG-14.2-7       

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 described in NIST Guidelines for Media Sanitization.

GP-IG-14.3-1       

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.

GP-IG-18-5       

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.

GP-IG-18-6       

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.

GP-IG-14.3-4       

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.

GP-IG-14.3-5       

Encryption Accredited to FIPS 140-2

The Supplier shall ensure that the encryption product used is accredited to FIPS 140-2.

GP-IG-18-7       

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.

GP-IG-14.3-7       

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).

GP-IG-14.3-8       

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.

GP-IG-14.3-9       

Encryption Keys - unique per data archive

The Supplier shall ensure that the encryption key for each archive is unique to that data archive.

GP-IG-14.3-10     

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.

GP-IG-14.3-11     

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 the NIST Cryptography Standards and transported in a secure manner. The transfer of Personal Data shall also be conducted using Secure Courier services following NIST Cryptography Standards.

GP-IG-14.3-12     

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.

GP-IG-14.3-13     

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

GP-IG-14.4-1       

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 Statement of Compliance obligations.

GP-IG-14.4-2       

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.

GP-IG-14.4-3       

Access to Diagnostic Ports - securely controlled

The Supplier shall ensure that access to diagnostic ports for network and server components is securely controlled.

GP-IG-14.4-4       

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.

DSP Toolkit (DSCR)

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.

The Data Security and Protection Toolkit online self-assessment must be completed and published at a level that is appropriate to the Authorities and Digital Social Care requirements (e.g., GP Connect requires that the Data Security and Protection Toolkit is published as, 'Standards Met').

National Data Guardian Security Standards

The Supplier shall ensure they comply with the National Data Guardian's Data 10 Security Standards.

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.

Application Security (DSCR)

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.' Guidance on this can be found within the Data Security and Protection Toolkit.

Patch Management

The Supplier shall ensure that vendor patches are applied as soon as reasonably possible. Where a 3^rd 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.