Patient Registration

Support Patient registration at a General Practice for all Medical Services

Anchor
GP-04.1-02 GP-04.1-02

GP-04.1-02

Patient Registration Types

Categorise Patients using Registration Types in line with legislative registration statuses as defined in NHS England Standard General Medical Services Contract (see definition of 'Patient' in Part 1)

Additionally, provide the ability to categorise Private patients using a specific Registration Type.

Patient Registration Personal Data

Enforce the following Minimum Data Set at point of Patient registration (prior to clinical data being recorded)

• Family Name
• Forename
• Date of birth
• Sex
• Registration Type (in line with legislative registration statuses):
  • Fully Registered
  • Temporary Resident
  • Immediately necessary treatment
  • Private
  • Other
• Registration start date
• Registration status (active/inactive)
• Communication needs for the Patient

See PDS for demographic data format.

For contractual references between GPs and NHSE see: NHS England Standard General Medical Services Contract

Patient's GP

Record:

• a Usual GP
• a Named Accountable GP
• an Individual GP for Specific Services (e.g. Child Health Surveillance services) - only applicable for Patient Registration Types of Other and Private (see Patient Information Maintenance - Standard)

Registration End Date

Record an end date for each Registration Type.

If the Registration type is Fully Registered and the Patient has been Deducted the Registration end date must equal the Deduction date.

Patient Verification

Support Patient verification during the registration process with comprehensive tracing functionality.

See PDS for details on PDS Advanced Trace functionality

Patient Registration Status

Automatically update a Patient’s Registration Status if/when registration start date, registration end date (or date of Deduction) is completed:

• Active
• Inactive

See GP2GP documentation for details of Patient registration and GP2GP trigger conditions

Re-activate Inactive Patient

Reactivate an Inactive Patient Record when a Patient re-registers with a General Practice (e.g. prisoner released) i.e. another instance of a Registration Type can be created for the Patient, but the original end date will not simply be deleted.

See GP2GP documentation for specific Electronic Patient Record transfer requirements on returning Patients

PIM8

Record and Maintain Demographic Information

Record and maintain the following national Demographic Information for all registered Patients:

• Patient’s Responsible GP
• Patient’s Responsible HA (hospital authority)
• Patient’s GP Practice
• NHS Number
• Family Name
• Former Family Name
• First Given Name
• Other Given Names
• Preferred Name
• Alias/Also Known As
• Title
• Sex
• Date of birth
• Address
• Post Code
• At least one previous home address
• At least one telephone contact
• At least two other contact types (e.g. email, work tel number)
• Preferred language (spoken)
• Place of Birth
• Drugs Dispensed Marker
• RPP Mileage
• BR/SD marker
• Walking Units
• RI code

Requirements for the format of these data fields can be found in the relevant NHAIS and PDS documentation – if they differ, Solutions will adhere to both formats when synchronising and transferring data between Solutions (e.g. NHAIS Requirements for address format are more prescriptive than those for the address format for PDS)

See Patient Information Maintenance - Standard for notifications around demographic and preference changes

GP-04.2-02

Record and Maintain Additional Demographic Information

Record and maintain the following additional Demographic Information for all registered Patients:

• Marital status
• Religion
• Ethnic Category
• Interpreter required
• Transport needs
• Advocacy needs
• A previous NHS number (including old style NHS numbers)
• Usual GP
• The location normally attended
• Address access notes (information about how to access a Patient’s home e.g. door code values or ‘use back door’ – not to be included within standard address details or synchronised with National Systems)
• A telephone number with its category e.g. Mobile
• Email address
• Whether the Patient is cared for / has a Carer
• Whether the Patient is also a Carer for another individual(s) irrespective of whether those individuals are registered Patients with the General Practice

Record and Maintain Preference Details

Record and maintain the following Preference details for each registered Patient, each data item in its own explicit field(s) with values determined from standard lists wherever possible:

• Gender  
  • Allow the gender and sex to be recorded as different data items with potentially different content
• Preferred written language
• Preferred spoken language

Default will always be implied dissent and for each Preference default to be ‘not yet set’ – any changes will be on an individual Patient basis

See Patient Information Maintenance - Standard for notifications around demographic and preference changes

Patient Alerts

Add, update and remove Patient Alerts manually or automatically (e.g. rules based), to indicate key characteristics to Practice Users (e.g. that the patient is violent or is on a certain chronic disease register).

Anchor
GP-04.4-01 GP-04.4-01

GP-04.4-01

Record and Maintain Related Persons

Record and maintain the following related persons for all registered Patients, each data item in its own explicit field(s) with values determined from standard lists wherever possible.

A Patient can have multiple related persons, a person can be related to multiple Patients and an individual can be a related person of multiple types to a single Patient:

• Related person type - examples include:
  • Carer
  • Next of Kin
  • Cared for Individual / Caree
  • Psychiatric nurse
  • Patient's social worker
• Relationship to Patient
• Family Name
• Given Name(s) / Forename(s)
• Title
• Sex
• Organisation name (to support situations where Patient is in the care of a home rather than a specific individual working at the home)
• Address
• At least one telephone number (and associated category e.g. Mobile)
• Email address
• Source of a related person’s information (who has given information regarding the relationship) e.g. Patient, Carer, other Health Provider Organisation 
• Notes about the relationship – free text

Where the related person is also registered at the Practice, this related person record can be derived from / linked to their Patient Record

GP-05.1-01

Search, identify and retrieve a Patient Record

Search for, identify and retrieve a Patient Record for use in the Solution by searching full or part of the contents of any combination of the following fields:

• Family name
• Given name / Forename (including first or other names)
• Preferred name/Alias/Also known As
• Date of birth
• NHS Number
• Address
• Postcode
• Telephone number
• Registration Type
• Local Patient identifier

GP-05.1-02

Find Record with Demographic Changes

Ability for Practice User to explicitly select to include historic Demographic Information in a search

GP-05.1-03

Notification of Patient Record Actions

Indicate to the Practice User:

At any point a Patient interacts with the Practice / when accessing a Patient’s record:

• About the incompleteness of a registration record
• Where contact details have a status indicating that they require re-verification e.g. where mail has been returned or emails bounced back
• If a task is outstanding for that Patient
• Of any outstanding Referrals
• Of any documents with a status indicating that they are not Filed and/or document properties (header file / document metadata) have not been recorded, or documents recorded as Provisionally Filed (including via/within a Citizen Service)

