Introduction

Citizen Services allow a Patient (or in some instances a person acting as a Proxy for a Patient) to access Solutions that allow them to perform certain actions online (e.g. via an internet web browser or an App on a Phone). As a minimum, this includes:

• Managing GP Appointments

• Ordering Repeat Prescriptions

• Viewing their Electronic Patient Record (EPR)

The services that are available to a Citizen are configured by their registered GP Practice using their Core Clinical Solution.

Citizen Capabilities

To support these Citizen Services, a number of Citizen Capabilities exist which Suppliers can choose to build Solutions to meet:

• Appointments Management - Citizen

• Prescription Ordering - Citizen

• View Record - Citizen

Suppliers can choose to build Solutions that meet one or many of these Citizen Capabilities.

Requirements relating to enabling and disabling these Citizen Services at a Patient and Practice level are mandated in the Patient Information Maintenance - GP Capability.

Scenarios

There are two main scenarios in terms of Citizen Services implementation:

1. The Core Clinical Solution is the same as the Citizen Service Solution

2. The Core Clinical Foundation Solution is different to the Citizen Services Solution

Where the Citizen Capabilities are being provided by the same Solution as the Core Clinical Solution (Scenario 1), the Supplier is free to determine how access to the appropriate Citizen Services is established for Patients providing they meet all MUST requirements within the Capabilities and Standards. They will still be required to support other Solutions integrating with their Core Clinical Solution as per Scenario 2 above.

Since the Citizen Capabilities can be provided by Solutions that are different to a Core Clinical Solution (Scenario 2), Suppliers of Core Clinical Solutions need to provide the ability for these Citizen Solutions to be integrated with the Core Clinical Solution. There are currently two ways to achieve this integration:

1. GP Connect (Patient Facing APIs) (latest approach)

   1. GP Connect (Patient Facing) User Permissions Standard

   2. GP Connect (Patient Facing) Prescriptions Standard

   3. GP Connect (Patient Facing) Access Record Standard

2. IM1 - Interface Mechanism Standard (legacy approach)

The diagram below illustrates the likely relationships between the Capabilities which make up the Citizen Services and the Core Clinical Solution Capabilities where different Solutions are integrated:

Open

Structure and Lifecycle of Citizen Online Accounts

This section is essential reading for Suppliers as it articulates the different types of account a Citizen can have, how they differ and the processes involved in their maintenance. It is primarily focused on the Scenario 2 where two different Solutions need to be integrated to provide access to Citizen Services for a Patient.

Account Types

Depending on the implementation scenario, as a minimum a Citizen is likely to need up to two accounts as outlined in the table below.

Where the Citizen Capabilities are being provided by the same Solution as the Core Clinical Solution (Scenario 1), it is possible only the VUA account will be required.

Account Structure and Relationships

The following describes a typical approach to account structure and relationships between accounts.

• A Verified User Account (VUA) consists of a Suppliers' internal ID for the Patient at a specific Practice and Account Linkage Key

  • Where the Citizen Capabilities are being provided by the same Solution as the Core Clinical Solution (Scenario 1), the VUA may be the only account required and may also hold a Username and Password to be used by the Citizen to access Citizen Services

• An Online Service Account (OSA) consists of only a Username and Password, which may be different to the credentials of both the VUA and any other OSA held by the Citizen.

Account Linkage (IM1 - Interface Mechanism only)

Where the Core Clinical Solution is different to the Citizen Services Solution (Scenario 2), in order for a Citizen to gain access to Citizen Services a connection will need to be established between an Online Service Account (OSA) and a Verified User Account (VUA) in the Patient Information Maintenance - GP Solution.

Citizen Services Solutions will allow the Citizen to enter VUA Credentials and Demographics and confirm, in conjunction with the Patient Information Maintenance - GP Solution, that information provided is a successful match. Where Account Linkage is successful, the Citizen will be informed of the successful linkage.

Once an Online Service Account has been linked to a VUA this then the Citizen can access the relevant Citizen Services as configured by their Practice.

See NHS login service for more information on Account Linkage and the associated requirements.

IM1 - Interface Mechanism

Open

GP Connect (Patient Facing APIs)

Open

 

Example Processes

Scenario 1: Citizen Services Process - Single Solution

Open

Scenario 2: Citizen Services Process - Integrated Solutions (IM1 - Interface Mechanism)

Open

Scenario 3: Citizen Services Process - Integrated Solutions (GP Connect (Patient Facing APIs))

Open

Online Accounts and Proxy Service Access

In some circumstances Citizens can be granted access to Citizen Services on behalf of another Citizen (i.e. as their Proxy). For example, as a parent booking Appointments for a Child. Citizen Services account structures that are created to support this can vary depending on the location of the records involved and also the Suppliers' Solution architecture:

Further Guidance

This section provides supporting information relevant to the different functionality required to support Citizen Services.

Verified User Account (VUA) Management

