Authentication

All

GP-IG-2.1-3A    

Authentication - Access using NHS authentication

Any access to Personal or Special Category Data within Solutions to be subject to NHS authentication (as per Authentication and authorisation section of Interoperability Standard).

may

All

GP-IG-2.1-3B

Authentication - General standards

Any access to Personal or Special Category Data within Solutions will be subject to authentication at least to standards described in GP-IG-2.2-1.

MUST

All

GP-IG-2.1-4

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.

MUST

All

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.

MUST

All

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.

SHOULD

All

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.

MUST

All

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.

MUST

All

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.

may

All

GP-IG-2.2-9

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.

may

All

GP-IG-2.2-9A

Two-factor authentication for Citizens

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

may

All

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.

MUST

All

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.

MUST

All

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.

MUST

All

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.

MUST

All

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.

MUST

All

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.

MUST

All

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.

MUST

Role-based Access Control

All

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.

For NHS authentication requirements see Authentication and authorisation section of Interoperability Standard.

MUST

All

GP-IG-3-7

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 the Authority.

MUST

All

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

MUST

All

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.

MUST

All

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

MUST

All

GP-IG-3-12B

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 Organisation Data Service (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

MUST

All

GP-IG-3-13

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.

MUST

All

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.

MUST

All

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.

MUST

All

GP-IG-3-18

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.

may

All

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 (for example where fit notes can only be issued by GPs).

MUST

All

GP-03.4-05

Non-RBAC role details

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

• Start date

• End date

• Status (active, inactive)

MUST

All

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

MUST

Legitimate Relationships

All

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 Notifications), detailing all Patient/Service User records affected

• 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 Notifications), detailing all Patient/Service User records affected

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

MUST

All

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

MUST

All

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.

MUST

Information Sharing across Organisations for Direct Care

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 (Personal Demographics Service)), 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

All

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.

MUST

All

GP-IG-5-2

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.

MUST

All

GP-IG-5-3

Practice controlled information sharing

The Practice is to have control as to whether information sharing (access to information from other care settings) for any Patient is enabled, so as to align with Confidentiality: Good Practice in handling Patient information.

MUST

All

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.

MUST

All

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, other than the exception condition described in requirement GP-IG-5-6A.

SHOULD

All

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.

MUST

All

GP-IG-5-6B

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.

MUST

All

GP-IG-5-6C

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?”

MUST

Additional Privacy Controls 

All

GP-IG-17-1

Access to whole Records

It will be possible to:

• Restrict access to a Patient/Service User’s entire record (use case is Practice staff member)

• Apply such restrictions at the level of RBAC user roles and to custom groups of Staff Members

MUST

All

GP-IG-17-2

Access to individual parts of records

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

• To automatically apply restrictions (they will be as a result of an explicit, audited, action by an authorised user)

• For any restrictions to interfere with any data transfers (any such restrictions, if applied locally should be removed)

MUST

Workstation Access Controls

All

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.

MUST

All

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.

MUST

Data Labelling

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.

All

GP-IG-9-1

Data Labelling - hard-copy output

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

SHOULD

All

GP-IG-9-2

Data Labelling 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:

1. By being shown on any screen displaying the information; or

2. By being displayed to the User upon logging into the Solution (for example as part of an acceptable use policy).

Where option 1 above is chosen, the protective labelling of information to be shown in a consistent location and manner on any screen displaying the information.

may

All

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.

may

All

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

may

Provenance

All

GP-IG-10-1

Record provenance details for all Personal and Special Category Data

The Solution will record the following provenance details of all Personal and Special Category 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

The Solution will also make access to this 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).

MUST

All

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

• The provenance of any information entered locally as a result of the incoming document

• The linkage between the locally-entered information and the incoming document

MUST

All

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.

MUST

Data Suppression & Removal

All

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

MUST

All

GP-IG-11-2B

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 Quality Outcomes Framework (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.

may

All

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 Quality Outcomes Framework (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)

• A Notification – as described in Notifications 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 Notification 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)

MUST

All

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

MUST

Name

ID

Level

Typically initiated by

Actioned by

Reversible?

Visible marker of use?

Example/use case

Logical deletion

GP-IG-11-3

MUST

User (during data entry)

User or Patient for previously-committed data

User

Yes, by back-office

Yes, for previously-committed data

i) Clinician discovered error during data entry

ii) Patient wishes damaging information to be hidden from all future users; Clinician agrees that this will not impact future case

Physical deletion

GP-IG-11-4

MUST

Patient

Back-office

No

No