Irrespective of the solution where a Practice User is Notified / Informed of any of the above, a Practice User is to have the option to directly access the relevant area of the Solution or specific information to enable rectification

GP-05.1-04

Access Patient Record with Matched Item

Access a Patient Record from any area or module within the Solution where a Patient has been successfully matched or linked to the item/area e.g. when viewing a document or managing a task, a Practice User can directly open/launch the associated Patient Record

GP-05.2-01

View Events and Future Activities

View all historic events and future activities planned within a journal or Patient activity log, including:

• Consultations / Encounters
• Medication
• Characteristics and Interventions
• Documents
• Tasks
• Allergies

PIM17

Problem-orientated records

Support a problem-orientated approach to recording and viewing data, including:

• Ability to define Problems (using appropriate coding as per Data Standards)
• Ability to maintain Problem lists

See Good Practice Guidelines for GP electronic patient records Version 4 (2011) for guidance

GP-05.2-02

Access Data Items

Identify and access related data items and documents irrespective of:

• Mechanism used to organise screen display
• Provenance – where or by whom an encounter or event occurred
• Activity progress, completion dates or statuses

All pertinent information will be accessible to the Practice User  e.g. when viewing a battery of test results, the result type, value, the unit of measure, the clinician and dates (such as date sample taken, date test requested, date test performed, date results received) will be available together for each of the tests within the received result

See Role-based Access Control for required access controls

PIM15

Organise Patient Record

Organise to make optimal use of the record by any combination of the following mechanisms:

• Creating/maintaining a personalised display of a Patient Record that can be saved and applied to all Patient Records as a Practice User’s default (User defined structure and layout of the order of certain elements of a record) 
• Sorting/ordering – ad-hoc re-ordering of the content of a Patient Record chronologically and by any particular data item or groups of data items e.g. date of consultation / Encounter
• Filtering and grouping – identifying a subset of the record based on the type or value of a data item e.g. show all unplanned service Encounters grouped by contact types (out of hours, A&E, NHS111) or display/exclude all entries featuring a certain range of clinical codes recorded within a date range

It will be obvious to a Practice User when a record they are viewing has been grouped, filtered and/or sorted/ordered.

Filter record on 'Restricted from View Record' items

Ability to filter the Patient Record (as described in PIM15) on those items marked as 'Restricted from View Record' (see Patient Information Maintenance - Standard)

GP-05.2-04

Search a Patient Record

• Using all/any combination of coded or structured data held within or linked to the Patient Record
• For a specified text string across both structured data (including clinical terms) and free text fields
• For a document using classification and/or document properties (header file / document metadata)

See Data Standards for coded data requirements

PIM13

Search within Documents

Ability to search the contents of Documents attached to a Patient Record for a specified text string across both structured data (including clinical terms) and free text.

GP-05.2-05

Print/Export Patient Record

Practice User to have the ability to Print/export the entire Patient Record with the ability to select to also print/export:

• Attached documents or a selection thereof
• Audit Trails

GP-13.1-01

Patient Outside of Catchment Area

Indicate to a Practice User that a registered Patient is residing outside of the catchment area of the Practice.

See Patient Choice Scheme and out of area registrations for background information.

Sexual orientation Monitoring (DCB2094)

Adhere to the Sexual orientation Monitoring (DCB2094) Standard.

Service Access - Patient

• Have the ability to enable or disable the following Citizen Services at a Practice level and Patient level:
  • Communicate with Practice - Citizen
  • Appointments Management - Citizen
  • Prescription Ordering – Citizen
  • View Record - Citizen - the Practice will be able to configure access to the following Record Access Levels:
    • Summary Information Record
    • Detailed Coded Record
    • Document Access (Clinical and Administrative)
      • only to be available if Detailed Coded Record is also enabled
    • Full Record

Epic C13E20

Service Access - Proxy

• Have the ability to enable or disable the following Citizen Services for Proxies:
  • Communicate with Practice - Citizen
  • Appointments Management - Citizen
  • Prescription Ordering – Citizen
  • View Record - Citizen - the Practice will be able to configure access to the following Record Access Levels:
    • Summary Information Record
    • Detailed Coded Record
    • Document Access (Clinical and Administrative)
      • only to be available if Detailed Coded Record is also enabled
    • Full Record

This is dependent on the Proxy being eligible for access.

Service Access - Acute Prescription Requests

Have the ability to enable or disable Acute Prescription requests (see GP-SPFS-5.2.2-03A) at a Practice level or Patient level when Practice is enabled for Prescription Ordering – Citizen service.

Record Management Notification - Patient

Notify Practice Users that a Patient has requested to change their own VUA Demographics or Preferences 

Practice User to be able to process the update and have an option to send a notification to the Patient.

See Patient Information Maintenance - Standard for notifications around demographic and preference changes

Record Management Notification - Proxy

Notify Practice Users that a Proxy has requested to change their own VUA Demographics or Preferences and/or the Patient’s Demographics or Preferences.

Practice User to be able to process the update and have an option to send a notification to the Citizen and Patient.

See Patient Information Maintenance - Standard for notifications around demographic and preference changes

Citizen Communications

Incorporate the content of any Communicate With Practice - Citizen communications into the Patient Record:

• Clearly displaying the source and nature of the communication e.g. Communication from Clinician (Clinician Name) to Patient (Patient Name) or Communication from Citizen (Citizen Name) to Role (Role Type)
• Linking to previous Communications
• Accepting and linking to documents attached/embedded within the Communications and clearly displaying this

See Document Management for standards relating to storage of electronic documentation

Respond to Citizen Communications

Practice Users will be able to respond to Communications received via the Communicate With Practice - Citizen Solution

For Citizen standards on communicating with the Practice See Communicate with Practice - Citizen 

Service Configuration - Citizen Communications Recipient

Enable the Practice to define which Practice Users and which generic Roles or Groups are acceptable Recipients of a Citizen Communication. This configuration will drive the functionality available within the Communicate With Practice - Citizen service to ensure that the Citizen is given appropriate options as to the intended Recipient of any message they may write.

The communications with the Practice will cover communications for admin and clinicians, these need to be managed to ensure the right Practice members receive the correct communications.

See GP-PPFS-6.3-07 for Practice notifications