As described above, a Verified User Account (VUA) is the Practice based account for a Citizen who can be a registered Patient or a person acting as a Proxy for a Patient. It is created by the Patient Information Maintenance - GP Solution which holds the Patient Record.

A Patient or Proxy should have a maximum of one VUA per GP Practice, however as covered by the scenarios in the Online Accounts and Proxy Service Access section above, a Supplier may choose to design a Solution where a single VUA is created for an individual for use and management by any Practice that uses their Solution to avoid duplication.

Typically the following data would be recorded in relation to a VUA:

• VUA ID* - A unique identifier per Practice (and/or per Solution)

• VUA Demographics

  • Title

  • Forename(s)

  • Family Name

  • Date of Birth

  • Contact Details - Postal Address, Telephone Number and Email Address

• VUA Linkage Key* - IM1 - Interface Mechanism only

• ODS Code* - of the GP Practice creating the VUA

• VUA Status - Live or Inactive

• VUA-Patient Association - association with one or more Patient Records

• VUA Identity Verification Record

Data items marked with * will typically be Solution-generated and non-editable.

VUA details display

It’s recommended the following VUA details and historic information are able to be displayed to a User in the Patient Information Maintenance - GP Solution:

• VUA Demographics

• Preferences

• Service Access (including date and time of changes)

• Identity Verification

• VUA Creation Date & Time

• Patient Association 

• Registration for Services (including date and time)

• Current and historic Account Linkages

VUA Linkage Key (IM1 - Interface Mechanism only)

VUA Linkage Key creation and retrieval is required to be implemented as per the NHS login service Standard to Support linking VUAs to OSAs when integrating via IM1 - Interface Mechanism.

Each VUA Linkage Key will be:

• As per Authority defined requirements within Information Governance, including being supportive of complexity management and enforcing suitable strength and character restrictions

• Re-usable i.e. the same VUA Linkage Key for each/all Services accessed

VUA Status

VUAs should be able to have the following statuses as a minimum to support the different stages of the VUA lifecycle:

• Inactive – default state upon VUA Creation.

  • VUA could revert to Inactive:

    • Automatically if no active VUA-Patient Associations exist e.g. if the Patient leaves the Practice and is not a Proxy for anybody else at that Practice

    • Automatically if Account Linkage is removed/reset e.g. in the instance of unusual activity or compromised Credentials.

    • Manually when changed by a User

• Active – to only become Active when the following is completed:

  • Completion of Account Linkage 

  • Identity Verification

  • VUA-Patient Association with at least one Patient Record

VUA-Patient Association

In order for a Citizen to access online services for a Patient, their VUA will need to be associated with at least one Patient Record within a Patient Information Maintenance - GP Solution.

Typically the following data would be recorded in relation to each VUA-Patient Association:

• Type of Association

  • Self (where the Citizen and the Patient are the same individual - zero or one such Self Association is permitted)

  • Proxy (where the Citizen and the Patient are different individuals - zero, one or many such Proxy Associations are permitted)

• Assurance of the Relationship - i.e. Legal Basis for the association and Online Service access, including:

  • Type of Relationship - e.g. Self, Mother, Father, Son, Daughter, Friend or Carer

  • Explicit consent of the Patient - recording consent has been obtained and method of Consent (i.e. Written or Verbal)

  • Free-text details - for further supporting information

• Services Registered - which Online Services are approved for this association

• Start Date

• End Date

See DAPB3051 (previously DCB3051): Identity Verification and Authentication Standard for Digital Health and Care Services - NHS England Digital for information on Proxy access.

Identity Verification

Identity Verification functionality is provided by the Patient Information Maintenance - GP Solution and is intended to support local Practice Policy on recording Identity Verification for Patients in relation to Citizen Services.

The functionality will need to be sufficient to support DAPB3051 (previously DCB3051): Identity Verification and Authentication Standard for Digital Health and Care Services - NHS England Digital and could be configurable.

Typically the following data would be recorded in relation to Identity Verification:

• Date - of the ID verification

• Health or Care Professional - who verified the identity

• Type of Verification

  • Vouching

    • Personal

    • Information confirmation - e.g. knowledge of details on their medical record

    • Vouched for by - Staff Member responsible for vouching

  • Identity Documentation - will need to be excluded form GP2GP transfers

    • Type of Document, including

      • Passport

        • Birth Certificate

        • Marriage Certificate

        • Other

• Attached evidence - e.g. copy of or link to an image of the identity document

Online Service Account (OSA)

As described above, an Online Service Account is an account held by the Citizen Services Solution to enable access to Citizen Services where this is a separate Solution to the Foundation Solution.

Where required, a Citizen Service Solution would typically allow a Citizen to:

• Create a unique Online Service Account

• Create/obtain account Credentials e.g. utilising NHS Login, by creating a Username & Password, by integrating a web Single Sign On (SSO) service or by associating a device identifier (such as Mobile Phone Identity IMEI - International Mobile Equipment Identity number)