Patient wishes damaging information to be hidden from all future users; court so orders.

Audit

All

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 GDPR, to enable fulfilment of requests from Patients/Service Users as to who has accessed or modified their Special Category 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.

MUST

All

GP-IG-12-2B

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.

MUST

All

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.

MUST

All

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.

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

MUST

All

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.

MUST

All

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.

MUST

All

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.

MUST

All

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.

MUST

All

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.

MUST

All

GP-IG-12-10

Audit retention

The Audit Trail can be moved to archive storage as required for efficient Solution operation. This shall be retained in accordance with the audit retention policy; as specified in Records Management Code of Practice for Health and Social Care 2016 (or later) 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).

MUST

All

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

MUST

All

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.

MUST

All

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.

MUST

All

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

MUST

Notifications

All

GP-IG-13-1

Inform user notification will be generated

There are a number of requirements elsewhere in this document (which reference this Notifications section) where it is appropriate for specific actions to be permitted, but a notification 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 a notification will be raised, and is provided with the ability to enter a reason for their action.

MUST

All

GP-IG-13-2A

Notification content

In such circumstances, a notification 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 notification was raised (including Patient/Service User identification)

• Reason entered by the user

MUST

All

GP-IG-13-2B

Notification mechanism

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

may

All

GP-IG-13-3

Levels of notifications

The mechanism shall support at least two levels: 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).

MUST

All

GP-IG-13-4

Privacy Officer requirements

The Solution will allow the designated Privacy Officer to:

• Receive each notification 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

• View all notifications/alerts

• Record the actions carried out associated with each notification/alert and to change the status (e.g. new, in-progress, completed)

• Filter and/or organise the view of notifications/alerts according to (either individually, or in combination):

  • Level

  • Date/time

  • User involved

  • Patient/Service User involved

  • Status

MUST

All

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.

Please see Privacy Officer guidance.

MUST

Data Subject Access Requests

All

GP-IG-15.8

Support Response to Subject Access Requests

The Supplier shall ensure that the Solution supports responding to Data Subject Access Requests (e.g. by providing the required data) in accordance with the ICO GDPR guidance regarding a data subject’s right to access.

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 Data Subject Access Request.

See right to rectification / erasure guidance.

MUST

General Data Protection Regulation (GDPR)

All

GP-IG-16-1

General Data Protection Regulation (GDPR)

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

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

MUST

Information Security 

All

GP-IG-14.1-1

Synchronise Internal Clocks

The Supplier to ensure that all parts of their Solution synchronise any internal time clocks to within 250 milliseconds, using the Network Time Protocol (NTP). This enables meaningful comparison and sorting of, for example, messages based on timestamps, and of audit entries.

MUST

All

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.

MUST

All

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.

MUST

All

GP-IG-14.2-2

Protection from Unauthorised Access - Solution's databases and/or files

The Solution shall ensure that all Personal and Special Category 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.

MUST

All

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 2016 (or later).

MUST

All

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 2016 (or later).

MUST

All

GP-IG-14.2-5

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 later) or as subsequently amended.

MUST

All

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.

MUST

All

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.

MUST

All

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.

MUST

All

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, including transfers across network 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.

MUST

All

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 physically transferred shall be auditable with the media logged and tracked to ensure all instances are accounted for.

MUST

All

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.

MUST

All

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.

MUST

All

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

MUST

All

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 are to be stored separately from the data they protect.

MUST

All

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.

MUST

All

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.

MUST

All

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.

MUST

All

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.

MUST

All

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

• Over the public internet

MUST

All

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 the Authority's Statement of Compliance obligations.

MUST

All

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.

MUST

All

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.

MUST

All

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.

MUST

All

GP-IG-16-2

ISO/IEC 27001 Accreditation

A valid ISO 27001 Certificate is required from a UKAS-registered accreditation organisation, or IAF registered accreditation organisation in exceptional circumstances.

SHOULD

All

GP-IG-18-1

DSP Toolkit

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.

MUST

• Tech Innovation

• DFOCVC

GP-IG-18-8

National Data Guardian Security Standards

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

MUST

All

GP-IG-18-2

Antivirus and Malware

The Supplier shall ensure that Anti-malware 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.

MUST

All

GP-IG-18-3

Application Security

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.

MUST

All

GP-IG-18-4

Patch Management

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.

MUST

All

GP-IG-18-9

Penetration Testing

Penetration testing will be completed by a 3rd party CHECK / CREST accredited organisation before go-live and annually thereafter.

An action plan must be in place to mitigate any vulnerabilities identified in an appropriate timeframe.

MUST