GP-PPFS-3.3-08A

Service Configuration – Record Access Start Date(s) - Patient

Provide the Practice with the ability to configure a Start Date for Full Record Access for Patients.

The Start Date determines the date from which the data made available goes back to, not whether the Service is offered/available by the Practice e.g. where the Full Record Access Start Date is set to 15th March 2015 and the Full Record Access is enabled (‘switched on’) by the Practice on the 1st April 2015:

• Any entries prior to 15th March 2015 relating to Full Record Access will default to 'Restricted from View Record' (see GP-PPFS-3.2-11)
  • Items prior to 15th March 2015 relating to Detailed Coded Record (see GP-PPFS-3.2-10) and Summary Information Record (see GP-PPFS-3.2-09) will need to be still available to view unless marked as 'Restricted from View Record' by a Practice User. (e.g. a previous asthma diagnosis prior to the Full Record Access Start Date is significant information that will still need to be visible)
• Any entries post 15th March 2015 will default to display to a Patient unless marked as 'Restricted from View Record' by a Practice User

For the Patient to see any entries prior to 15th March 2015 the Record Access Start Date can be set earlier upon review of the Patient Record.

Epic C13E21

Service Configuration – Record Access Start Date(s) - Proxy

Provide the Practice with the ability to configure a Start Date for Full Record Access for Proxies.

The Start Date determines the date from which the data made available goes back to, not whether the Service is offered/available by the Practice e.g. where the Full Record Access Start Date is set to 15th March 2015 and the Full Record Access is enabled (‘switched on’) by the Practice on the 1st April 2015:

• Any entries prior to 15th March 2015 relating to Full Record Access will default to 'Restricted from View Record' (see GP-PPFS-3.2-11)
  • Items prior to 15th March 2015 relating to Detailed Coded Record (see GP-PPFS-3.2-10) and Summary Information Record (see GP-PPFS-3.2-09) will need to be still available to view unless marked as 'Restricted from View Record' by a Practice User. (e.g. a previous asthma diagnosis prior to the Full Record Access Start Date is significant information that will still need to be visible)
• Any entries post 15th March 2015 will default to display to a Proxy unless marked as 'Restricted from View Record' by a Practice User

For the Proxy to see any entries prior to 15th March 2015 the Record Access Start Date can be set earlier upon review of the Patient Record.

Service Configuration - Welcome Message - Patient

Functionality to define text to be displayed to the Citizen at the point of logging into Citizen Services, such as a Welcome Message or Practice Information.

See GP-SPFS-5.1-04 

Service Configuration - Welcome Message - Proxy

Functionality to define text to be displayed to Proxies at the point of logging into Citizen Services, such as a Welcome Message or Practice Information.

See GP-SPFS-5.1-04 

Service Configuration - Configure Disclaimer - Patient

Functionality to define text to be displayed to the Patient when creating a message using the Communicate with Practice - Citizen Solution

See GP-CWP-3 for displaying the disclaimer 

Service Configuration - Configure Disclaimer - Proxy

Functionality to define text to be displayed to Proxies when creating a message using the Communicate with Practice - Citizen Solution

See GP-CWP-3 for displaying the disclaimer 

Service Configuration - Patient Record Review

By default, all elements will be available for access by Citizens in line with the Record Access Level specified (See record access requirements in View Record - Citizen).

Enable Practice Users to undertake a review as to the appropriateness for access by a Citizen where required for:

• A Patient Record (as a whole)
• Groups of elements of a Patient Record e.g. an entire consultation
• Individual elements e.g. a code, a medication

Allow the Practice User to record the outcome of the Citizen Services Review for each element as 'Restricted from View Record'.

Allow Practice User to subsequently make elements previously marked as 'Restricted from View Record' available for access by Citizens.

The Practice User can review all Coded elements of a Patient Record and record the outcome in a single step/action.

Where any part of the Record is marked as to be Restricted from View Record, this is to apply to all Citizen Services. Practice User will also to be able to record justification for such a decision (free text, but not mandatory).

Practice User to have the ability to change the outcome of a review for each element (fully audited within the Solution) where required.

Review Pathology and Radiology Results and Documents

The Practice User is able to review:

• Pathology Test results

• Radiology Test results

• External documents (not created by the Practice and not provided by the Citizen via Citizen Services).

There will be a record of the review process.

Service Configuration - Record Access Level - Practice

The Practice Level Configuration of the Service to act as a default setting for Record Access Level against a Patient.

The Record Access Levels can be set for the Practice can be set as per Patient Information Maintenance - Standard

Service Configuration - Record Access level - Patient

Have the ability to amend Record Access level for a Patient.

The Record Access level for a Patient cannot exceed the configured Record Access Level for the Practice.

E.g. if the Record Access Level for the Practice has been Set to 'Detail Coded Record' then the Patient's Record Access Level cannot be set to Full Record.

See View Record for Record Access Levels

Service Configuration - Patient Record Review at point of data entry

Enable Practice Users to determine the appropriateness of elements of a Patient’s Record for access by a Citizen at the point of data entry, with regard to

• Individual elements e.g. a code, a medication
• Groups of elements of a Patient Record e.g. an entire consultation

Allow the Practice User to record the outcome for each element as 'Restricted from View Record'.

Where any part of the Record is marked as to be Restricted from View Record, this is to apply to all Citizen Services. Practice User will also to be able to record justification for such a decision (free text, but not mandatory).

Practice User to have the ability to change the outcome of a review for each element (fully audited within the Solution) where required.

PIM14

Indicate 'Restricted from View Record' elements

Where elements are marked as 'Restricted from View Record', this is to be indicated to Practice Users when viewing these elements within all areas of the Solution. 

GP-PPFS-3.3-12

Identity Verification Recording and Configuration - Patient

Enable the Practice to configure the Solution to support Practice Policy on recording Identity Verification for Patients. Such configuration will include the ability to support DCB3051 for Identity Verification and Authentication Standard for Digital Health and Care Services

When the Identity verification is recorded it will include:

• Date (pre-populated with current date – amendable by Practice User)
• Practice User (populated by a list of Practice Staff, default to logged on Practice User)
• Type of Verification (Vouching, Identity Documentation)
• Attached evidence e.g. ID document (optional)

PIM24

Identity Verification Recording and Configuration - Proxy

