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