Authentication

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 (as per Authentication and authorisation section of Interoperability Standard).

may

GP-IG-2.1-3B

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.

MUST

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

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

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

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

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

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

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

Two-factor authentication for Citizens

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

may

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

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

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

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

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

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

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

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

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 NHS Digital. 

MUST

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

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

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

MUST

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

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

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

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

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

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 fitnotes can only be issued by GPs).

MUST

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

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

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)

MUST

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

MUST

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

“safe and appropriate sharing in the interests of the individual’s direct care should be the rule, not the exception”
Caldicott review: information governance in the health and care system

There are different ways in which information is commonly shared across Organisations; for example:

• Providing information to accompany, for example, routine referrals of the patient to other care settings; in such circumstances, providing information is an essential part of the process.  Solutions will support this type of scenario; requirements are defined as part of the Catalogue Solutions Requirements.

• Allowing information from within the practice to be accessible in other care settings; this might follow an explicit referral (for example, the clinician within an outpatient clinic might feel it is helpful to review parts of the patient’s general practice record that have not been included in an original referral letter) or might be as a result of a patient’s attendance at an unscheduled or urgent care setting.  

The requirements in this section are intended to recognise that:

• There is a national system for recording Patient/Service Users’ expression of their “consent-to-share” (a flag held on PDS), but this is a global setting and does not allow Patients/Service Users to specify which information they consent to share, nor in which circumstances.

• Some Patients/Service Users have previously expressed their dissent to information sharing, which is recorded using that mechanism.

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

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

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 patients is enabled, so as to allow alignment with any practice-wide information campaigns.

See Confidentiality: Good Practice in handling patient information for guidance around information handling.

MUST

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

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

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

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

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

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 IGSoC or equivalent successor

• Be subject to annual penetration testing as a minimum, or to coincide with significant Solution changes

• Continually incorporate best-practice monitoring and intrusion-detection mechanisms

MUST

Additional Privacy Controls 

GP-IG-17-1

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

MUST

GP-IG-17-2

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.

MUST

GP-IG-6-3

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.

MUST

GP-IG-6-4

Restrictions - not apply to data transfers

Restrictions applied to records will NOT interfere with their inclusion in data transfers (for example as a result of a patient changing practice, or as part of a data migration between Solutions).  It is expected that in these circumstances, as described in published guidance, any locally-applied restrictions will be removed.