Enable the Practice to configure the Solution to support Practice Policy on recording Identity Verification for Proxies. Such configuration will include the ability to support DCB3051 for Identity Verification and Authentication Standard for Digital Health and Care Services

When the Identity verification is recorded it will include:

• Date (pre-populated with current date – amendable by Practice User)
• Practice User (populated by a list of Practice Staff, default to logged on Practice User)
• Type of Verification (Vouching, Identity Documentation)
• Attached evidence e.g. ID document (optional)

Service Configuration - Communication Channels Configuration - Patient

Ability to set default Communication Channels to be used to provide Patients with Citizen Service specific information.

Service Configuration - Communication Channels Configuration - Proxy

Ability to set default Communication Channels to be used to provide Proxies with Citizen Service specific information.

Deactivate Citizen Services Access

Access to Citizen Services to cease immediately for deceased or otherwise deducted Patients.

Patients will no longer be classed as having ‘active’ registrations. i.e. VUA-Patient Association will be de-activated.

• Enable Identity Verification to be recorded multiple times if required by the Practice User.
• Where the Patient requesting access to Citizen Services is a registered Patient at that Practice and Identity Verification has already been recorded:
  • An Identity Verification Record will not need to be created as part of the VUA Creation process unless locally configured to separate VUA Identity Verification during the Registration process. 

See DCB3051 for Identity Verification and Authentication Standard for Digital Health and Care Services

• Enable Identity Verification to be recorded multiple times if required by the Practice User.
• Where the Proxy requesting access to Citizen Services is a registered Patient at that Practice and Identity Verification has already been recorded:
  • An Identity Verification Record will not need to be created as part of the VUA Creation process unless locally configured to separate VUA Identity Verification during the Registration process. 

See DCB3051 for Identity Verification and Authentication Standard for Digital Health and Care Services

Practice Users to create VUAs for Patients, to record and the update the following information:

• VUA ID*
• VUA Demographics (See Patient Information Maintenance - Standard for demographics required)
• VUA Linkage Key*
• ODS Code (of the Practice creating the VUA)*
• VUA Status
• VUA-Patient Association 
• VUA Identity Verification Record (See Patient Information Maintenance - Standard for requirements)

  • Anchor
    PIM24 PIM24

     Practice Users will be able to undertake Identity Verification again, as part of the Citizen Service registration process

All information above is mandatory to create a 'Live' VUA and will adhere to the data requirements defined within this Capability.

Data items marked with * will be Solution-generated and are non-editable, other data items can be pre-populated by the Solution or manual entry.

A VUA can be created without the VUA-Patient Association and/or VUA Identity Verification Record, however the Account would have a Status of Inactive until these are provided (See Patient Information Maintenance - Standard for VUA status)

The Solution will ensure that a Patient has a maximum of one VUA per Practice.

See Patient Information Maintenance - Standard for VUA management and Structure and Lifecycle of Patient Online Accounts for further information on Patient Online Accounts

VUA Creation - Proxy

Practice Users to create VUAs for Proxies, to record and the update the following information:

• VUA ID*
• VUA Demographics (See Patient Information Maintenance - Standard for demographics required)
• VUA Linkage Key*
• ODS Code (of the Practice creating the VUA)*
• VUA Status
• VUA-Patient Association (association with one or more Patient Records)
• VUA Identity Verification Record (See Patient Information Maintenance - Standard for requirements)
  • This can link to a Patient Identity Verification Record where the Proxy is also a Patient at the Practice, though Practice Users will be able to undertake Identity Verification again, as part of the Citizen Service registration process) 

All information above is mandatory to create a 'Live' VUA and will adhere to the data requirements defined within this Capability.

Data items marked with * will be Solution-generated and are non-editable, other data items can be pre-populated by the Solution or manual entry.

A VUA can be created without the VUA-Patient Association and/or VUA Identity Verification Record, however the Account would have a Status of Inactive until these are provided (See Patient Information Maintenance - Standard for VUA status)

The Solution will ensure that a Citizen has a maximum of one VUA per Practice.

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.

An example of a scenario this could support is if you are a Citizen at Practice A with a VUA-Patient Association of 'self', but at Practice B you are a 'proxy' for a relative.

Identity Verification would need to occur at each of the Practices in the above scenario.

See Patient Information Maintenance - Standard for VUA management and Structure and Lifecycle of Patient Online Accounts for further information on Patient Online Accounts

Creation of inactive VUA

The creation of an OSA will result in a VUA being created (with Status of Inactive) or an existing VUA updated within the Solution. 

A proposed VUA-Patient Association can be recorded but no assurance of the relationship has occurred, therefore access will be limited to the OSA Appointments functionality (even if VUA Identity Verification is undertaken) until VUA-Patient Association Assurance occurs. 