• Set up security questions for use when account Credentials have been forgotten

All account Credentials to be created/assigned as per Authentication requirements.

Appointments Management - Citizen

Functionality allowing Citizens to manage Appointments online either for themselves or on behalf of someone else (as a Proxy) will be provided by the Appointments Management - Citizen Solution.

This functionality will allow Citizens to book appointments based on availability defined by the Appointments Management - GP Solution (adhering to any additional rules and restrictions defined) through the provision and consumption of Patient interfaces as per the IM1 - Interface Mechanism Standard.

View Record - Citizen

Functionality allowing Citizens to access Patient Record information either for themselves or on behalf of someone else (as a Proxy) will be provided by the View Record - Citizen Solution.

This functionality will allow Citizens to access different levels of information from the relevant Patient Record as defined by the Service Configuration functionality within the Patient Information Maintenance - GP Solution and through the provision and consumption of Patient interfaces as per the IM1 - Interface Mechanism Standard or GP Connect (Patient Facing) Access Record Standard.

It is recommended that Citizens have the ability to:

• Be informed upon every access that they might not be accessing the full information held using the following statement “This is a limited view of the Patient Record and may not include any free text. Information that is considered to be sensitive or that existed before the creation of this service may not be available for viewing online.”

• View relevant elements of the Patient’s Record logically grouped as appropriate, including:

  • The clinical term description i.e. not the code

  • Associated free text

  • Date and Time of the event

  • Source/Provenance (Organisation/System, User/Role, Name)

• Sort the Patient’s Record by relevant elements, including:

  • Event Date

  • Type

  • Problem (where available)

  • Source/Provenance (Organisation/System, User/Role, Name)

View Record - Access Levels

The different levels of Patient Record access are:

Summary Information Record

When enabled for a Patient, the Summary Information dataset (and *only* that data) will be made available irrespective of any agreement with the Patient regarding their actual Summary Care Record (i.e. if certain information for the Patient is excluded from their Summary Care Record, this information will not automatically be excluded from the Summary Information Record and vice versa). 

The Summary Information Record dataset is defined here.

Detailed Coded Record

Detailed Coded Record Access builds on the data already made available through the Summary Information Record dataset and additionally includes all data held as coded data (See Data Standards for definition of coded data and associated requirements) within the Patient Record, excluding associated free text.

The Detailed Coded Record dataset is defined here.

Since this builds upon the data provided to the Citizen via the Summary Information Record, the Detailed Coded Record cannot be enabled without the Summary Information Record also being enabled.

View Documents

View Documents builds on the data already made available through the Summary Information Record and Detailed Coded Record datasets, but also includes the ability for Citizens to be able to view all clinical and administrative documents (inc. Pathology and Radiology test results) made available by the GP Practice.

The Documents dataset is defined here.

Citizens will not be able to view any clinical or administrative documents until they have been reviewed by the GP Practice. Typically this would mean the documents are marked as ‘Restricted from View Record’ until a review has taken place and the document deemed appropriate to be displayed online to the Citizen.

View Full Record

View Full Record builds on the data already made available through the previous levels and the Full Patient Record dataset is defined here.

Individual Elements of Patient Record - ‘Restricted from View Record’

In addition to the different levels of access to the Patient Record, individual elements of the Patient Record can also be marked as ‘Restricted from View Record’ allowing specific elements of the Patient Record to be hidden from Citizens when viewing the Patient Record information online.

All/any elements of a Patient Record marked as 'Restricted from View Record' will not be displayed by the View Record - Citizen Solution to the Patient irrespective of Record Access Level configuration.

For example, where Service Configuration determines Detailed Coded Record enabled with a Start Date of 1st February 2013 but a Clinician has reviewed a Patient’s Record back to 1st January 2010, any elements of the Patient Record not marked as ‘Restricted from View Record’ as part of the Record review/preparation (between January 2010 and February 2013) to display in addition to those displaying due to the Detailed Coded Record configuration.

Prescription Ordering - Citizen

Functionality allowing Citizens to manage requests for Repeat medication and EPS Nominated Pharmacy preferences online either for themselves or on behalf of someone else (as a Proxy) will be provided by the Prescription Ordering - Citizen Solution. This functionality may also allow Citizens to manage requests for Acute medication, Preferred Pharmacy preferences and view additional medication information (e.g. how to use it and the implications of doing so).

Any submitted medication requests or Pharmacy preference changes will be received and managed by the Prescribing Solution through the provision and consumption of Patient interfaces as per the IM1 - Interface Mechanism Standard or GP Connect (Patient Facing) Prescriptions Standard.

Enabling/Disabling Citizen Services

The enabling and disabling of the above Citizen Services at both a Patient and Practice level will be configured by the GP Practice using the Patient Information Maintenance - GP Solution. It is recommended that the ability for Health or Care Professionals to record a reason when disabling Citizen Services is provided by this Solution.