Any Demographic Detail recorded for the OSA pertaining to the Patient will be used for Patient Matching (comparing Patient Demographic Details entered by the OSA with Patient Demographic Details held in the Solution.

Adhere to the following data requirements:

VUA ID will be:

• A unique identifier per Practice (and/or per Solution)

VUA ID will not be:

• Changeable by any user or Solution 
• Re-usable i.e. even where a VUA is Inactive, the VUA ID will not be used or assigned to a future created VUA

GP-PPFS-4.3-03

Adhere to the following data requirements:

VUA Demographics to include the following data items:

• Title
• Forename(s)
• Family Name
• Date of Birth
• Contact Details 
  • Postal Address
  • At least one Telephone Number (and associated category e.g. Mobile)
  • Email Address

The Solution will provide the ability to record all VUA Demographics as above, however some VUA Demographics are not mandatory fields:

A Citizen will provide at least Forename(s), Family Name, Date of Birth and at least one set of Contact Details.

Patient Information Maintenance - Standard for notifications around demographic and preference changes

Adhere to the following data requirements:

VUA Demographics to include the following data items:

• Title
• Forename(s)
• Family Name
• Date of Birth
• Contact Details (this can include multiple instances/sets of Contact Details where the VUA has VUA-Patient Associations of both Type ‘Self’ and ‘Proxy’)
  • Postal Address
  • At least one Telephone Number (and associated category e.g. Mobile)
  • Email Address

The Solution will provide the ability to record all VUA Demographics as above, however some VUA Demographics are not mandatory fields:

A Citizen will provide at least Forename(s), Family Name, Date of Birth and at least one set of Contact Details.

Patient Information Maintenance - Standard for notifications around demographic and preference changes

Patient Record Management Notification - Patient 

Enable the Practice User when inserting, amending or deleting any Patient Demographic and/or Preference details to notify the Patient of the update

Any such selection to result in a Patient being automatically notified via their preferred verified Contact Details (see COM1).

Patient Record Management Notification - Proxy

Enable the Practice User when inserting, amending or deleting any Patient Demographic and/or Preference details to notify any Proxy of the Patient Record update.

Any such selection to result in the proxy being automatically notified via their preferred verified Contact Details (see COM1).

VUA Management Notification - Patient

Enable the Practice User when inserting, amending or deleting any VUA Demographic and/or Preference details to notify the Patient of the update.

Any such selection to result in a Patient being automatically notified via their preferred Verified Contact Details (see COM1).

VUA Management Notification - Proxy

Enable the Practice User when inserting, amending or deleting any VUA Demographic and/or Preference details to notify the Proxy of the update.

Any such selection to result in a Proxy being automatically notified via their preferred Verified Contact Details (see COM1).

Contact Details Verification - Patient

Verify a Patients Contact Details via a time-limited challenge-response mechanism, where the Solution will request confirmation details in the response. Upon successful verification i.e. receipt of confirmation details and the matching of those details against the data held within the Solution,

Contact Details to be given a Verification Status of ‘Verified’. Contact Details that require verification include:

• Email Address
• Mobile Phone Number

Contact Details Verification - Proxy

Verify a Proxy's Contact Details via a time-limited challenge-response mechanism, where the Solution will request confirmation details in the response. Upon successful verification i.e. receipt of confirmation details and the matching of those details against the data held within the Solution,

Contact Details to be given a Verification Status of ‘Verified’. Contact Details that require verification include:

• Email Address
• Mobile Phone Number

Contact Details Verification – Patient status update

Record and update the Verification status of the Patient's Contact Details, including

• Verified
• Unverified (default for any new Contact Details recorded and for existing unverified data)
• Requires Re-verification

Status can be recorded or updated

• Manually by the Practice Staff 
• Automatically by the Solution e.g. upon successful verification or upon receipt of a delivery failure

Contact Details Verification – Proxy status update

Record and update the Verification status of the Proxy's Contact Details, including

• Verified
• Unverified (default for any new Contact Details recorded and for existing unverified data)
• Requires Re-verification

Status can be recorded or updated

• Manually by the Practice Staff 
• Automatically by the Solution e.g. upon successful verification or upon receipt of a delivery failure

VUA details display

Display following VUA details and historic information to the Practice User:

• Demographic
• Preferences
• Service Access (including date and time of changes)
• Registration (including date and time)
• Identity Verification
• VUA Creation
• Patient Association 
• Registration for Services (including date and time)
• Current and historic Account Linkages
• Usage of Services linked to every Patient Record and updates of information

For every VUA-Patient Association display the following information for the VUA:

• First Name
• Family Name
• Service Access

VUA details display – Patient Record

Display to a Practice User all relevant details from within the Patient Record, for example:

• All current details relating to VUAs (and prospective VUAs) associated with that Patient Record
• Historic details for the VUA and Patient

Adhere to the following data requirements:

VUA Linkage Key will be

• As per Authority defined standards 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

GP-PPFS-4.3-06

Adhere to the following data requirements:

VUA Status can be:

• Inactive – default state upon VUA Creation.
  • VUA will revert to Inactive where:
    • 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

• Live – to only become Live when the following is completed:
  • Completion of Account Linkage 
  • Identity Verification
  • VUA-Patient Association with at least one Patient Record

See GP-PPFS-6.1-01 for VUA management

Adhere to the following data requirements:

VUA-Patient Association will exist between a VUA and one active Patient Record, to include the:

• Type of Association (See Patient Information Maintenance - Standard)
• Assurance of the Relationship (See Patient Information Maintenance - Standard)
• Services Registered
• Start Date
• End Date to be populated:
  • Where a timespan is known (e.g. Patient record looked after for 6 months)
  • The VUA-Patient Association will be end-dated/inactivated if the Patient is no longer registered at the Practice
  • If the Patient withdraws Consent for the VUA-Patient Association

VUA-Patient Association - Proxy

Adhere to the following data requirements:

VUA-Patient Association will exist between a VUA and at least one active Patient Record, each instance to include the:

• Type of Association (See Patient Information Maintenance - Standard)
• Assurance of the Relationship (See Patient Information Maintenance - Standard)
• Services Registered
• Start Date
• End Date to be populated:
  • Where a timespan is known (e.g. Patient record looked after for 6 months)
  • The VUA-Patient Association will be end-dated/inactivated if the Patient is no longer registered at the Practice
  • If the Patient withdraws Consent for the VUA-Patient Association
  • Automatic updates which are age-related or Competence based e.g. VUA-Patient Association of Type ‘Proxy’ will have access automatically removed upon a Patient’s 16th birthday where a Competent Patient has not given Explicit Consent.

The Solution will support:

• Many to many VUA-Patient Associations i.e. Proxies can be associated with multiple Patient Records and
• A Patient Record will be capable of having multiple VUAs associated with it.

Where possible and appropriate, the Relationship information to link to / be populated by the Related Persons recorded within the Solution with a Related person type of 'Proxy'.

Adhere to the following data requirements:

Each VUA-Patient Association will have a Type of Association of:

• Self (zero or one such Self Association is permitted). Where the Type of Association is ‘Self’, the Solution to pre-populate all necessary Assurance of Relationship detail, such that a Practice User is not required to record any further information except the Type of Consent given by the Patient

See Patient Information Maintenance - Standard for Patient preference details

VUA-Patient Association – 'Self' or 'Proxy' Association

Adhere to the following data requirements:

Each VUA-Patient Association will have a Type of Association of either:

• Self (zero or one such Self Association is permitted). Where the Type of Association is ‘Self’, the Solution to pre-populate all necessary Assurance of Relationship detail, such that a Practice User is not required to record any further information except the Type of Consent given by the Patient
• Proxy (zero, one or many such Proxy Associations are permitted)
  • Where Child competence has been recorded as 'not competent' or Adult Capacity has been recorded as 'lacks capacity' then they cannot have an Association of 'Proxy' with another Patient.

Practice User to be able to record Preferences for use with the Proxy Association and any subsequent Proxy Association. 

See Patient Information Maintenance - Standard for Patient preference details

See RCGP documentation for information on proxy access

See GP-PPFS-3.4-06 for recording Child Competence and GP-PPFS-3.4-08 for recording Adult Capacity 

Adhere to the following data requirements:

Practice User to record the Legal Basis including:

• Type of Relationship (Self)
• Explicit consent of the Citizen (where VUA-Patient Association is of type 'Self' this can be pre-populated by the Solution)
  • Method of Consent
    • Written
    • Verbal

For each/any Legal Basis selected, Practice User to have the ability to record Details (free text) to support the Assurance of the Relationship

Adhere to the following data requirements:

Practice User to record the Legal Basis including:

• Type of Relationship / Relationship to Patient (including Self, Mother, Father, Son, Daughter, Friend, Carer)
• Explicit consent of the Citizen (where VUA-Patient Association is of type 'Self' this can be pre-populated by the Solution)
  • Method of Consent
    • Written
    • Verbal
• Parental Responsibility (this can be pre-populated by the Solution only where the VUA-Patient Association is of Type ‘Proxy’, the Patient is a Child for which no Competence Decision of ‘Competent’ exists and there is a Patient Relationship of Mother or Father recorded in the Patient Record). Such a Basis will need a Type of Verification recording:
  • Vouching
    • • Type of Vouching, including
        • • Personal
          • Information confirmation (e.g. knowledge of details on their medical record)
      • Vouched for by (populated by a list of Practice Staff, default to logged on Practice User)
  • Identity Documentation (multiple instances and associated documents, as per local configuration)
    • • Type of Document, including
        • • Passport
          • Birth Certificate
          • Marriage Certificate
          • Other
      • The Practice User might not always have the opportunity to attach ID documents at the point of registration, this flexibility will need to be considered.
      • ID documents attached will need to be excluded form GP2GP transfer
      • Associated Document (copy of or link to an image of the identity document, likely scanned in the Practice – Practice User to have ability to scan and attach or link to already stored image of the identity documentation as part of this process)
  • Previously recorded e.g. where the Related persons details are already stored within the Solution and as such have been previously verified
• Patient lacks Capacity
  • Lasting Power of Attorney for health and welfare
  • Court Appointed Deputy
  • Best Interests (with ability to record the Clinician, who with a clear appreciation and understanding of the facts, implications and future consequences in line with the Mental Capacity Act, has agreed the VUA-Patient Association)
    • Clinician (populated by a list of Practice Staff, default to logged on Practice User)

For each/any Legal Basis selected, Practice User to have the ability to record Details (free text) to support the Assurance of the Relationship

VUA Management – Legal Basis for Request of Service

The Legal Basis for Service Registration will be recorded when Service Access has been requested at a different time to recording the Legal Basis for the Assurance of the Relationship.

This will need to be done for each VUA-Patient Association that is requesting access to a Citizen Service.

The data to be recorded for the Legal Basis for a Citizen Services request will be the same as per Patient Information Maintenance - Standard

If the Legal Basis for Assurance of the Relationship is recorded at the same time as registration for a Citizen Service there is no need to record it separately to grant Service access at that point in time

Grant Patients access to Citizen Services at the VUA-Patient Association level.

A Patient will not be granted access to any Citizen Services that are not enabled for the Practice and for the Patient for whom they are associated with.

The minimum default access when creating a new VUA-Patient Association is practice configurable and detailed in Patient Information Maintenance - Standard.

See GP-SPFS-5.3-01 for VUA-Patient Association requirement 

Grant Proxies access to Citizen Services at the VUA-Patient Association level. The Proxy will be able to request access for a specific VUA-Patient Association

A Proxy will not be granted access to any Citizen Services that are not enabled for the Practice and for the Patient for whom they are associated with.

The minimum default access when creating a new VUA-Patient Association is practice configurable and detailed in Patient Information Maintenance - Standard.

See GP-SPFS-5.3-01 for VUA-Patient Association requirement 

Generate for a Citizen with a VUA the following information about the Practice and VUA Credentials:

• Practice ODS Code
• VUA ID
• VUA Linkage Key
• The Citizen needs to be aware of the Citizen Service available to them, and to where they need to go to access the services provided (i.e. URLs for the Citizen Service offerings)
• The Citizen needs to be aware of any Solutions providing a Citizen Service which is integrated with the PIM Solution.

Provide the generated VUA information (see Patient Information Maintenance - Standard) to a Citizen via multiple / a combination of Communication Channels.

Appropriate Channel as defined by the Practice User at the point of provision and accounting for Contact Details as recorded for the Citizen.

Trusted Communication Channel used: A trusted Communication Channel can be used for provision of the VUA Credentials, for enhanced security.
Trusted Communication Channel not used: The Solution will split the provision of the VUA Credentials such that

• VUA ID is provided via one channel and VUA Linkage Key via another channel

or

• VUA ID is provided via one channel and VUA Linkage Key via the same channel in a different communication e.g. where only one communication channel is available

See Trusted Communication channels for definition

VUA Credentials Provision –  Multiple trusted Channels

Provide the generated VUA information to a Citizen via different methods of communication which supports with the Practice policy.

Trusted Communication Channel used: Multiple / a combination of Communication Channels can be used for provision of the VUA Credentials, for enhanced security.

See Trusted Communication channels for definition

VUA Credentials Generation – Prevention (due to incomplete activity for Patient)

Credentials cannot be generated until:

• Patient has been identified and identity verification completed (where Patient is requesting access to Citizen Services)
• VUA created and 'Live'
  • Where a VUA already exists and it is not Inactive
• VUA Association with one or more Patient Records including:
  • Citizen Registration for Services

See GP-SPFS-4.1-02A for Account Linkage  

VUA Credentials Generation – Prevention (due to incomplete activity for Proxy)

Credentials cannot be generated until:

• VUA created and 'Live'
  • Where a VUA already exists and it is not Inactive
• Identity Verification of the Proxy requesting Services has been recorded
• VUA Association with one or more Patient Records including:
  • Citizen Registration for Services
  • Assurance of the Relationship between the Proxy and the Patient (where the Proxy is acting on behalf of a Patient who is not themselves)

See GP-SPFS-4.1-02A for Account Linkage  

Where one or more Citizen Services are delivered, then the Solution will confirm to the Citizen Service Solution that information provided (including VUA Credentials and Demographics) is a successful match i.e. the Solutions match and Account Linkage is complete.

The Solution can request the additional demographics required to confirm a match. This information can be established during integration between this Solution and Solutions that provide Citizen Services.

Upon completion of Account Linkage for the first time, the VUA will become 'Live' 

See Patient Information Maintenance - Standard for Account Linkage key reset

Manually update (by a Practice User) all aspects of a VUA including:

• VUA Demographics and Preferences (including verification of Contact Details)
• VUA Linkage Key (only via VUA Linkage Key Reset functionality)
• VUA Status, including deactivation of a VUA and reactivation of an Inactive VUA
• VUA-Patient Association 
  • Registration for Services
• VUA Identity Verification Record (one or more)

See Patient Information Maintenance - Standard for VUA Creation

Support the resetting of the VUA Linkage Key as requested, both

• Via the Citizen Service Solution.
• By a Practice User via their Solution.

Upon reset request, the VUA will:

• Revert to a Status of Inactive and all access to Citizen Services terminated excluding limited Appointment functionality for OSAs

VUA is re-activated by the Practice when the Citizen successfully undertakes a subsequent Account Linkage.

In order to re-activate the VUA, the Practice will need to undertake VUA Identity Verification and a new VUA Linkage Key will need to be generated. VUA Credentials will then be provided to the Citizen via the processes and functionality defined within VUA Generation.

See GP-SPFS-5.3-07 for VUA requesting Linkage Key reset and Patient Information Maintenance - Standard for Account Linkage

Account Linkage Key Reset - Suspicious Activity

The Citizen Service Solution can also request the VUA Linkage Key Reset due to identification of suspicious activity.

See OWASP Top 10 - 2017 for guidance on Suspicious Activity.

VUA Credentials Reminder

Generate for a Citizen with a Live VUA (upon receipt of a request via Citizen Services) the following information:

• Practice ODS Code
• VUA ID
• VUA Linkage Key
  for provision to the Citizen via Citizen Services.

It will be possible for a Practice User to manually generate a reminder of the VUA Credentials for a Citizen with a Live VUA as per Patient Information Maintenance - Standard and Patient Information Maintenance - Standard

See GP-SPFS-5.3-06 for Citizens accessing Account Credentials

Notification of new VUA-Patient Association - Patient

Notify a Patient via their preferred verified Contact Details (see COM1) that:

• The Patient is the subject of a new VUA-Patient Association due to VUA Activation and/or VUA Management (Patient Notification).

See GP-SPFS-5.3-01 for VUA-Patient Association requirement, and Patient Information Maintenance - Standard for notifications around demographic and preference changes

Notification of new VUA-Patient Association - Proxy

Notify a Proxy via their preferred verified Contact Details (see COM1) that:

• The Patient is the subject of a new VUA-Patient Association due to VUA Activation and/or VUA Management (Patient Notification).
• The Proxy's access to services has changed, where the Registration for Services relating to a VUA-Patient Association for which the Patient is the subject, has been amended (Proxy notification)

See GP-SPFS-5.3-01 for VUA-Patient Association requirement, and Patient Information Maintenance - Standard for notifications around demographic and preference changes

Notify a Patient via their preferred verified Contact Details (see COM1) upon successful Account Linkage.

Once a notification for successful Account Linkage has been sent if a Patient Citizen Services Solution then another notification is not needed

See Patient Information Maintenance - Standard for notifications around demographic and preference changes

Notify a Patient and their Proxy via their preferred verified Contact Details (see COM1) upon successful Account Linkage:

• That a new Proxy is now using Citizen Services with their Patient Record and/or that a Proxy is using a new Citizen Services Solution (Patient Notification).
• That a new Citizen Services Solution is being used (Proxy Notification).

Once a notification for successful Account Linkage has been sent if a Proxy chooses another Citizen Services Solution then another notification is not needed

See Patient Information Maintenance - Standard for notifications around demographic and preference changes

Notification of Failed login

Where a User has attempted to access Citizen Services, but has failed authentication on multiple occasions within a short space of time (for guidance see Digital Identity Guidelines), then the VUA holder will be notified via their preferred contact method (see COM1).

See Patient Information Maintenance - Standard for notifications around demographic and preference changes

Alternative channels/methods of notification

• Where preferred Verified Contact Details (see COM1) have not been recorded, any Verified Contact Details to be used.
• Where no contact details have been verified, Patient and/or Proxy to be informed via any contact details provided, however, Patient details except for Patient name (title, forename(s) and family name), will not be included within the communication.

See Patient Information Maintenance - Standard for notifications around demographic and preference changes

Indicate to Practice Users when accessing a Patient Record for a Patient with a Self Association without Verified Contact Details recorded.

Such that the Practice User can inform the Patient of the implications of not providing verifiable Contact Details e.g. VUA Credentials Reminder only possible via Citizen Services and VUA Linkage Key reset functionality will require a visit to the Practice.

Indicate to Practice Users when accessing a VUA where the Proxy does not have any Verified Contact Details recorded.

Such that the Practice User can inform the Proxy of the implications of not providing verifiable Contact Details e.g. VUA Credentials Reminder only possible via Citizen Services and VUA Linkage Key reset functionality will require a visit to the Practice

Child Competence Management – Patient

Upon recording a Competence Decision of ‘Competent’ for a Child who is a Patient, Clinician to have the ability to update the Patient's Service Access as required.

See Patient Information Maintenance - Standard for Competence Assessments with maturing children

See Patient Information Maintenance - Standard for Service Access

See Competence Assessment for further information

See GP-PPFS-3.4-06 for recording Child Competence and GP-PPFS-3.4-08 for recording Adult Capacity 

Child Competence Management – Proxy

Upon recording a Competence Decision of ‘Competent’ for a Child who is a Patient, Clinician to have the ability to update Proxy Service Access as required. In such instances, where VUA Associations are reviewed by the Patient and considered appropriate and/or updated, the Legal Basis for those VUA-Patient Association(s) to be automatically updated to ‘Explicit Consent’.

See Patient Information Maintenance - Standard for Competence Assessments with maturing children

See Patient Information Maintenance - Standard for Service Access

See Competence Assessment for further information

See GP-PPFS-3.4-06 for recording Child Competence and GP-PPFS-3.4-08 for recording Adult Capacity 

Association of 'Not Competent' Child

Where a Child is recorded as ‘Not Competent’, there cannot be a Citizen with a VUA-Patient Association of Type ‘Self’ associated with their Patient Record (until they turn 16 / become an Adult).

See GP-PPFS-3.4-06 for recording Child Competence and GP-PPFS-3.4-08 for recording Adult Capacity 

Citizen Services Access – Age and Competence - Patient 

Allow access to Citizen Services based on age and Competence.

• A Child can be deemed eligible to have an association of 'Self' if they are considered Competent (default is not eligible as a Child needs to be actively assessed and recorded as Competent before they can have a Live VUA)
• Adult (Patient aged 16 or over) is likely eligible to have access to Citizen Services (default is eligible due to assumed Capacity of an Adult, however this can change following a Capacity assessment)

See GP-PPFS-3.4-06 for recording Child Competence and GP-PPFS-3.4-08 for recording Adult Capacity 

Citizen Services Access – Age and Competence - Proxy

Allow access to Citizen Services based on age and Competence.

• A Child can be deemed eligible to have an association of 'Self' and be a Proxy for another Patient if they are considered Competent (default is not eligible as a Child needs to be actively assessed and recorded as Competent before they can have a Live VUA)

See GP-PPFS-3.4-06 for recording Child Competence 

Citizen Services Access for Patients 0-15

The Legal Basis for a VUA-Patient Association for a Patient aged 0-15 inclusive can be ‘Explicit Consent’ only if the Child who is a Patient is deemed to be Competent.

The 'Competent' Child can be involved in:

• Deciding which Citizen can be associated with their Patient Record
• Deciding what level of Service Access an associated Citizen can have

See RCGP documentation on proxy access on behalf of children and young people

Citizen Services Access Following 11th Birthday

On the Child’s 11th birthday, the Solution will automatically restrict the scope of existing proxy access.

Access to the following services will be switched off automatically when the Child reaches the age of 11:

• View Record

Proxy access can be reinstated if, after discussion with the Citizen/s requesting access, the Child’s GP believes that proxy access would be in the Child’s best interest.

Such Patient age-related updates to result in information being passed to all/any Citizen Services used by each of the affected Citizens, such that the Citizen Service Solution can highlight to the Citizen the change in Service Access that has been applied and the need for them and/or the Patient to consult with the Practice if they wish to enhance or re-establish their Service Access.

See RCGP documentation on proxy access on behalf of children and young people

Citizen Services Access Following 16th Birthday

A Citizen of VUA-Patient Association of Type ‘Proxy’ will have access automatically removed upon a Patient’s 16th birthday where a Competent Patient has not given Explicit Consent

Once the Child turns 16, their Competence becomes irrelevant as they are an Adult and the relevant allowances/restrictions apply i.e. they are assumed to have Capacity under the Mental Capacity Act 2005.

Such Patient age-related updates to result in information being passed to all/any Citizen Services used by each of the affected Citizens, such that the Citizen Service Solution can highlight to the Citizen the change in Service Access that has been applied and the need for them and/or the Patient to consult with the Practice if they wish to enhance or re-establish their Service Access.

Practice Notification of Patient Age-related Competence Management

Indicate to a Clinician when a Maturing Child interacts with the Practice i.e. when accessing a Maturing Child’s Patient Record, that a Competence Assessment is required.

This notification need not be generated where a Maturing Child has a Competence Decision of:

• Competent
• Not Competent and the timescale indicated by the Clinician at point of assessment has indicated that a re-assessment need not yet occur (suggested date of re-assessment has not been reached as per Child Competence Management Decision)

See Patient Information Maintenance - Standard for Child Competence management

See Workflow for Task Management

Notify the Practice that a Patient with a Competence Decision of ‘Not Competent’ has turned 16 and the Patient’s Capacity need now be assessed as an Adult.

Notification is not required where the Competence has not been assessed and the Child was assumed 'Not Competent'

See Patient Information Maintenance - Standard for Citizen Services access for children

See Workflow for Task Management

Audit Citizen Service Usage

The Solution will give Practice Users the ability to see the Audit Trail for individual's usage of Citizen services.

Patient Record screening

The Supplier shall ensure that the Solution enables the Patient's electronic records to be screened by Authorised Users for data that could be detrimental to a patient if viewed and/or third party information before responding (with such information being redacted) to a subject access request. This must adhere to the General Data Protection Regulation (GDPR).

This ability to be subject to the requirements described in Legitimate Relationships.

Record Subject Access Request

The Supplier shall ensure that the Solution enables a user to record a subject access request adhering to the General Data Protection Regulation (GDPR).

Also see NHS Digital guidance on GDPR

Subject Access Request refusal reason

Where a subject access request is refused, the Solution shall require that a reason for refusal is selected from a pre-defined list adhering to the General Data Protection Regulation (GDPR)

Also see NHS Digital guidance on GDPR

Subject Access Request access controls

The Solution shall enforce RBAC controls to control access to functionality described in this section as per Role-based Access Control.

Subject Access Request monitoring

The Solution can provide functionality for monitoring requests in progress and for reporting on targets for fulfilment as per General Data Protection Regulation (GDPR).

Also see NHS Digital guidance on GDPR

Capitation Reporting

Ability to generate a Patient-based report on Capitation (list by Usual GP of current registered Patients – as per current legislative registration status/type)

Child Vaccinations and Immunisations Reporting

Ability to generate a Patient-based report on Child vaccinations and immunisations, regarding coverage of Interventions relating to Childhood Immunisation Schemes (See latest version of The General Medical Services Statement of Financial Entitlements Directions documentation here)

Carers Reporting

Ability to generate a Patient-based report on Carers. For example, a list of Carers linked to Patients or specified Patient Characteristics.

See Patient Information Maintenance - Standard for recording information for related persons

Epic C13E12

GP-11.2-03

Create Patient Cohorts

Create Patient Cohorts from Search Results

• Update Patient Cohorts e.g. adding or deleting records from the saved Patient Cohort
• Manage Patient Cohorts e.g. combine Patient Cohorts to create a new Patient Cohort, or Patient Cohort A minus Patient Cohort B to create a new Patient Cohort
• Applying Search Criteria to create further Patient Cohorts