standard operating procedure for systmone

Did you print this? Please makes sure you are accessing the most recent version.

Visit: http://thepulse/our-trust/trustwide-policies-procedures/

Standard Operating Procedure for SystmOne

November 2019/2022 Procedure Version: V1.0 December 2019 This document remains valid whilst under review

TARGET AUDIENCE (including temporary staff)

People who need to know this document in detail

All staff and students who use, access, handle or manage SystmOne Health Records, Service and Team Managers.

People who need to have a broad

understanding of this document

Service Managers

Information Governance team

Clinical records leads

Information Asset Owners

Registration Authority

Application Support Team

People who need to know that this document exists

All staff using SystmOne

Clinical Directors

Caldicott Guardian

Author: Digital Clinical Safety Team

Approved by: Health Records Group Date: 29.11.19

Ratified by: Information Governance and Security Group Date: 17.12.19

Date of next review: November 2022

http://thepulse/our-trust/trustwide-policies-procedures/


Excellent care at the heart of the community 2

VERSION CONTROL

Record of Changes

Date Version Changes / Comments

29.11.19 1.0 Combination of multiple SystmOne related SOPs into one document



1. INTRODUCTION ................................................................................................. 4

2. ACCESS TO SYSTMONE .................................................................................. 7

3. SMARTCARD USE ........................................................................................... 14

4. RECORD KEEPING ......................................................................................... 15

5. ACCESSING RECORDS .................................................................................. 16

6. REGISTERING A RECORD TO THE UNIT ...................................................... 17

7. RECORDING AND UPDATING DEMOGRAPHICS ......................................... 19

8. SENSITIVE RECORDS .................................................................................... 24

9. CASELOAD MANAGEMENT ........................................................................... 26

10. RECORDING RELATIONSHIPS ...................................................................... 27

11. DOCUMENT MANAGEMENT .......................................................................... 28

12. CONSENT FOR SHARING RECORDS ............................................................ 30

13. PATIENT CONTACT ........................................................................................ 32

14. HOW TO MANAGE AN INCORRECT ENTRY IN THE PATIENT RECORD ... 35

15. MANAGEMENT OF TASKS ............................................................................. 38

16. MEDICATIONS, SENSITIVITIES AND ALLERGIES ........................................ 44

17. ALERTS AND REMINDERS ............................................................................ 47

18. RECORDING SAFEGUARDING CONCERNS ................................................. 50

19. CLOSING THE RECORD ................................................................................. 56

20. DISCHARGE..................................................................................................... 57

21. TEAM OR SERVICE CHANGES ...................................................................... 58

22. STAFF ABSENCE ............................................................................................ 59

23. KEY PERFORMANCE INDICATORS (KPIS) ................................................... 60

24. RESPONSIBILITIES ......................................................................................... 60

25. ASSOCIATED DOCUMENTS AND REFERENCES ........................................ 61

26. DISSEMINATION AND IMPLEMENTATION .................................................... 62

27. CONSULTATION, APPROVAL, RATIFICATION & REVIEW .......................... 62

APPENDIX 1: SYSTMONE TEMPORARY ACCESS PROCESS............................ 63

APPENDIX 2: PROCESS FOR MANAGING TEMPORARY STAFF ACCESS TO SYSTMONE ............................................................................................................. 63

APPENDIX 3: CONFIDENTIALITY AGREEMENT FOR NON SCFT STAFF & STUDENTS ACCESS TO PATIENT INFORMATION .............................................. 64

APPENDIX 4: CONTACTING THE DIGITAL SERVICE DESK ............................... 76

APPENDIX 5: REQUESTING CHANGES TO SYSTMONE .................................... 76

APPENDIX 6: SYSTEM-WIDE TASK TYPES ......................................................... 76



1. INTRODUCTION

SystmOne is an electronic patient record system used within Sussex Community Foundation NHS Trust.

1.1. Purpose

The purpose of this Standard Operating Procedure (SOP) is to specify the processes required to ensure safety of patients through standardised use of SystmOne and documentation of information within the SystmOne patient record. Following this guidance will ensure that information is documented appropriately and is easily accessible in a consistent section of the health record.

1.2. Scope

This document applies to all staff working within SCFT services using SystmOne, including temporary staff, students and non-SCFT staff working alongside our services. It describes:

Access to SystmOne Creation of Records Access to Records Record Sharing Records Management Tasks Management Closing the Record Discharge and Recording a Death

1.3. Where to get guidance on using SystmOne

This SOP outlines SystmOne processes which are applicable across SCFT services. It should be used in conjunction with the appropriate service-specific SOP which outlines the specific processes used in your service. Quick Reference Guides (QRGs) offer step-by-step instructions, e.g. How to unlock a Smartcard. QRGs are accessed in 2 ways:

1. On SystmOne screen: use the quick link button QRG at the top of the page. 2. On the Pulse: click on Digital in the right upper corner of the home page, then

SystmOne in the left upper corner. The option Quick Reference Guides (QRG) is available in the centre of the following page. http://thepulse.sussex.nhs.uk/it/systmone/quick-reference-guides.htm

The relevant QRGs are referenced throughout this document.

http://thepulse.sussex.nhs.uk/it/systmone/quick-reference-guides.htm



Help function in S1: click F1 on your keyboard to open the S1 Help function. Using the Search function allows you to find specific information.

1.4. Definitions

Alert A message/icon/symbol linked to a read code in the patient record which is displayed on the patient home view when the record is retrieved and is flagged with a symbol on every screen in the patient record.

B&H Brighton and Hove

Caldicott Guardian

The person in each NHS and social care organisation who ensures that their organisation meets the required standards for handling patient identifiable information.

CCHIS Community Child Health Information Service

Clinical Tree A list of the different clinically relevant sections of the patient record, located at the left side of the screen in the SystmOne electronic patient record.

IG Information Governance

EDSM Enhanced Data Sharing Model: The model within SystmOne is to enable sharing of the records with other SystmOne organisations, e.g. GP, and recording of the patient's sharing preferences: sharing out to other services and viewing the record shared by other services.

KPI Key Performance Indicators: set by the commissioners in West Sussex and Brighton & Hove to measure service performance

NBO National Back Office: provides a national data quality service. It's responsible for the management of NHS Numbers and PDS records, investigation and resolution of data quality incidents on Personal Demographics Service (PDS) demographic records, and the provision of a Tracing Service to approved organisations.

Node A section of the clinical tree which can be interacted with to record/perform relevant info/tasks

Organisation Sharing Group

A collection of SystmOne units which are grouped together to allow sharing of the patient records within SCFT irrespective of the EDSM record sharing preferences. All adult services units belong to the adults organisation sharing group.

PDS Personal Demographics Service: holds the demographic details of users of health and care services in England, including name, address and NHS number. It is used to confirm the identity of patients, link care records, support communications with patients and support management of NHS Services.

Pre-Registration Student

A Student currently in education and working towards a qualification in their chosen profession, under the supervision of a mentor for example student nurse, student physio or OT

Post- Registration Student

A Student who has completed pre-registration training and is named on professional register but is now completing additional training for example student Health visitor, School nurse or District Nurse.

RA Registration Authority: The service responsible for issuing and governance of smartcards and smartcard access following National policy and procedures.



Reminder A free text message of low, normal or high priority which is displayed on the patient home view when the record is retrieved and is flagged with a symbol on every screen in the patient record.

Safeguarding Information Node

A section on the clinical tree containing system wide safeguarding information. This node is only visible to staff with the access right to ‘view safeguarding alerts’ and the information is shared regardless of record sharing settings.

SCFT Sussex Community Foundation Trust

Smartcard Card providing access to SystmOne and other NHS Care Record Service applications

SCR The Summary Care Record: This is the national electronic database of NHS patient demographic details such as name, address, date of birth, GP and NHS Number. It also contains key information from the GP record: medications and allergies. All electronic health record systems interact with the SCR. The SCR visible in SCFT records is read-only.

SOP Standard Operating Procedure

SPINE, The Allows information to be shared securely between different electronic record systems, including patient demographic data. For example, if one organisation updates personal data such as a patient’s address on their system, the SPINE will pass the information on to another organisation when they open the patient’s record.

Sponsor A manager with authority to allocate appropriate smartcard positions, roles and activities to their staff for accessing SystmOne

SystmOne The main electronic patient record system used by SCFT, developed by TPP (The Phoenix Partnership)

SystmOne unit

The SystmOne care setting. This may consist of one or a number of services or teams based on both clinical and administrative requirements of services in SCT.

Temporary Staff

Temporary staff includes students, agency staff, bank staff, locums, visiting doctors, contracted staff, staff who have been moved within the service to cover for shortages and “back to the floor” staff



2. ACCESS TO SYSTMONE

All members of staff, including bank and agency workers, locums, visiting doctors, managers working back to floor, staff re-distribution to another service at short notice and certain students will require access to patient records to enable them to work effectively and safely. Different services may have different requirements for temporary staff access to the electronic patient record, depending on the nature of the service. The purpose of this section is to provide guidance on how to manage access to SystmOne for all staff requiring this access, including ensuring appropriate control and removal of access when it is no longer appropriate. It also aims to ensure safe patient care and enable maintenance of the contemporaneous patient record within SystmOne, even in the event that it is not possible or appropriate to provide access to the system. This section details how to manage the viewing and entering of relevant clinical information in order to provide informed continuous patient care within Sussex Community Foundation NHS Trust (SCFT), when staff do not have access to SystmOne. To access SystmOne, there is an expectation that all staff working within SCFT will use a smartcard and will receive appropriate training. Different levels of access will be provided according to the role and requirements of staff. For staff who are not required to enter information into the system, but are required to view patient records, Read Only access will be arranged (see 2.1.4). Training is tailored to the requirements of the services and staff roles. All staff issued with a smartcard must use this to access SystmOne, as stated in the Registration Authority Policy. Smartcard access ensures connection to the SPINE, which enables information to be shared securely through national services such as the Summary Care Record. Connection to the SPINE is essential for appropriate sharing of information such as demographic updates.

2.1. Standard Access Procedure for SystmOne

The standard procedure for arranging access to SystmOne applies to regular SCFT staff and any temporary staff who will be working within SCFT for more than just a one off shift. When a new member of staff joins the service, or temporary staff are planned to provide cover, the authorised SystmOne service sponsor must confirm whether the staff member has:

A smartcard

Appropriate SystmOne competencies for the service

Access to the required SystmOne unit = correct Smartcard profile

Access to SCFT Network account (a requirement to access SystmOne via the SCFT IT Network).

http://thepulse/downloads/trustwide-policies-procedures/it-comms/registration-authority.pdf



The relevant provision (i.e. smartcard, training, smartcard profile) should be requested as soon as a start date is agreed, to ensure that training and system access can be arranged for new starters as soon as possible after their commencement in post. Any exceptional circumstances will require discussion with the Systems Training Manager. 2.1.1 Staff Requiring a Smartcard For staff without a smartcard, the New Smartcard Registration form should be completed;this is available on the Pulse: https://servicedesk.scft.nhs.uk/support/catalog/items/79 The requirement for the smartcard profile to access the relevant SystmOne unit(s) and a link to complete the SystmOne Training Request Form are also indicated within the New Smartcard Registration form. 2.1.2 Staff Requiring Training and Smartcard Profile Staff may already have a smartcard from another organisation, or may have worked in another role within SCFT. Unless they already have the appropriate competencies for using SystmOne within the service, the relevant training must be completed. The Electronic Staff Records (ESR) system is used to record details of staff with smartcards and those who are trained and competent in using SystmOne. ESR will feed information into the e-Rostering system to enable assignment of temporary staff with the relevant skills to fill the vacant shifts.

Competencies will be defined as either Administrative or Clinical and will be categorised according to the functionality which is used in different services, indicating the areas in which the temporary staff would be competent to use SystmOne:

Community: Appointments / Rotas

Community: Care Plans / Visits

Minor Injuries Unit

Community Hospital For staff without the appropriate competencies, the sponsor is responsible for completing the Training Request Form, and should indicate on the form that the member of staff already has a smartcard: https://servicedesk.scft.nhs.uk/support/catalog/items/204 The form should be used to indicate which SystmOne unit(s) the member of staff will require access to.

https://servicedesk.scft.nhs.uk/support/catalog/items/79




2.1.3 Staff Requiring Smartcard Profile Change: Access to the Relevant SystmOne Unit Staff may already have a smartcard and the appropriate competencies, for example they have previously worked within the service but in a different geographical location. A smartcard profile change will be required to ensure that access to the relevant SystmOne unit is provided: https://servicedesk.scft.nhs.uk/support/catalog/items/136 The free text ‘What needs to be updated?’field on this form should be used to indicate which SystmOne unit(s) the access is required for, and when the access is required. There are some service specific access rights which can only be set up after the staff member has logged in to the unit, for example, to include the member of staff on the list for being able to allocate visits to them. The RA team will update the access rights when the member of staff has logged in to the new SystmOne unit(s). 2.1.4 Read Only Access to SystmOne If staff only require access to view patient records, not to update information within SystmOne, training is provided via e-learning: http://thepulse/it/systmone/systmone-elearning.htm In addition to completing this e-learning, the staff will need to have completed Information Governance training within the past 12 months and will require a smartcard with the relevant profile. The appropriate request should be made via the Self Service Portal, using the relevant form to request a new smartcard or a profile change on an existing smartcard. The EPR Core SystmOne unit is designed for providing read only access to any patient record; please refer to the EPR Core (Read Only version of SystmOne) Standard Operating Procedure for more information. If staff only require read only access to patients being seen within a particular service, read only access to the relevant SystmOne unit(s) can be provided.

2.2. Procedure for Arranging Temporary Access to SystmOne

There may be situations where it is not possible for the standard access procedure to be followed, and it is necessary to arrange temporary access to SystmOne. Temporary access may be needed if agency cover is provided at short notice, or if it is not possible to book a staff member for appropriate training in advance of their requirement to use SystmOne. If a temporary member of staff is providing cover for one shift and it is uncertain whether they will be returning to SCFT for any further work, temporary access should be provided. If ongoing SystmOne access is required, the standard access procedure should be followed as soon as it is possible to arrange this.


http://thepulse/it/systmone/systmone-elearning.htm



Temporary access can also be provided if a member of staff has forgotten, lost or broken their smartcard. During office hours, a call should be logged via the Digital Service Desk for any smartcard or access issues. Depending on the situation, access to SystmOne will be provided as follows:

If the staff member has a smartcard and has completed appropriate training, the RA team will be able to update their smartcard profile with the relevant unit(s) access. An end date to the access should be set up at the outset, if known.

If the staff member has a smartcard but has not completed any training, the sponsor for the service will be required to confirm that adequate training and support will be provided by the service. The service-specific Standard Operating Procedure for using SystmOne should be provided for the temporary staff to refer to. The access will be removed at the end of the shift by the RA team, based on the information provided by the service.

If the staff member does not have a smartcard, a temporary access profile will be created to enable SystmOne access to the relevant unit(s). Please note, this will not provide access to mobile working, which requires a smartcard. The access will be removed at the end of the shift by the Application Support team.

For some services with high levels of short notice temporary staff, or providing care out of hours, the Temporary Access Process (Appendix 1) enables controlled provision of access to SystmOne which is managed within the service. Processes for managing temporary staff access at the time of booking and arrival at shift are shown in Appendix 2. For temporary staff members who have not been provided with the full training, the RA team / Application Support team will monitor their access requests and will only provide short notice temporary access up to 3 times. Temporary staff working repeatedly within SCFT will be required to attend the full training for ongoing access, or complete an appropriate e-learning course. 2.2.1 Additional Requirements for non SCFT staff Non SCFT staff are required to sign a confidentiality agreement before being provided with access to person identifiable information and / or information systems (Appendix 3). Confidentiality agreements must be logged and approved by the IG Team. These staff will also require access to the SCFT network to be able to log into a computer for using SystmOne. A call to the IT helpdesk is required to set up this access. Whenever possible, an individual network login should be created for each staff member. In exceptional circumstances however, it may be necessary for a generic login to be created for a service, e.g. if the service use unplanned agency staff out of hours on a regular basis. These are required to be set up in advance by



the service via a request to the Digital Service Desk and require a detailed justification for using generic logins.

2.3. Procedure for Arranging Student Access to SystmOne

Services within SCFT provide support for students from different courses and at different stages of learning. Students may require access to SystmOne to be able to update patient records; this will depend on the duration of their placement and whether they are required to see patients without direct supervision. Students who are on shorter placements, or will only be working under direct supervision, may not require a smartcard if they will only be accessing patient records in the presence of the mentoring clinician. 2.3.1 Pre-Registration Students Students who are expected to see patients without direct supervision will need to be able to write up their own records. The service needs to establish ahead of the placement if a student requires a smartcard (they may have one from a previous placement). Subsequently, the service sponsor must contact the Registration Authority (RA) with as much notice as possible to request the issue of a smartcard if required and access to the relevant unit(s). For pre-registration students the sponsor will be the Practice Education Facilitators (PEF) or delegated administration PEF team member. Training can also be requested if required; however, this is not an essential requirement, as the placement mentor / supervisor will be responsible for supervising and countersigning the student’s record entries – please refer to additional detail on countersigning in section 2.3.3. If the student does not attend the full training course, e-learning should be completed (where available) to provide an understanding of the SystmOne functionality which is used by the service. An appropriate e-learning course should be selected for the required service type as described in section 2.1.2. The student’s mentor will be responsible for showing the student this SOP in addition to the relevant service specific SystmOne SOP, and explaining the service processes for using SystmOne. If it is not possible for the student to complete e-learning, the mentor will be required to provide an overview of the system as well as the processes. RA will send the student a copy of the SCFT Confidentiality Agreement for them to read and sign; the smartcard will not be issued unless this has been completed. RA will send the signed Confidentiality Agreement to Information Governance. 2.3.2 Post-Registration Students Post-registration students are likely to have their own smartcards and some may already have experience of working within the service where they are on student placement.



For staff without the appropriate competencies for the service, the sponsor is responsible for completing the Training Request Form: https://servicedesk.scft.nhs.uk/support/catalog/items/204 The form should be used to indicate which SystmOne unit(s) the member of staff will require access to. A post-registration student has already achieved competency to complete records and should complete them in accordance with their professional standards and under mentor guidance / supervision. Countersigning is not necessary for these students. 2.3.3 Countersignature When the service sponsor requests a smartcard and / or smartcard profile change to arrange SystmOne access for the student, the request should indicate whether the student will require their record entries to be countersigned. RA will liaise with the Application Support Team to set this up. The countersignature functionality within SystmOne will trigger an automatic task each time the student saves an entry within a patient record, indicating that this entry requires countersigning. The sponsor will need to advise which staff member(s) are authorised to countersign entries for each student, for this to be set up. The named student mentor is the appropriate member of staff to be allocated as responsible for countersigning the entries of the student. The entries can be amended if required or countersigned to confirm that they are appropriate. 2.3.4 Student research Some students may need access to SystmOne for research purposes only. As they have no need to enter into the patient record they will need to be given read-only access. Please follow the process in 2.1.4 above.

2.4. Managing Patient Records without SystmOne Access

When a staff member does not have access to SystmOne, the service has responsibility for managing allocation, access to relevant patient information and updating the record on behalf of the staff member. 2.4.1 Allocation of work within SystmOne Different services will use different processes for allocation of work to staff members. Services that provide home visits will assign these to the relevant individual staff member’s visit list. If the member of staff does not have access to SystmOne, their visits should be assigned to a ‘dummy’ user. Bank staff and Agency staff dummy users are configured in each unit for this purpose.




Services that provide clinics may have appointment rotas which are not assigned to individual staff. Where it is necessary to assign the appointment rota to an individual staff member, dummy users will be provided. 2.4.2 Providing Access to Patient Information Required for Care Delivery In order for staff without SystmOne access to carry out patient care, it is advised that an appropriate summary is printed to enable the staff to access basic details about the patients they are responsible for, including recent consultations and problems. The information required will vary according to the service requirements. Some services may provide paperlight patient held records which will contain adequate information for staff to deliver care without requiring any additional printouts of the patient records. All printed documents must be kept secure and managed in accordance with the Health Record Keeping Policy. 2.4.3 Updating Patient Records on behalf of Staff without SystmOne Access The temporary staff member is responsible for keeping a record of the date, time and duration of each patient contact, and detail of the care which they have provided. The clinical content of the visit should be recorded on paper documentation e.g. progress notes sheets. Paper documentation must be managed in accordance with the SCFT Health Record Keeping Policy, including ensure patient identifiers (name, DoB, NHS Number) are on every side of paper documents. The co-ordinator / clinician in charge of the team which the temporary staff member is working for remains responsible for ensuring the patient record is updated within SystmOne. Information will need to be entered within templates to meet the needs of the service. This may be required for significant clinical details or in relation to key performance indicators. For services using care plans for planning and provision of care, it is essential that the care plan is performed within SystmOne. The date, time and duration of the clinical activity must be recorded for each patient, indicating that this has been done by the temporary staff member, with the entry in the record authorised by the clinician entering this information. Additional information which has been documented on paper by the temporary staff should be scanned in by administrative staff to be included as an attachment in the electronic patient record.

2.5. Removal of Access to SystmOne

If a member of staff is leaving the Trust or changing teams / role within the Trust, a call needs to be logged with the Digital Service Desk (Appendix 4) to inform them of the following details:

• Staff name • Name of current base • Name of SystmOne unit(s) they no longer require access to



• Changes required to caseloads, task groups and waiting lists Please note that the staff members Smartcard belongs to them, they do not have to hand it back. Through the call logged via the Digital Service Desk the Registration Authority (RA) will follow their guidance/procedure to remove access to SCFT units which is no longer required.

3. SMARTCARD USE

It is Trust policy that SystmOne is always accessed with the Smartcard as this makes record entries SPINE compliant. Please do not access SystmOne with username and password unless instructed to do so by the Registration Authority. Your Smartcard is your ID or = electronic signature in terms of SystmOne and you must always log in using your Smartcard. The Smartcard contains information about you, e.g. your name and professional registration number and your access rights. Access rights are linked to roles and determine what level of information you have access to and which functions you can complete in the system. The common roles are Health Professional Access Role and Admin/Clinical Support Access Role. Where requested by the service, appropriate staff will be given safeguarding access rights to allow them to access record entries saved as safeguarding relevant. Never share your Smartcard as you will be held accountable for all activities completed with the use of your Smartcard. Your Smartcard belongs to you and will move with you to other healthcare organisations. Access to different systems will be given and removed as necessary by RA. Never leave your Smartcard unattended. Loss or theft must be reported immediately to RA. The registration authority (RA) is responsible for the distribution and administration of Smartcards. Please find the team’s contact details and further information on how to apply, renew, unlock and report lost, stolen or damaged Smartcards on the Pulse under Digital > SystmOne > Smartcards http://thepulse.sussex.nhs.uk/it/smartcards/ It is recommended that staff sign up for Smartcard self service, allowing you to unlock your own Smartcard. Guidance on how to sign up for this is provided on the Pulse: https://servicedesk.scft.nhs.uk/support/solutions/articles/50000014263-how-to-sign-up-for-smartcard-self-service-allowing-you-to-unlock-your-own-smartcard Guidance is also provided to show how to unlock your Smartcard once you have signed up to Smartcard self service: https://servicedesk.scft.nhs.uk/support/solutions/articles/50000014333-how-to-unlock-your-own-smartcard-once-signed-up-to-smartcard-self-service Further information: QRG How to log into SystmOne QRG How to log out and unlock SystmOne QRG How to unlock a Smartcard

http://thepulse.sussex.nhs.uk/it/smartcards/

https://servicedesk.scft.nhs.uk/support/solutions/articles/50000014263-how-to-sign-up-for-smartcard-self-service-allowing-you-to-unlock-your-own-smartcard

https://servicedesk.scft.nhs.uk/support/solutions/articles/50000014263-how-to-sign-up-for-smartcard-self-service-allowing-you-to-unlock-your-own-smartcard

https://servicedesk.scft.nhs.uk/support/solutions/articles/50000014333-how-to-unlock-your-own-smartcard-once-signed-up-to-smartcard-self-service

https://servicedesk.scft.nhs.uk/support/solutions/articles/50000014333-how-to-unlock-your-own-smartcard-once-signed-up-to-smartcard-self-service



4. RECORD KEEPING

All clinical information should be documented appropriately as part of the patient record in accordance with the SCFT Health Record Keeping Trust Policy. To ensure the required consistent structure in the record, it is important to record key information such as alerts and reminders, medications, sensitivities and allergies in the appropriate section. Please refer to sections 16 (Medications, Sensitivities and Allergies) and 17 (Alerts and Reminders) for further information. All users of the digital patient record are responsible for maintaining accuracy of the record. If you see information which has been documented incorrectly, it is important to amend it / mark it in error / request mark in error (see section 14: How to Manage an Incorrect Entry in the Patient Record).

SystmOne record is a shared record and all users must take responsibility for up-to-date and correct information.

4.1. Requesting changes

It is possible to change most of the configuration of SystmOne units, particularly templates, questionnaires and care plans. SCFT uses a defined change process (See Appendix 5: Requesting changes to SystmOne). Changes need to be agreed across the service. In some cases agreement is required across services where the same template / questionnaire / care plan is used, e.g. Holistic Assessment template. The Champion User Group is recommended as a forum to discuss service needs and changes.

4.2. Use of abbreviations

The trust’s approved list of abbreviations can be used. However, users outside of SCFT who have access to records due to sharing will not have access to the list. Therefore it is best practice to use the full term with abbreviation in brackets when first used for each record entry.

4.3. Tracking paper notes

In line with the Trust’s Health Record Keeping Policy, the Notes Tracker template must be completed every time the record moves base within the trust. NB: children’s paper records moving out of the trust must be processed by CCHIS. For further information see Health Record Keeping Policy.

4.4. Subject Access Requests

Patients or persons acting on behalf of the patient may ask for a copy of the health record. This constitutes a Subject Access Request and must be answered within 30 days (1 Month). The IG Team will co-ordinate the request and must be contacted within 48hrs of receipt of the request.

http://thepulse.sussex.nhs.uk/downloads/trustwide-policies-procedures/governance/health-record-keeping.pdf



For detailed information on the process of creating a Subject Access Request in S1 please see QRG Subject Access Request Guide.

5. ACCESSING RECORDS

5.1. Invalid NHS number message: adoption, gender reassignment, protection of identity

This message appears when a patient has been given a new NHS number, e.g. following adoption, gender reassignment, or protection of identity. This record should not be added to – specifically the new name / new gender must not be recorded. Please open the record and end the referral with Intervention “Record no longer valid”. Following the closure of the old record, the new record needs to be registered (see 4.7). Please make sure you have the correct spelling of the new name.

5.2. Adoption

The record keeping processes for adoption are described in the SCFT Procedure for Adoption & NHS Number Change – Electronic Record Keeping (SystmOne). For further guidance, e.g. if the new record cannot be found when searching for registration, contact CCHIS or the Looked After Children team.

5.3. Gender reassignment

Patients may request to change gender on their patient record at any time without undergoing gender reassignment treatment by informing their GP practice that they wish to change gender. The GP practice will request a new NHS number.

5.4. Accessing the record of a discharged patient

There may be occasions when it is necessary to access the record of a patient who is no longer receiving care from the service. You may be required to record your reason for accessing the record, depending on how long ago the patient was discharged.



Attempting to access the record of a discharged patient will trigger a warning message to your Privacy Officer (usually a service lead) and an audit trail of every attempted access will remain in the system.

6. REGISTERING A RECORD TO THE UNIT

Patients not already registered within your SystmOne unit and not referred to you within the system (via electronic referral) will need to be registered into the unit via the Registration screen. If a referral is received outside of SystmOne, search for the patient (with the option ticked to ‘include deducted patients’) to access the record if the patient has ever been registered for care in your SystmOne unit. If you locate the patient you can re-register them for care and add a new referral. If the search yields no results, the patient will need to be registered in the unit before adding a referral.

Please check spellings of names when searching for clients. Particularly names originating in a different script (Arabic, Chinese, Cyrillic, etc.) may have been given different spellings at different healthcare organisations. GPs request the creation of the NHS number following registration, so it’s worth checking that you have the same spelling of the name as the GP. All patients who are registered with a GP in England, Wales and the Isle of Man will have an NHS number and therefore should be found when searching the SPINE during the registration process. NB: patients from Scotland, Northern Ireland, the Channel Islands and countries outside the UK do not have an NHS Number unless they have previously registered with a GP in England, Wales or the Isle of Man.

If a patient is not found on the SPINE, then further investigation must be done e.g. contact GP or referrer to check details. See section 6.1 below for the process of registering patients without NHS number.

6.1. Records without NHS number

When you are certain that a patient does not have an NHS number, e.g. they are new to the country / have never registered with a GP / were not born in England, Wales or the Isle of Man, a local (non-NHS number) record can be created. Local records do not communicate with the SPINE and you will not be notified of changes to the patient’s demographic details, e.g. address, that have been entered by other organisations into the S1 record.



Encourage the patient to register with a GP as this will trigger the creation of an NHS number. Advise the patient to use the same demographic details (name spelling) at GP registration. A local record is created when the following message pops up on the Register page:

6.1.1 Local records process for adult services

1. Double check patient details (NHS number, spelling of name, DoB); if

necessary check patient details with patient / on Open Exeter / with GP if known

2. Once you know that entered details are correct, click Register New Patient. You are now creating a local record without NHS number.

3. Add reminder in record to highlight this is a local record 4. Follow up with patient if they have registered with GP 5. Following GP registration, check S1 database as above to see if NHS number

has been allocated (it can take several weeks from GP registration to NHS number allocation)

6. Contact the IT Helpdesk (see Appendix 4) as soon as the NHS number becomes available to request the merger of the local record with the NHS number record.

6.1.2 Local records process for children’s services CCHIS will create a local record if the child needs to be seen before the NHS number has been allocated.

1. Double check patient details (spelling of name, DoB) 2. Check patient details with parent / on Open Exeter / with GP if known 3. If entered details are correct, abort registration by closing the window and

contact CCHIS via their generic email address [email protected] providing all the available details to enable them to create a local record

4. Follow up with parent if they have registered their child with GP (this triggers the allocation of NHS number)

5. CCHIS will let you know when the patient has been allocated an NHS number and will merge the local record with the NHS number record.

Further information: QRG How to register a patient and record a referral in

mailto:[email protected]



6.2. Receiving referrals

Referrals are usually processed by administrators. In the absence of admin staff, clinicians are expected to process referrals to allow for timely record keeping. If the referral is not received via a SystmOne task it will be necessary to register the patient into the unit. The NHS number must be used as the patient identifier if available. Alternatively, the minimum dataset required for registration is patient’s full name, DoB and address. All patients who are registered with a GP should have an NHS number and therefore should be found when searched.

6.3. Paper and email referrals

The original referral form must be attached to the record following the registration process. Email: attach to record in Attachments and complete Contact Tracker template Word file: attach in Communications & Letters Paper: Scan this via Document Management, ensuring you select the required ‘Letter Type’ from the list available to ensure ease of filing later on. See section 11 Document Management for information on how to attach paper referrals.

6.4. Electronic referrals

Referrals within SystmOne may come through as unassigned tasks or may be assigned to a group (see section 15 Management of Tasks in SystmOne).

Actioning the electronic referral task prompts the user to complete the referral process into the SystmOne unit by completing the Referral In screen accordingly (see service-specific SOP).

Following the completion of the referral, you can task users and update the patient record as required to notify of new referral and action required.

7. RECORDING AND UPDATING DEMOGRAPHICS

Patient addresses and other contact details are a crucial element in the care of patients. Accurate patient addresses are also required for the NHS charging mechanisms to function correctly.

SystmOne communicates with the national demographics service also known as the SPINE to maintain patient details. This means that a user of any electronic health record can update patient details, e.g. change of name or new address, and you will be asked to verify the details when you open the record. NB: only users with patient contact are expected to verify changes, this includes admin having telephone contact with patients.



All SPINE users share the responsibility to keep patient details up-to-date. You can change the details by going into Patient details in the Administrative tree in the record.

If a patient is concerned about sharing their address details across SystmOne or other digital health record systems (via the SPINE), e.g. due to having experienced domestic abuse, they can request that their details remain hidden on the record through their GP (see section 8: Managing Sensitive Demographics).

Following this guidance will ensure that there is always clarity about the current address(es) for patients. This is particularly important where patients have more than one address e.g. patients in care homes or in hospital, children who split their time between two parents, Children in Care or adopted children patients in a refuge, students, patients on holiday, unaccompanied child asylum seekers etc.

Potentially serious problems can be caused as a result of having an out of date or inappropriate address for a patient e.g. letters may not be received or they may be sent to someone who should not receive them. Particular care needs to be taken with children whose parents do not live together; Looked after Children; patients living in a refuge; for a person on holiday or staying with a relative etc.

As well as our duty of care to patients to ensure that addresses are accurate, we are legally required by the Data Protection Act’s 4th principle to ensure that data is accurate and up to date. It is the responsibility of all staff to ensure that patient demographics are up to date and not just an administrative job to be left to support staff.

7.1. Address types

Situation Address type Procedure/rule to follow

Patient moves from one permanent address to another

Permanent address

Follow the standard S1 procedure to update the patient’s permanent address (Administrative | Address history | Record new address | Home).

Patient moves into a temporary accommodation; eg. Respite care in residential or nursing home, holiday address.

Temporary address

Follow the standard S1 procedure to record a new temporary address (Administrative | Address history | Record new address | Temporary).

Confirm with patient whether the temporary address is to be used for correspondence, if so, tick the box to ‘Use this address for correspondence’.

Tick the box to ‘Use this address in the patient search’. The temporary address will then be shown in the demographics box.

Patient does not have a permanent address eg. homeless or

Home (no fixed abode)

Follow the standard S1 procedure to set the patient’s address to indicate that they have no fixed abode (Administrative |




traveller Address history | Record new address | Home (No fixed abode))

Record the person’s current location as a temporary address.

Patient is a student whose home is elsewhere.

Student at term-time address

NHS guidance is that the student can nominate either their home address or their university address as their permanent address with the other address being their temporary address.

Once the permanent and temporary addresses have been given by the student, follow the standard S1 procedures for permanent addresses and/or temporary addresses (see above).

A patient who is not “ordinarily resident” in the UK is defined as an overseas visitor.

Permanent address: overseas

Temporary address: this country

Follow standard S1 procedures described above for recording these address types.

An overseas address is recorded as follows: start recording an address in the normal way but do not enter a postcode. Click the “Find” button. S1 will ask you “Are you sure you don’t have a postcode?”. Answer “yes” then select the “International Address” tab. Select the country from the drop-down list and enter the rest of the address in that country as normal. A “pseudo-postcode” will be recorded for that country.

The patient is admitted to an inpatient facility.

Temporary address

If the patient requires visits from the community teams whilst they are an inpatient, follow the standard S1 procedure as above to record a temporary address.

Do not amend the permanent or other addresses.

Community teams involved in care should add a reminder to indicate the patient is in hospital (refer to Alerts and Reminders Standard Operating Procedure).

The patient’s address is not known

Permanent address

If the address is unknown and cannot be identified, it is important to record the address as unknown rather than recording nothing as this demonstrates that attempts have been made to identify the patient’s address.




To do this, follow the standard S1 procedure to update the patient’s permanent address (Administrative | Address history | Record new address | Home) and enter the “pseudo-postcode” “ZZ99 3WZ”. S1 will tell you that it does not recognise this postcode and will bring up the normal screen to record a UK address. Put “Unknown address” in the “House name” box, the “Road” box and the “Town” box.

The patient moves out of a temporary address

Temporary address

Follow the standard S1 procedure to end an active temporary address (Administrative | Address history | click “Remove” against the temporary address). The temporary address will be retained in the address history but will not be displayed in the ‘current addresses’ screen.

Person is vulnerable and requires access to their location to be restricted.

Permanent or temporary address but needs to be flagged as a sensitive address

Inform the service manager. Do not register the patient. Service manager to refer to Managing Sensitive Demographics Standard Operating Procedure to request that the record is flagged as sensitive.

Patient (or carer) requests that correspondence is sent to an alternative address.

Correspondence only address

Follow the standard S1 procedure to record a correspondence address (Administrative | Address history | Record new address | Correspondence only).

If the patient tells you that the correspondence address will only be used until a certain date, you can enter that date by clicking “Record end date” and selecting the required date. S1 will stop using the correspondence address when the end date is reached.

The patient (or carer) requests that the correspondence address is no longer used.

Correspondence only address

Follow the standard S1 procedure to end an active correspondence address (Administrative | Address history | click “Remove” against the correspondence address) The correspondence address will be retained in the address history but will not be displayed in the ‘current addresses’ screen.



7.2. Key safe numbers

Key safe numbers must never be recorded as part of the address itself as this could lead to them being disclosed e.g. when a letter is printed and inserted into a windowed envelope. Key safe numbers should be recorded as a reminder on the record (see section 17: Alerts and Reminders) as K XXXX. The same applies to any other instructions re access e.g. “key with neighbour” etc.

7.3. Phone numbers

S1 allows you to record one or more of a mobile number; a home phone number; a work number; an alternate number; and a temporary number.

One of the recorded phone numbers should be designated as being the preferred contact number; this is done by clicking the “preferred contact” box beneath the phone number.

Landline numbers must be recorded in full i.e. including area code e.g. “01273”. (S1 will not accept a phone number without the area code.)

You can record an extension number after the main number by typing an “x” then the extension number.

Overseas phone numbers must include the country code preceded by “+” to indicate that the international dialling prefix is required e.g. “+33” for France etc. Do not include the leading zero e.g. “+33 123456789” rather than “+33 0123456789”

If a mobile number (07* / +447*) is provided, consent for SMS text messages to be sent must be requested from the patient. Record consent or dissent accordingly by ticking the box above the mobile number.

If a number is stated as being ex-directory then you should record this in the comments box alongside the phone number.

7.4. Email addresses

An email address for the patient can be recorded within the S1 record. A verification email should be sent prior to using the email address for any other correspondence. Your SystmOne unit will need to be configured to link with the appropriate shared service email address to send the email from; please log a call with the IT helpdesk if this has not been set up. For further details on policy and procedure of the use of email to contact patients please refer to the Health Record Keeping Policy.

7.5. Ethnicity and language

Record ethnicity in the patient details node using the 2011 census categories. Main spoken language / Main communication method: To alert all users to the need for booking an interpreter, please set a High Priority Reminder indicating the language required (see section 17.2 Reminders).

http://thepulse/downloads/trustwide-policies-procedures/governance/health-record-keeping.pdf



7.6. Gender-inclusive pronoun

Gender-inclusive pronouns, e.g. they; per; ze; zie; xe; ve can be entered into the “Known as” field as follows: Pronoun They. The pronoun will be displayed in the Demographics field following the name:

8. SENSITIVE RECORDS

There are some situations where it is necessary to protect patients’ identity, for example to protect the location of patients who are at risk of domestic abuse.

The Government has determined that the PDS (SPINE) is the authoritative source of NHS demographic information. NHS patients have no specific legal right to prevent demographic data being stored on the Personal Demographics Service (PDS). The NHS cannot comply with requests for data not to be held on the PDS; the information is required to ensure the record of one patient is not mixed with another, to enable contact with patients and for legal reasons (NHS Digital 2019).

Although demographic data must be held, there are cases where access to a patient’s details must be strictly controlled, for example adoptions, gender reassignment, or other vulnerable patients.

The patient is responsible for the decision about whether access is restricted, but they should be informed and guided by their GP, who can request that the PDS National Back Office (NBO) mark the record as sensitive and thus restrict access.

This prevents users of the PDS from accessing the address, registered GP practice and registered or preferred pharmacy. A flagged record also means that healthcare professionals will be unable to access the patient’s most up-to-date address and contact details held on the Personal Demographics Service. The data returned from PDS will only show the NHS number.

Even though a record is flagged the NHS will still hold demographic information on the patient. The information is still accessible to the PDS NBO and although it is hidden on the electronic patient record, it is possible to authorise staff to view the information with the smartcard access right for this.

8.1. How to Mark a Record as Sensitive

When the patient requests that they want their record to be marked as sensitive, a conversation needs to take place with the patient to:



Confirm that they understand it is their demographic information that is hidden if the record is flagged as sensitive. Explain that if it is clinical information within the record which they want to restrict access to, a sensitive flag is not appropriate.

Request they elaborate why they wish for their record to be marked as sensitive, as this may help decide the best course of action. E.g. does a family member or a friend work for the Trust? If so, explain that due to the way in which the systems and processes work to ensure clinical continuity, it will be difficult to keep this information private and do they wish to be seen in another service

Ensure that they understand the implications of this with regards to communicating with different professionals, e.g. if the patient is referred to another service, that service will not have access to the address. Replies to referrals or invitations to appointments will need to be sent via the GP for the GP to forward to the patient.

Advise the patient that they need to speak with their GP, who can make the request to the PDS NBO to flag their record as sensitive.

NHS Digital guidance for patients (NHS Digital 2019) can be provided to help explain the purpose and consequences of restricting access to their demographic details.

A medium priority reminder should be placed on the patient record to indicate to all SCFT staff accessing the record that the patient is intending to request their demographic details are flagged as sensitive.

8.2. Patient's Demographic Details Not Current: Patient Choice to Avoid Disclosure

If the patient's demographic details on SystmOne are not their current demographic details, this creates difficulties in provision of care. If the patient has moved into an address that they would like to be flagged as sensitive, but they have not yet spoken with their GP to request this, updating their address on the record will allow all PDS users to view this information.

Discuss sensitive records as described in section 8.1. If the patient requests that their new address is flagged as sensitive, advise them to speak with their GP to request this.

Explain to the patient that leaving their previous details on the record means there is a risk that correspondence will be sent to the wrong place, which could result in inappropriate disclosure of clinical information. Discuss with the patient as to whether they would prefer:

a) The record be updated with an address of ‘unknown’ (Quick Reference Guide

on Pulse showing how to do this) and the GP address be recorded as the correspondence address.



b) The record to be updated with their new address. Ensure that the patient understands the implications of their decision:

a) Until they have spoken with their GP to resolve this, any correspondence, appointment letters etc will be sent to their GP.

b) Their new address will be available to all PDS users until the patient has spoken with their GP to update this.

8.3. Access to Demographic Information which has been Flagged as Sensitive

It will be necessary for some staff to be aware of demographic details of patients which have been flagged as sensitive, for example if the patient requires the member of staff to visit them at home.

A smartcard access right enables viewing of sensitive records. This access is not given to any staff members as a baseline role. It will be necessary for individual members of staff within a service to have this access to be able to manage the care for these patients. The appropriate sponsor should request this as an additional access right for the members of their team / service requiring this. Without the relevant access right, it is not possible to register the patient or to update the following information on the record:

o Registered and usual GPs o Addresses o Telephone numbers o Relationships o Treatment centres o Letters o Email addresses

8.4. Removing the Sensitive Flag

If a patient requests that the sensitive flag on their record should be removed, they should be advised to speak with their GP, who is able to authorise this by requesting the PDS NBO to remove the flag.

9. CASELOAD MANAGEMENT

Patients are added to a caseload at the point of referral. A patient can only appear on one caseload per referral. All referrals must be actioned and records assigned to a caseload to allow for reporting to be correct.

9.1. Recent registrations

This caseload shows patients who have been registered at this unit within the last 90 days without having a referral actioned. There should not be any records in this



caseload. Any records found in Recent registrations must be opened and actioned accordingly.

9.2. Unassigned referrals

This caseload shows records which have had the referral actioned but have not been allocated a caseload. This caseload must be monitored and if you see a patient in here please open the record and action accordingly. Further information: QRG How to retrieve and Reassign a Patient to a Caseload QRG How to view and Retrieve a Patient Assigned to a Caseload QRG How to Download a Caseload (Mobile Working)

10. RECORDING RELATIONSHIPS

All clinicians working with a patient’s record are responsible for ensuring that relationships are up-to-date. This is particularly important with regards to safeguarding. It is important to end relationships when it is known that a relationship status has changed, for professionals involved or family members.

In a shared record, relationships entered by other services / organisations will be visible. Each relationship should only be added once to avoid confusion.

10.1. Viewing relationships

Tick Show ended relationships to view further relationships which were previously entered.

10.2. Amending / ending relationships

All relationships entered in your unit can be amended / ended by users of your unit. It is not possible to end Relationships which were created in other units; if the relationship is no longer current, this will need to be communicated to the unit who entered the information by requesting this is ‘Marked in error’. This generates an unassigned task with your specified request to the unit where the information was recorded (see section 15.6: Managing Mark in Error Tasks for further information).

All relationships entered by your service must be ended when ending the referral as subsequent services will be unable to end / amend the relationship created in your unit (see section 20.2 Ending reminders and relationships).

10.3. Reciprocal relationships

Relationships with family members whose records are also open in your unit can be set up as reciprocal. This means that the 2 records interact with each other, i.e. when you update an address or contact number in one record, you will be asked if you would like to update any related records and the system will be able to identify records linked through reciprocal relationships.

NB: the system does not automatically update the addresses logged in the relationship node.



10.4. Blended families / adopted siblings

It is possible to record a more complex relationship and provide detail that ensures the record is up to date. For example if a child has older siblings who have been adopted or not living at the same address you can add as a ‘textual relationship’. Leave the address blank or make a judgement if address can be disclosed in the record, remember this is the patient’s record and they can ask to see it in the future.

Use the notes field to add detail of the relationship e.g. sibling adopted, living elsewhere. Please see Standard Operating Procedure for Adoption & NHS Number Change (Children) – Electronic Record Keeping (SystmOne) for further information.

10.5. Deceased family members

If a parent or other family member recorded in Groups & Relationships has died, please end the current relationship and add a new relationship without an address. Add a comment e.g. Died. This ensures that a letter will not be sent out in error or the name of the deceased used in communication.

10.6. Professional relationships

Professional relationships should be marked as “Proxy”.

10.7. Creating relationships with students

Please state your role e.g. Student OT in the comments box when recording the relationship as it is not possible to indicate student status otherwise.

10.8. Informing the named clinician of the registration

When you have set up a new relationship with someone within your organisation, S1 will ask you if you want to send a task to the person informing them of this relationship. If this task is not required then click no. Further information: QRG How to add a health care professional relationship QRG How to add a reciprocal relationship QRG How to add a textual relationship QRG How to view amend and end a relationship

11. DOCUMENT MANAGEMENT

The Communications and Letters node within the record is the place where all correspondence which you have sent or received about the patient should be stored. The only exception to this is the attachment of emails and photos, which are attached via Record Attachments. Using the Communications and Letters node enables you to record the relevant information to show who the correspondence is from and to, so you are able to see what information has been shared, who with, and when.



11.1. Creating letters for print or email

All communications regarding individual patients are generated from the node Communications and Letters. These can be created as hard copies (letters) or sent electronically as emails. Thus, all correspondence is automatically logged in the record in chronological order and can be searched. All standard letters requested by your service will be available as templates. Letters can be edited as needed and can be Saved for Future Editing.

NB: Once you have saved a letter as Final Version, you will not have access to previous versions saved as Save For Future Editing, i.e. there is no version control.

IG requirement: All email communication should take place between nhs.net or gov.uk addresses to allow for secure transmission of confidential patient data with services provided by the local authority. If you would like to request a new letter or changes to existing letters, please see Appendix 5 for how to request changes to SystmOne.

11.2. Attaching emails and photos to the record

The record attachments section is for attaching emails and photos only. All other correspondence must be attached in the Communications and Letters section.

11.3. Referrals to other SCFT services / S1 organisations

Referrals to SCFT services and other healthcare organisations using S1: send New Electronic Referral. This will ensure that the referral is a part of the patient record. Acceptance of the electronic referral automatically registers the patient to the new unit. 11.3.1 Record sharing requirements for referrals

Following the completion of the New Electronic Referral screen, a pop-up will appear asking you to set sharing settings for the receiving service to be able to view the shared record (see section 12 for further information about sharing records).

For a referral to another SCFT service you can cancel the sharing setting screen as all SCFT units will be able to view the full SCFT record due to Adult Services / Children’s Services sharing groups, unless you are referring from a children’s service to an adult service.

NB: If another SCFT service using SystmOne is already involved in the patient’s care, a task should be sent instead of a new electronic referral if possible.

11.4. Referrals to organisations not using S1

Create a New Word Referral from Communications & Letters, using the appropriate letter template. The letter can be printed or sent as an email to a secure nhs.net / brighton-hove.gov.uk / gcsx.gov.uk address by choosing Email on the task bar. If you



want to print out, choose Save Final Version. S1 takes you back to the Communications & Letters screen. Right-click on the correct letter and choose Print. Further Information: QRG How to send an electronic referral QRG How to create a letter from the patient record

12. CONSENT FOR SHARING RECORDS

One of the advantages of electronic record systems is the ability to share the patient record across services and healthcare organisations. In electronic systems, records are no longer owned by an organisation (e.g. the “GP record”). The electronic record is the patient’s record (although this does not give the patient access rights to their full electronic record, see section 4.4 for Subject Access Requests). It is the patient’s right to make decisions about sharing their record. Not asking the patient and not setting consent does not allow the patient to make a choice. Records are not shared when consent has not been set. Patients should be asked about consent for sharing during the first contact (ideally face-to-face) and should be offered the leaflet “Patient information and how we use it”. For further information see the leaflet “Guidance for staff - Informing patients how we use their Information” and the Health Record Keeping Policy. Sharing consent can be decided on behalf of the patient in certain situations, e.g. safeguarding, mental capacity. Please seek further advice from the relevant safeguarding leads. For extensive information on sharing, including how to discuss sharing with patients, see QRG Clinician’s guide to consent for record sharing in SystmOne FAQs.

12.1. Organisation Sharing Groups

Records are shared across SCFT adults’ services in the Adult Organisation Sharing Group and across children’s services in the Children Organisation Sharing Group. This means that another SCFT service will be able to view all information entered by your service and is particularly useful when referring a patient on. Staff should inform patients of the shared SCFT record. In the case that a patient would prefer not to share their record across SCFT services, please contact IG for advice.

12.2. GP Verification of Record Sharing

Following intervention from the Information Commissioner’s Office, GP’s are able to control organisation sharing of the patient’s record. If the patient’s GP uses SystmOne and has not included your service SystmOne unit as ‘allowed’ to view shared records, you will require verification to be able to set the consent to view information (Share In) from other organisations even if the patient has agreed to this.



SCFT is working closely with local GP surgeries to add all our S1 units to their Allowed list (see below). Each SystmOne GP Practice can define 3 lists: Allowed: SCFT S1 unit is free to set the patient’s Sharing In preferences Prohibited: SCFT S1 unit is blocked by the GP from being able to set the Share In preference to view the shared patient record. Require Verification: additional verification is required to set the ‘Share In’ preference. A window will pop up alerting you that verification is required when you try to set consent to Sharing In – Consent given. If you click ok, an SMS or (if no mobile number available) an email will be sent to the patient. The message will contain a verification code which needs to be entered by you. Please check the mobile number and email details before allowing the verification code to be sent, to avoid sending a message to an inappropriate / out of date contact, disclosing the patient name and service being provided. Please note that the system will not use a mobile number or email address entered by SCFT to avoid manipulation. If necessary, please ask the patient to update their details with the GP before attempting verification. SCFT is working with GPs to avoid verification needing to happen.

12.3. Sharing Preferences template

The Adult Information Sharing Consent template and the 0-19 / Child Information Sharing Consent template are designed for documenting discussions relating to sharing of information and sharing of health records. This should be completed at initial assessment / first clinical contact. IG advises that there is no requirement to obtain signed consent from patients. Record Sharing screen: the option “Consent not asked” in either Sharing Out or Sharing In prompts you to make a decision on the patient’s behalf. Patients can ask for their sharing preferences to be changed at any time (see QRG below). As record sharing consent is vital to providing joined up care, regular reports are provided to ensure that the patient’s record sharing preferences are being recorded. Further information: QRG How to view and amend a patient’s record sharing consent QRG Clinician’s guide to consent for record sharing in SystmOne FAQs

12.4. Mental Capacity

The mental capacity assessment is accessible from the first tab of the Adult Information Sharing Consent template. If the patient is unable make consent decisions, tab 2 does not need to be completed.



12.5. Marking record entries as Private or Safeguarding Relevant

In addition to sharing the record as a whole, when saving each record entry you need to indicate how this individual event is shared. The default is ‘Normal’ visibility; this means the record entry is shared as determined by the sharing preferences. Two further options are ‘Private’ and ‘Safeguarding Relevant’: Marking an entry as Private: this allows the patient to opt out of record sharing with other organisations for this record entry only. The entry will be visible across the whole of the SCFT organisation sharing group, but will not be visible to non-SCFT services (e.g. GPs using SystmOne) even if the overall sharing preference on the record is set to share out. Marking an entry as Safeguarding Relevant: this ensures that any safeguarding concerns are shared with staff with appropriate access rights across all services and organisations that are sharing this S1 record. Please see section 18: Recording Safeguarding Concerns and specifically 18.4 Marking an entry as Safeguarding Relevant for further guidance. 12.5.1 Amending the visibility of record entries

Visibility of saved record entries can be changed: In the tabbed journal, right-click on the event heading at the very top of the record entry, and choose Part of Shared Record, Mark Event as Private or Safeguarding Relevant.

13. PATIENT CONTACT

13.1. Preparing for a patient contact without mobile working

Services using Appointments: an appointment list can be printed from the rota. Services using Visits: A visit list can be printed from the monthly planner screen if staff do not have access to Mobile Working. Printed copies of documentation will be required, so that information can be recorded whilst with the patient. Guidance from Information Governance:

Due to the confidential nature of the information contained, you are expected to handle these lists and templates carefully, using a secure folder for transporting these documents. Please remember that appointment lists and templates contain client-identifiable information and must be disposed of in confidential waste as soon as the electronic record is updated following your visit. They should be printed on yellow paper to ensure they are more visible and less likely to be lost.

13.2. Preparing for a patient contact using mobile working

Each time you open SystmOne mobile, the programme needs to download and exchange data. As this may take 5-10 minutes, it is recommended that you open the software with time to spare before you need to visit patients. You don’t have to be in the office or on the Sussex network to open mobile, all you need is a WiFi or a 3G Vodafone connection. Mobile will download patient records for the patients booked



on your visit list for 7 days, and the records will remain accessible in mobile for 1 week. You can search for and download records into the mobile app at any point as long as

you are online .

13.3. Recording a patient contact (desktop and mobile)

In SystmOne desktop version: Open record from visit list via Consultation; this means that the event is automatically recorded as a face to face and clinically relevant contact. In Mobile Working the patient record is accessed from the visit list; all events recorded in mobile working are clinically relevant and face to face without needing to document this. Information is documented in the patient record using care plans, templates and questionnaires. To enable accurate reporting it is essential that all patient contacts are recorded in the relevant template/care plan/questionnaire under the appropriate read code.

13.4. Care plans

For those services who work with care plans to schedule care delivery, e.g. Community Nursing teams, these are an essential part of managing visits in S1. Care plan frequency sets the visit frequency (see service-specific SOP). Care plans are also relevant for other services for defining the care input required.

Care plans contain a list of instructions; these define the plan for safe and appropriate delivery of care. To perform the care plan it is necessary to tick the relevant instructions indicating the care provided. Any variation (i.e. if care is not delivered as plan) should be documented within the record as an exception; this should not be defined within the care plan instructions as being the plan of how to provide care.

Care plans must be edited to reflect the individual patient’s needs. Instructions can be added, amended or deleted as required. Record the activity type (e.g. assessment / clinical intervention) and duration (time spent in minutes performing the care).

Further information: QRG How to Add a Note to a Care Plan QRG How to amend Care Plan Frequency QRG How to Apply a Care Plan from a Template QRG How to Complete a Care Plan QRG How to Manage Care Plan Instructions QRG How to Perform a Care Plan (Mobile Working)

13.5. Templates

Templates are for documenting information within the record; this is the format most widely used for recording assessments. Every field – tick box, free text box and multiple choice box – on a template is attached to a read code, enabling the analysis of records through reports. Some of the read codes are used for reporting on KPIs



for commissioners. Read codes also allow record entries to be pulled through to letters generated in SystmOne and enable you to view data trends. When entering information into a template, previous entries under the same read code are displayed if “Show recording from other templates” (in the desktop system) / ‘Show previous values’ (in mobile working) is ticked. This applies to every read code used in a record, for example a nurse from responsive services will be able to see the community nursing entry into the read code Social and personal history. It is an individual staff member choice to tick or untick the option to view previous values within the open template. If it is ticked so these are included, the readings which are associated with the same code but entered into the record using different templates show as grey rather than black text. It is important to be aware that if the previous values are grey they may relate to a different value than that used within the template which you are using; the code may have been used with a different meaning in a different context. Templates have been created to allow for the recording of service-specific assessments. The use of generic templates such as Progress notes and SOAP should be limited to general updates on the patient. Templates have been designed to allow for the recording of all information which may need to be gathered during a specific assessment. There are different options for recording information to enable a full clinical record to be documented, without omitting any essential aspects of an assessment. The configuration is designed to allow for you to document the required information to evidence your assessment, clinical decisions and actions taken. It is not always appropriate to enter information into every available field within a template. Where it is necessary to document assessment information, free text fields are generally provided within the templates to be able to type in as needed. You can use these fields to indicate your assessment or incomplete assessment with plans to assess on a future date. Your assessment may indicate that there are no problems; it is appropriate to document that you have made this assessment and to make it clear within the record that there are no problems. Leaving a free text field blank will indicate that you have not assessed this aspect of the patient’s condition or situation. Where it is necessary to record specific details, for example health problems or diagnoses which a patient may have, there are usually tick box fields for adding this information. These fields must be left blank when they’re not applicable for the patient. Ticking these boxes will code each problem or diagnosis into the patient record, providing misleading information indicating that the patient actually has these conditions. Although problems / conditions are usually tick box fields, there may be occasions where it has been necessary to provide a free text field for entering information. Past medical history is an example of this – documenting ‘none’ will add a code to the record of ‘Past medical history’ without any meaningful data. It may be appropriate to document elsewhere in your assessment that there is no previous history (e.g. in a ‘Presenting complaint’ field you could state this is a new condition



with no previous medical history, or you could include this detail in a field for providing a ‘Summary’ or ‘Assessment of needs’). Alternatively you may need to include as part of your ‘Plan’ for the patient that you will contact the GP surgery for details of the past medical history as this information isn’t currently available. There may be other situations when it is appropriate to be completing some information within a template but not assessing everything within that template. In this type of situation the irrelevant sections should be left blank. NB: There is a limited choice of read codes available in SystmOne, which is why the language used often sounds very different to the professional language you are used to. The most clinically appropriate available codes are used. 13.5.1 Contact Tracker template This template is available for all SCFT services using SystmOne. It facilitates recording of email, phone and face-to-face communication with the patient and with other professionals. Further information: QRG How to Apply a Care Plan from a Template QRG How to Complete a Clinical Template (Mobile Working) QRG How to Complete a Data Entry Template QRG How to Copy Previous Template Values

13.6. Questionnaires

The fields within a questionnaire can be configured without linking to read codes, so questionnaires are created when it is not necessary or possible to read code the information which needs to be entered into the patient record. Data entered into questionnaires can pull through to letters and reports. Questionnaires do not display in detail on the tabbed journal. The completed questionnaire can be accessed by right-clicking on the entry in the tabbed journal. If there is a reporting requirement related to a questionnaire, it is possible that one or more of the fields will be linked to a read code. In this situation, when the final version of the questionnaire is saved in the patient record there will be a prompt question to confirm that these codes will be added to the record. If a field has been completed which is linked with a read code, it will always be necessary to add this code to the patient record, so it is essential that the prompt message is responded to appropriately. Further information: QRG How to Complete a Questionnaire

14. HOW TO MANAGE AN INCORRECT ENTRY IN THE PATIENT RECORD

The accuracy of patient records is essential in ensuring safe clinical decision making, as well as being a requirement of the data protection principles as described in the



Health Record Keeping Policy and Records Management Code of Practice for Health and Social Care (IGA 2016).

It is acknowledged in professional guidance that there are occasions when amendments need to be made in patient records; immediate action should be taken when inaccurate information is found (NMC 2015), and the original entry should still be clearly visible with the amendment (CSP 2015).

14.1. Amending the Record

Where it is appropriate to do so, incorrect information in the record should be amended by the clinician who entered this or who has identified the error. Amendments can be made to correct the date and time of an event, the location (e.g. clinic or patient home) and the consultation method (e.g. face to face or telephone).

Amendments in the record are flagged and visible to all staff accessing the record. Details of the date and time and member of staff are clearly shown for both the original entry and the amendment.

There are restrictions in SystmOne which prevent information from being amended when this would not be appropriate; for example, if a medication has been prescribed or if a diagnosis has been made. Any entry which is coded, to allow for reporting on this information, will need to be marked in error for the code to be removed.

14.1.1 Marked as Deceased in Error

If a patient has been marked as deceased in error on the SCR, this can be reversed. If you believe that a patient has been deceased in error, please log an urgent call with the Trust IT Service Desk giving the patient’s NHS number, initials (of the forename and surname) and DOB and describing the problem and why you believe that the patient is not deceased. The Application Support Team will then take this up urgently with the NBO, who deal with SCR data quality issues.

14.2. Marking Information in Error

When any system user becomes aware of incorrect data in the record which it is not possible to amend, they are responsible for marking this in error. It is necessary to give a reason why this is being done, for example:

Data was recorded in the wrong patient record

Data was recorded with wrong date

Incorrect data was recorded

Data was duplicated

Other: Use free text notes box for further explanation

Data which has been marked in error will no longer be visible in the record, except for those users with the appropriate access rights. Users with this access will have a ‘deleted items’ view listing all items which have been marked in error. ‘Deleted



items’ will also be visible within the part of the record they were removed from, and will be clearly identifiable.

If one read coded entry within a template is not correct, it is possible to select the individual coded information within the tabbed journal to mark it in error without marking in error the whole content of the completed template.

If a patient related task has been sent to another unit, it is not possible to mark this in error. If you become aware that you have sent a task incorrectly, the recipient should be contacted immediately and advised to update the task indicating ‘incorrect patient information’ and delete it. The sender should ensure that the task is sent in relation to the correct patient as soon as possible; the content can be copied and pasted from the original task prior to it being deleted.

If it is not immediately recognised that the task was relating to the wrong patient and it impacts on the care for that patient, information will need to remain in the record to provide an audit trail indicating the reason for the inappropriate care. The recipient of the task should contact the sender to inform them of the error, as this may enable them to send the task in relation to the correct patient.

It is not possible to mark in error an entry which has been made by another service or organisation involved in the patient’s care, which has been entered via a different unit of SystmOne. A mark in error request task needs to be sent to the originating unit, explaining why this is being sent.

14.3. Requesting Permanent Deletion of Data from the Patient Record

In the rare circumstance such as a court order requires an item to be permanently removed from the patient record, it is the responsibility of the relevant manager with the appropriate access rights to request this. To request permanent removal of an item in the record, the information will first need to be marked in error as described in 14.2. The data will then only be visible to managers with the relevant access right to be able to request permanent removal of this data. Other than by request of a court order, there may occasionally be other circumstances when it is necessary to request permanent deletion of data. Examples of this include:

a patient has been incorrectly registered for care with a service; this registration for care cannot be marked in error.

a duplicate referral is entered for a patient’s hospital admission; the referral can be marked in error but requires permanent deletion to discharge the patient from care on the system. NB: this does not apply when a duplicate referral is entered for any other community services. The additional referral can be ended, indicating that this is a duplicate, without the need to permanently delete this.

A patient makes a request for deletion under the right for erasure within Data Protection laws, which has been managed by the IG Team and the Caldicott Guardian.



The manager who requests the permanent removal of data should inform the Caldicott Guardian when they do this, explaining why this is required and advising which SystmOne unit the incorrect data is recorded in. Requesting the permanent deletion of data in SystmOne will result in a task being generated by the system for the Caldicott Guardian to authorise the request. The Caldicott Guardian is responsible for actioning this task. Mark in Error Request task: please see section 15.6 below. Further Information: QRG Managing Incorrect Entries

14.4. Responsibilities

The Caldicott Guardian is responsible for actioning tasks appropriately for authorising the permanent deletion of information from a patient record. Service managers / team leaders are responsible for ensuring permanent deletion of information from the patient record is only requested in the appropriate circumstances and liaising with the IG Team.

All staff using SystmOne are required to maintain accurate patient records, which includes marking erroneous information as described in this procedure.

15. MANAGEMENT OF TASKS

Tasks are designed to help users and organisations manage their workloads. A task takes the form of a message sent to one or more SystmOne users. It records work to be done and allows you to keep track of the progress of that work. Tasks can be sent to SystmOne users outside SCFT if the record is shared; in this case, the task MUST be patient-related. SystmOne also generates tasks in response to data entry in order to alert you to work that has been done or needs to be done on a patient record.

If tasks are allowed to build up and your SystmOne unit receives more than 200 tasks this will have a detrimental effect on the performance of the system. As a result, you will experience a timeout of up to 45 seconds or longer when logging onto your SystmOne unit.

Further tasks are generated by other users or organisations in order to keep the record up-to-date and accurate in content. Therefore tasks are an essential part of the management of the patient record. Tasks within SystmOne can be patient related or non-patient related. The patient record can be accessed directly from a patient related task, allowing you to manage the task effectively. The task and the management of this will be saved automatically within the patient record as part of the administrative documentation for that patient. Quick reference guides are available on the Pulse (see reference below) to provide an overview of how to send a task and how to manage a received task.



The left hand pane of the tasks screen within SystmOne shows a view of two main folders, ‘All Tasks’ and ‘Filters’. These can be expanded to view the sub-folders contained within them, allowing you to focus on a sub-section of the tasks when required, for example breaking them down by task type, user group or staff member.

There are a number of locally defined task types that have been created within the SCFT SystmOne units to assist staff to identify clinical work and/or administrative updates to the record which are relevant to a particular service.

There are also a number of built in system generated tasks that are sent automatically after the record has been accessed or updated. More information can be accessed about tasks by using the ‘help function’ in SystmOne (press F1 on your keyboard when in the tasks screen).

15.1. Task Types

A glossary of the built in task types is shown in Appendix 6. This provides details of each task type, explaining what the tasks are and why they have been received. Instruction is also provided to show who is responsible for dealing with them, how frequently they should be managed, and the actions that should be followed to manage each task type.

15.2. Task Status

If you need to record progress made on a task (without completing it) or if you want to make several changes to a task, you must update it. If you need to record that a task has been completed, you must action the task or change the task status to 'Completed', as appropriate. Tasks should not be deleted.

15.3. Task Flags

When you create or update a task, you have the option of assigning a flag. These task flags can be associated to a specific meaning and colour coded. Flags should only be used if these have been agreed with the recipient of the task, to ensure they are understood.

15.4. User Groups

It may be appropriate for some tasks to be sent to a staff group rather than sending them unassigned or to an individual user, in order for the task to be dealt with efficiently. Examples of user groups which you might find in your unit are:

Administrative

Community Nursing

Health Visiting

Dieticians

Doctors

Medical

Occupational Therapists

Physiotherapists

Proactive Care

Speech Therapists



Urgent

Members of staff are allocated to these specific user groups. Tasks sent to the specific group still remain visible to those staff who are not within the user group.

To check which staff are members of a user group, within the ‘Task’ screen select

the relevant user group from the drop‑down list and click ‘Members’. If this list needs

to be amended or a new user group is identified, contact the application support team via the IT Service Desk.

15.5. Top 5 Tasks

15.5.1 Managing Out of Hours (OOH) tasks If one of the patients who is registered for care within your unit is seen by a SystmOne OOH or A&E service, you may receive up to three tasks at your organisation regarding the contact: 'SystmOne OOH Contact' task

This task is sent to notify you when an out of hours service using SystmOne has contact with a patient who is registered within your unit.

Please note: Changes to the patient's address, name, sex, registered GP, telephone number or consent status are not included in the message.

'Patient Accessed' task

Whenever an OOH or A&E service accesses a patient record, they will have to answer the question "Does the patient consent to the viewing of the medical record?" If the patient gives consent, this causes a 'Patient Accessed' task to be sent to your organisation's 'Unassigned' folder for each individual patient. The task shows where and when the record was accessed and by whom. If more than one person at the OOH unit accessed the record, they will all be recorded in this task (this means you should only receive one of these tasks for one patient, no matter how many people have looked at the record).

'Patient Access Summary' task

This type of task contains a list of all of the patients registered for care within your

unit who are accessed by an OOH or A&E service during a 24‑hour period. This is

sent to your organisation's 'Unassigned' folder. This task can be deselected if the organisation unit prefers not to receive this task. Contact application support via the IT service desk to log your request.

These tasks, although high in numbers, are useful for patient care to highlight frequent attendance which may flag concerns. If the patient has consented to record sharing, the task can be used to identify access to view the clinical information for the attendance.

It is recommended that these tasks be directed to the key clinician involved in the patient’s care; once these have been observed they can be marked as completed to



clear the task from the tasks screen. The information will be retained within the patient record so can be referred to later

15.5.2 Managing Patient Deceased Tasks

If a date of death has been set in another organisation, a patient deceased task will be received to any SystmOne unit caring for the patient.

These tasks should be completed and the patient record accessed to ensure the patient is discharged (deducted) from the unit.

Please see SystmOne: Recording Deaths Standard Operating Procedure for further information (reference below).

15.5.3 Managing Mark in Error Tasks

Mark in error request tasks are sent by other organisations, asking you to remove information which has been added to the patient record by a user at your organisation. It is vital to action these tasks promptly to maintain the accuracy of patient records, as future clinical decisions may be based on information that the other organisation is disputing.

If the mark in error request relates to a coded entry completed as part of a template and the request indicates that the code is inappropriate not just for an individual patient but for general use, a call should be logged with the IT helpdesk for the application support team to review the coding of the template.

If your organisation has any un-actioned 'Mark in error request' tasks that are more

than four days old, a warning with a countdown timer will be displayed when you log on to SystmOne. If these tasks are not dealt with immediately, this warning will be redisplayed every 30 minutes.

It is best practice for the clinician to review the entry in the journal so that the error can be viewed in context of the consultation.

If you decide not to ‘mark as error’ you MUST enter a reason. SystmOne will generate a ‘mark in error’ response to the requesting organisation.

Team leads or clinical service managers will have the appropriate access rights on their smartcard to be able to see all items marked in error in the ‘deleted items’ node of the clinical tree.

15.5.4 Handling Merge Records Requests

Duplicate records may occur for the following reasons:

The patient was registered under two different names (Mr and Master)

The patient was initially registered with a temporary status and then fully registered

The patient was registered without an NHS number and then with an NHS number



When a duplicate record has been identified, a merge is required to combine the two into one complete patient record. When a merge has been requested there are two types of task which will be received.

Patient Record Due to be Merged

A ‘patient record is due to be merged’ task will be sent to your unit with or without the name of the unit requesting the merge (according to patient consent settings). The patient merge will be completed within a set timescale (see SystmOne F1 help for more information). The task will automatically be set to complete once the merge has taken place - if the merge request is appropriate.

For example:

The record of Mr Mickey Blogs (00 Feb 2009) is due to be merged with another patient record. The other record is for Mickey Blogs (00 Feb 2009).

This merge was scheduled by Mrs A Rich @ Dr Surgery.

You will be unable to report on the merged patient's record for 24 hours following the merge. The patient will also be excluded from QOF results during this time.

To cancel this merge, simply delete this task.

There is limited information to determine whether the merge should not take place; inconsistencies in the names or date of birth may be a reason to cancel the merge. If there are inconsistencies, the organisation who requested the merge should be contacted if this information is known, in order to ascertain whether the request is appropriate. However, as this is very likely to be a valid request, usually no action is required. The merge will occur automatically without any intervention required, and the task will automatically complete once the merge has taken place. Deleting the task may result in an increased number of duplicate records which could mean you are viewing or using in incomplete record.

Merged Patient Record Check

A ‘merged patient record check’ task will be sent after the merge has taken place between 2 electronic patient records. Each SystmOne unit that has the patient registered will receive this.

For example:

Mr Mickey Blogs's record has recently been merged with another on SystmOne.

New data may be available that may affect your clinical and administrative processes.

You will be unable to report on this patient's record for 24 hours following the merge.

The patient will also be excluded from QOF results during this time.



The task does not ask you to do anything but it is best practice to retrieve the patient and look through the tabbed journal to complete the ‘merged patient record check’. This review can be completed by a team administrator.

You are looking for consistencies that show that two records belong to the same patient and are therefore safe to merge, or inconsistencies in the records that may indicate that they are two different records from different patients that should not be merged. Look for:

Review the tabbed journal (click from local data to ‘Everything’) looking at geographical locations; has the patient been seen by different services in two different locations? For example it’s not likely to be the same patient if they have been seen on one day by your team in Brighton and then shortly after by a community service in Bath.

If another organisation is visible it might be worth consider calling them to help establish whether you both have records for the same patient or whether the patients are different people.

If you have checked the record and are happy that the merged records are the same patient then close the record by ‘discard’ go back to the task, click Action – (take over the task if it’s not assigned to you) click ‘yes’ to ‘Has the patient record been checked’. The task will then be removed. Clicking ‘No’ to ‘Has the patient record been checked’ will keep the task active and will remain open until the above process has been completed.

If you believe that the merge should not have taken place, click ‘no’ to keep the task active and contact the application support team via the IT helpdesk to request advice. Update the status of the task to ‘started’ and add a note to indicate to other staff in your unit that this merge is being investigated as it appears to be incorrect.

15.5.5 New patient address task

When a SystmOne user records a new patient address, other organisations sharing the patient record are sent a 'new patient address' task to give them the opportunity to update the address details. When the task is actioned, the ‘change home address’ dialog box is displayed, showing the old address (if one exists) and the new one. If the ‘update patient address’ dialog box is completed, the 'new patient address' task will be marked as completed.

It is vital that these tasks are actioned on a daily basis to ensure the records remain up-to-date and patient visits/appointments are not affected. A temporary address can be added to the record if the patient is staying with relatives/friends for a short period. A correspondence address can be added to the record to ensure letters are sent to the correct address.

Please refer to section 7 for further guidance on managing addresses.

15.6. Monitoring of tasks, including during staff absence



Team leads should monitor SystmOne units on a weekly basis to ensure that tasks do not build up. All tasks can be accessed by task type and staff member on the left hand side of the screen.

All teams must have a process in place to monitor unassigned tasks and to monitor the tasks of colleagues who are temporarily not working, e.g. due to annual leave / sick leave / maternity leave. This could be the Administrator or Co-ordinator.

16. MEDICATIONS, SENSITIVITIES AND ALLERGIES

It is important for clinicians to be aware of allergies, sensitivities and medications to ensure safe provision of care. For staff to be able to access the information easily, it needs to be documented in a consistent location and format in the patient record. Where the record is shared across services, the information will be visible for all who have access to the shared record.

When allergies, sensitivities and medications are appropriately documented within SystmOne, the system will flag a warning if a clinician attempts to prescribe medication which may interact with other medication the patient is taking, or to which the patient may have a sensitivity or allergy. A patient might still be prescribed interacting medicines i.e. the presence of a flagging system does not prevent interacting medicines from being prescribed. Interactions may be beneficial or harmful and the prescriber should be monitoring them. Staff with concerns or questions should always raise them with the prescriber.

The initial clinical assessment of a patient should include identification of any allergies or sensitivities, and confirmation of all medication which the patient is currently taking, including medicines purchased by the patient, homeopathic and herbal medicines. The clinician obtaining this information is responsible for documenting this as part of their assessment. If the patient has no known allergies or sensitivities this should also be recorded. If the information is already documented on the SystmOne record and visible due to sharing of the record, it should not be duplicated, but if there are any changes the record should be updated appropriately.

16.1. Checking Existing Allergies and Sensitivities recorded in S1

When prescribing or administering treatment, it is good practice to always ask the patient / carer if they have any allergies or sensitivities. There may be information which has not been recorded in SystmOne; the record can then be updated as necessary.

Access the patient record to check what has been recorded. Allergies / sensitivities can be viewed in multiple places.

Any allergy or sensitivity documented on SystmOne will show on the home screen within the record when the patient is retrieved. If details of the reaction / symptoms are documented as part of recording the allergy, the entry on the home screen will also include this information. Please note: If there is a lot of information on the home screen users may need to scroll down to see the allergy/sensitivity information.



Any allergy or sensitivity which has been recorded can be accessed from any screen

in the patient record via the symbol. This will show at the top right corner of the record, below the demographics box. The number below the symbol indicates how many allergies have been recorded. Clicking on the symbol will provide a pop up box giving details of the recorded allergies.

Allergies and sensitivities can also be accessed via the relevant node in the clinical tree.

16.2. Documenting a New Allergy or Sensitivity

Check the allergies and sensitivities already in place on the record. All allergies and sensitivities including but not limited to those caused by medication should be documented.

If you are aware of an allergy or sensitivity which is not documented, complete the template to ‘Record sensitivity or allergy’. Select whether this relates to a drug or other allergy.

Recording an allergy will automatically flag up an information box asking you to make a decision on whether you need to complete the yellow card scheme. Answering ‘yes’ will automatically take you to the reporting screen. This means you can report directly to the MHRA via SystmOne and don’t need to fill in any paper copies or other online versions of the Yellow Card Scheme. If you click ‘Do Later’, you will receive a task at a later point which must be acted on by completing the yellow card reporting form.

All clinical practitioners are expected to complete yellow cards when appropriate. Please find guidance on the yellow card scheme in the relevant policies referenced below.

When you have entered the relevant information, save the record.

16.3. Documenting Medication which the Patient is Currently Taking

The Summary Care Record can be accessed from within the SystmOne patient record following appropriate guidelines to view medications which have been prescribed.

The medications node in the clinical tree should be checked to view any medication already recorded – be aware that this list may be incomplete depending whether there is full sharing of the record and whether the GP or other prescribers are using SystmOne.

Check the relevant assessment documentation for your service; if relevant, this will include a field for ‘Current medication’ or ‘Drug therapy observations’. This field has been consistently coded across SCFT services to ensure any information documented within your organisation sharing group (adults or children’s services) will be visible as a previous recording.

If the prescribed medications are visible in the SystmOne record but there is a mismatch between the record and what the patient reports they are taking:



Any medication stopped for side effects must be recorded as a sensitivity or allergy. The prescriber should be notified that the medication is no longer being taken.

Any additional medication should be documented within the assessment template. If the GP or other relevant prescriber is a SystmOne user, the issue should be raised directly to them for their review and consideration of addition to the record as a prescription.

16.4. Prescribing

It is only possible to document a ‘New Acute’ prescription within the Medication node of the SystmOne record if you are a qualified prescriber with the appropriate access rights. It is important to check for existing prescriptions and any warning messages relating to contraindications or allergies and sensitivities, to ensure it is safe to proceed. The required details must be documented within the patient record. Please refer to SCFT Medicines Policy for further details.

It is currently only possible to send a prescription electronically to a community pharmacist via the GP’s electronic record system, so the prescription will need to be handwritten, or printed if you have appropriate facilities.

Clinicians who are qualified to prescribe but do not yet have appropriate access rights agreed to do this within SystmOne should continue to handwrite their prescriptions. The prescription must also be documented within the SystmOne record, using the ‘Record Other Medication’ option within the Medication node.

For non-SystmOne GPs it will be necessary to send a notification to the GP of what has been prescribed.

16.5. Recording the Administration of Medication in SystmOne

SCFT staff administering medication in any setting must follow the relevant Trust medicines policies and must record the administration within the SystmOne patient record. When medication is administered in the patient’s home, the administration record will also need to be included within the paperlight patient held record to ensure that duplicate doses are not administered by staff without access to the SystmOne record.

Check the medications node in the clinical tree to view any medication already recorded. If in the patient’s home, check the patient held paper record for medication administered by others not using SystmOne.

Select the relevant medication administration template. Vaccinations or administration from PGD are recorded within the system wide medication section. Other medications administered should be recorded within the appropriate service specific template for administration of medication.

Complete all the required details – refer to SCFT Medicines Policy for further information.



17. ALERTS AND REMINDERS

17.1. Alerts

Patient status alerts are designed to draw important information to your attention when you retrieve a patient record. Each alert links to a specific read coded entry in the record and it is possible to report on how many patients have an alert. System wide alerts are available to any system user; they are visible whether or not the record is shared. They show in the record below the patient demographics details in the top right corner. Hovering over the symbols in this area will flag up a text box giving details of what the symbol is indicating. Different symbols relate to different alerts, for example:

Diabetic

Hypertensive There are some system wide alerts relating to safeguarding information, which are only visible to users who have the relevant access rights:

Safeguarding information exists without ever having been on a child protection plan

Patient is on a child protection plan

Patient removed from child protection plan Local alerts can be defined specifically within an organisation group; these will only be visible to specific Sussex Community Foundation Trust (SCFT) services. Information will show in the patient record within the organisation group. An example of an organisation specific alert in SCFT is Do Not Attempt Cardio Pulmonary Resuscitation. This is shown in the same area, below the demographic details:

Do not resuscitate (DNACPR) Local alerts are also flagged in the column at the right hand side of the record; any

local alert will be flagged with the symbol:

Clicking on this symbol will reveal the details of the alert.

17.2. Reminders

Reminders are used to flag on the record any other issues which could put patients or staff at risk, for example security warnings, environmental concerns or key safe details. These issues are not linked to read codes; they are free text and cannot be reported on. Different priority levels can be set, depending on how widely the reminder needs to be flagged to users. Reminders of all priorities will be visible on the reminders view for all SystmOne units that care for the patient, if the record is shared.

Symbols appear in the column at the right hand side of the record when there is a reminder in place:



High priority reminder: flags to all users at any SystmOne unit if the record is shared.

Normal priority reminder: flags to all users at the SystmOne unit where the reminder is set. Flags to all users within the SCFT organisation sharing group which the service setting the reminder is a part of.

Low priority reminder: flags as a reminder only to the user who sets it on the patient record. Will flag to this user in any SystmOne unit where they access the record, whether or not the record is shared.

17.3. Visibility of Alerts and Reminders

In the SystmOne unit where an alert or reminder is set up, the full textual information of both alerts and reminders will be shown on the home screen when the patient record is accessed. When looking at any other screen in the record, the presence of alerts or reminders will be flagged using the symbols defined above.

Visibility of alerts and reminders at other SystmOne units (SCFT and non-SCFT) is summarised in the table below:

Alert / Reminder Visible without sharing the record

Visible when the record is shared

Only visible with appropriate access rights

Locally defined alert

NO YES (only flagged as an alert if a report is configured associated with the read code which triggers the alert)

N/A

System wide alert YES YES N/A

Safeguarding relevant alerts

YES YES YES

Low priority reminder

NO YES (only within the reminders screen, not flagged throughout the record except for the user who created the reminder)

N/A

Normal priority reminder

NO YES (only within the reminders screen and included on printout of a patient summary, not flagged throughout

N/A



the record)

High priority reminder

NO YES (visible within the reminders screen and flagged throughout the record)

N/A

17.4. Creating a new reminder

Use the ‘Expiry’ field if appropriate to set an expiry date for the reminder and use the notes field to add details. If there is no expiry date the notes field should be used to indicate when the reminder needs to be reviewed.

Commonly used notes within reminders can be configured as presets. Examples of preset reminders which may be configured for community services providing home visits could be: ‘beware of dog’, ‘telephone before visit’, or ‘visit in pairs’.

17.5. Checking Alerts

Access the patient record and view any existing alerts and reminders as indicated by the icons at the top right corner below the demographics box. Alerts should be checked each time the record is accessed.

17.6. Reviewing Reminders

If an existing reminder is no longer valid, access the reminder in the relevant section of the record and select ‘cancel’ to end it.



If the information in a reminder is still valid but the review date has been reached the reminder should be cancelled and a new reminder created with an updated review date.

All reminders should be reviewed at time of discharge and when a patient is transferred to another service (see 20.2 Ending reminders and relationships).

18. RECORDING SAFEGUARDING CONCERNS

It is everyone’s responsibility to act on and report safeguarding concerns regarding children and adults. Further, as clinicians it is our duty to record safeguarding information correctly and accurately on patient records.

Serious case reviews have demonstrated that lack of communication between practitioners contributes significantly to children experiencing harm from abuse by parents/carers. In SystmOne, the status of children at risk and vulnerable adults can be shared across services and organisations to alert clinicians and guide their decision-making.

This section guides clinicians to record safeguarding information on patient records (children and adults) accurately in SystmOne.

Some safeguarding information needs to be widely shared across services so that clinicians are aware there are safeguarding concerns. Access to other safeguarding information documented in the record needs to be limited. This SOP will explain how to record information to ensure that it is appropriately shared.

18.1. Safeguarding Alerts / Patient Status Markers

Recording ‘Safeguarding Information’ within the Safeguarding node in the patient record will trigger one of the following three alerts to appear. These alerts are system-wide; they will be visible across all organisations and services using SystmOne.

Alert Definition Triggered by

Safeguarding information exists without ever having been on a child protection plan.

Entering safeguarding information within the system wide Safeguarding Information node. This applies to adults and children.

Patient on a Child Protection Plan Entering via the Safeguarding

Information node that the patient is currently on a child protection plan. This applies to children’s records.

Patient removed from Child Protection Plan

Unticking the ‘Patient is currently on child protection plan’

Any member of staff who identifies a safeguarding concern which is not already flagged within the patient record is responsible for adding a safeguarding alert to flag this.



Please note that only staff with ‘View Safeguarding Alerts’ access right will be able to see the three system wide Safeguarding Information alerts (see section 2.3 for more detail about access rights).

There may also be other locally created or system wide alerts which are triggered by entering read coded information as described in section 17.1.

18.2. Guaranteed Sharing of Safeguarding Information

The system wide safeguarding node is designed for entering brief details to flag a safeguarding concern. All information entered into the safeguarding node is shared across S1 organisations and visible to users with safeguarding access rights – independent of record sharing settings. Information which should be recorded in this node is:

Event date and time

Organisation name – to ensure that all organisations accessing the record know which organisation recorded this information

Telephone number – to enable other organisations accessing the information to contact your service if they have questions / feedback / concerns about the patient to discuss with you.

Comments – this field should be used to concisely document key safeguarding information using pre-defined ‘presets’ where possible to ensure consistency in the information which is documented.

18.3. Marking an entry as Safeguarding Relevant

Any staff member who observes an incident or receives safeguarding relevant information is responsible for recording this as safeguarding relevant within the patient record. Documentation received by a service separately from the SystmOne record may be scanned in by administrators and must be recorded as a safeguarding relevant entry if appropriate.

When saving an entry in the patient record, you have the following three options for visibility of the information within SystmOne:

Normal

Private

Safeguarding relevant

Detailed safeguarding information should be recorded as a safeguarding relevant event to ensure that only those staff who have been given the additional access right to ‘View Detailed Safeguarding Relevant Events’ will be able to see this in the record. However, a user without safeguarding access is able to view their own safeguarding relevant entries if they enter safeguarding information in this way.

Please be aware that other non-safeguarding information must be recorded as a separate entry in the patient record even if it was part of the same event. This is



important, to ensure that users without the additional safeguarding access right are able to see the relevant information in the patient record.

Example of recording safeguarding information:

A HV has identified safeguarding concerns during a developmental review. The safeguarding concerns must be recorded separately in the safeguarding node, with no reference in the developmental review template. Both entries need to be saved separately, the developmental review as normal visibility and the safeguarding information as safeguarding relevant.

Visibility of record entries can be changed at a later date, please see section 12.5.1 Amending the visibility of record entries.

18.4. Who should enter safeguarding information & who can see safeguarding entries

There are different access rights to SystmOne which will control the safeguarding information that staff are able to view within the patient record.

‘View Safeguarding Information’ allows staff to record and view the 3 system wide safeguarding alerts or patient status markers described in section 18.1.

‘View Detailed Safeguarding Relevant Events’ allows staff to access the detailed information within the patient record which has been documented as a safeguarding relevant event described in section 18.3.

Each organisation using SystmOne determines access rights for their own different staff groups. Within SCFT this will vary across different services; for example, within the Healthy Child Programme it is considered appropriate for all clinicians and administrators to be given this access, but for adult services it is only appropriate for some clinicians and not for administrators to have this access.

The appropriate access rights for each job role within each service are defined with consultation from clinical services and localities across the Trust and used to create baseline smartcard roles to provide appropriate access. Additional access rights which are not part of the baseline role can be added for an individual staff member if appropriate.

The RA team keep a record of the smartcard roles and access rights assigned to each job role as a baseline. When access rights are not a core part of the role but are assigned to individual staff members within a service, the line manager is responsible for keeping a record of the additional access rights given. There is an audit trail within SystmOne which shows every record accessed by every member of staff.

Concerns regarding insufficient or excessive access should be escalated via line management. Amendments to the access rights for an individual staff member can be approved by an appropriate sponsor, who is responsible for keeping a record of the members of their staff with additional access. Proposed amendments for a staff group (e.g. all administrators working in Minor Injury Units) should be escalated through SystmOne Champion User Groups or through line management for approval.



18.5. Significant event / Chronology

Please use this template as if you were writing headings for the related record entry

– see pre-set notes to the right of the box for quick entry. Further detail must be recorded in the relevant template. The information from the significant events template can be printed off for child protection reports etc. – create a New letter in Communications & Letters and choose template Chronology template (Child protection section).

18.6. Safeguarding information about Children and Adults not Receiving Care from your Service

When visiting a patient you may identify safeguarding concerns about another person in the household who is not within your care. It will not be appropriate to register this patient within SystmOne as receiving care from your service, so you are not responsible for adding an alert within the SystmOne record. However, it is important that you act on your concerns.

Safeguarding concerns should be escalated using existing processes i.e. raising an alert to Social Services, recording an incident and notifying the Safeguarding team. Please refer to the Safeguarding Policy for further detail.

18.7. Safeguarding Adults Receiving Care from SCFT services

Adult safeguarding concerns should be documented on the Datix system and appropriate safeguarding boxes completed.



The patient’s record on SystmOne should then be updated highlighting the concern in safeguarding relevant information and including the Datix report identification number for cross referencing purposes.

18.8. Adult safeguarding: Making Safeguarding Personal (MSP)

A key principle of the Care Act 2014 is to ensure that each adult patient is supported and empowered to make choices with regard to the safeguarding concern. Staff need to ensure the patient has capacity to make their decisions, however unwise their decisions may appear to be. If an individual’s capacity to make such decisions is in doubt, then staff should follow and complete the mental capacity assessment tool within SystmOne.

18.9. Deprivation of Liberty Safeguards (DOLS)

Should a patient be under a DOLS this should be recorded on SystmOne as a reminder to ensure all staff working with the patient are aware.

18.10. Recording reports from other services in SystmOne

Safeguarding relevant documentation may be received from another organisation who have been involved in an event relating to a patient in your care, for example social services or police. This information will need to be included in the patient record to ensure all appropriate staff are able to access it. The entry in the patient record (e.g. scanning in a letter or adding an attachment received electronically) should be marked as a safeguarding relevant event. Please see section 11 Document Management for further information.

Health Visitor, School Nurse, FNP:

All SCARFs, minutes from MARAC and child protection conferences and other safeguarding documents from third parties must be attached to child’s and parents records where available within Communications and Letters and saved as safeguarding relevant, following review by a clinical member of staff (see section 11 Document Management).

18.11. Supervision case discussions

Attach as per section 11 Document Management and mark 'safeguarding relevant' and /or safeguarding main template and completed in appropriate section.

18.12. HCP Specific Patient Status Markers

There are locally created patient status markers within SCFT which are recorded within the Healthy Child Programme to flag significant information within the patient record, as shown below. This information may be completed as part of the ‘Safeguarding Main Template’ (if not otherwise possible) but must not be recorded as a safeguarding relevant event, to ensure that all staff who require access to this information are aware of it.

Alert Definition Triggered by these Read Codes

Health visiting: UP Service Level: Under care of HV



service – Universal Plus

Health visiting: UPP Service Level: Under care of HV

service – Universal Partnership Plus

School nursing: UP Service Level: Under care SN service –

Universal Plus

School nursing: UPP Service Level: Under care of SN

service – Universal Partnership Plus

Under the care of FNP Under care of Family Nurse Partnership

No longer under the care of FNP No Longer Under Care of Family Nurse Partnership

Child with additional needs Disability

Early Help Plan Common Assessment Framework

initiated – On Early Help Plan

Looked after Child (added by LAC team)

Looked after child (Children Act 1989)

Child previously looked after (removed by LAC team)

Child no longer looked after

Child In Need also known as Child and Family Plan

Child in need / Child and Family Plan

Subject to Education and Health Care Plan

Birth to 25 EHCP

Further information:

QRG How to View Patient Status Alerts

QRG How to Email a Safeguarding Alert Form (MIU)

18.13. Use of reminders for safeguarding information

It is recommended that a reminder is used on the record to flag information which it is appropriate to share with all staff accessing the record from any organisation involved in the patient’s care. For example, high priority reminders are appropriate for flagging Child Sexual Exploitation.

Please see section 17 Alerts and Reminders for further information.



19. CLOSING THE RECORD

19.1. Saving a record entry

The QRG How to Record Event Details explains how to save record entries. Please also refer to your service specific SOP for more information to ensure accurate Event Details are recorded. TIP: in the desktop version of SystmOne, if you want to save several events without the record closing each time, click on Next Event which is located above the clinical tree:

Make sure you have saved each event before selecting Next Event, to ensure the correct details and visibility of the event are added into the patient record.

Please be aware that safeguarding information must be saved separately from other record entries, see section 18.4 Marking an entry as Safeguarding Relevant.

19.2. Marking a visit as finished

To ensure clear visibility that care has been provided and to allow for accurate reporting it is essential that all visits are finished appropriately. S1 mobile working On the Planner screen left click to select the patient and choose Finished. S1 desktop version When accessing the record: on the visits / appointments screen right click, choose Consultation. Your contact will automatically be marked as face-to-face, clinically relevant and finished when saving the event and closing the record. If the visit / appointment has not been accessed via ‘Consultation’ it needs to be manually marked as finished. This is done from the visits / appointments screen by right clicking the relevant patient and selecting the option ‘Finished’.

19.3. Amending details of event

It is possible to change event details if required, even on deducted records. Choose the correct record entry in the tabbed journal and right-click on the header.



20. DISCHARGE

20.1. Ending a referral

When the patient does not require any further input from the service, the Referral In needs to be ended within the patient record. In order to enable accurate reporting and effective caseload management, all referrals should be ended as soon as possible following the decision to discharge / end service involvement. Ending the referral deducts the record from the SystmOne unit. Please see section 20.3 for recording a patient death.

20.2. Ending reminders and relationships

All reminders and relationships which have been added to the S1 record by your service must be ended as other teams will not be able to amend or remove relationships created at your unit. Please remember to hand over all relevant info on relationships and reminders, e.g. key safe, to other services as relevant.

20.3. Recording a death

The death of a patient is a sensitive time for all involved, particularly for family and friends. It goes without saying that all care should be taken to act appropriately, particularly if there is any question about the correct status of the patient i.e. whether they are alive or deceased. The patient’s GP will normally be a definitive source for this information and should be consulted if there is any question about this. Following this process will discharge and remove the patient from caseloads; cancel any appointments and scheduled visits; discharge from an inpatient bed; etc.



See section 14.1.1 for guidance on what to do when a patient has been marked as deceased in error.

20.4. CCHIS Procedure

Complete the “Record Child Death – CH –SCT” data entry template:

Tick ‘Patient Died’

Suspend all scheduling

Add reminder to child’s record stating: CHILD HAS DIED – awaiting date of death to be recorded by GP

Send task within SystmOne to all services involved in care to notify them of death

Send cascade email to ensure information is shared appropriately with all who need to know

20.5. Procedure for All Other SystmOne Users

When aware of or notified of a patient death:

Search for the patient in the usual way. Double-check that the correct patient has been selected.

End all open referral(s) with the reason for end of referral being “Discharge” and record the location as appropriate. Referral intervention is “Discharged - Patient died”.

Do not attempt to record the date and time of death – this will be done by GPs or others who are in a position to officially confirm death.

Follow any other local procedures as required e.g. reporting the death to staff or other agencies; retrieving equipment from the deceased person; archiving paper notes etc.

20.6. Notification of death via task

When notified as a task on SystmOne via the PDS of a patient death:

Action the task

End all open referral(s) as prompted by the system: The reason for ending the referral will be marked for you as "death" in this situation, and the date and time will be set.

Record the location as appropriate.

Tasks will be automatically sent to other SystmOne users with an open referral for the patient, informing them of the death.

21. TEAM OR SERVICE CHANGES

Team / service changes or large mergers should be logged by the service lead through the IT Helpdesk as soon as the changes enter the planning stage to allow for an assessment of the changes needed to SystmOne.



This request will initiate S1 BAU Business Change process, and issues such as smartcard access, configuration changes and data migration are assessed and planned with the service to smooth the transition as much as possible.

Teams will need to work with the Application Support team to ensure a safe transition and continued service provision.

22. STAFF ABSENCE

It is possible to disable an account if the member of staff will be absent for a long period of time. The team lead / service manager would need to log a call to the Application Support team to inform of the user’s absence. NB: This would not remove that person from the task list, rota list etc. When the staff member’s return date has been agreed (i.e. before they return to work), a call needs to be logged requesting the account be unlocked. Planned leave: the staff member needs to ensure that SystmOne is up to date by the end of their last working day. This should be highlighted to the staff member as part of their supervision or pre-leave meeting with their manager or team lead. The following processes need consideration when a member of staff goes on short- or long-term, planned or unplanned leave: Visits / Appointments Any booked Visits / Appointments should be reassigned, cancelled or rebooked as required. Tasks The absent user’s task inbox needs to be monitored and any pending tasks reviewed, actioned or completed as necessary or reassigned to another team member. Staff-specific caseload

Consider if the caseload needs to be cleared and patients re-assigned. NB: Patients can be reassigned in bulk within Caseloads via Reassign Caseload Holder.

Inform relevant users, e.g. admin, if patients must not be added to caseload. Staff-specific waiting list

Consider if the staff-specific waiting list needs to be cleared and patients re-assigned to other waiting lists.

Inform relevant users, e.g. admin, if patients should not be added to the absent user’s waiting list.



Rota templates / existing rotas

If any rota templates or existing rotas need to be cancelled, amended or reassigned to other members of staff or if you are unsure please contact the Application Support team via the IT Helpdesk.

Batch reports

Batch reports should be sent to a user group rather than an individual, however if an absent user is the recipient of a batch report, this will need to be reassigned to an appropriate member of staff or group: please contact the Application Support team via the IT Helpdesk with this request.

Privacy Officer

If the absent user is the unit’s Privacy Officer, a new Privacy Officer may need to be identified. The corresponding access can be reassigned or a second Privacy Officer can be allocated: please contact Application Support team via the Helpdesk with this request.

Mobile device (laptop)

The device should be left with the manager / team lead. If the mobile device needs to be made available for another member of staff, a call needs to be logged with the IT Helpdesk.

If the absent member of staff uses mobile working: ensure that mobile devices have connected to the SCFT network to allow all patient information to upload to SystmOne.

For staff leaving the Trust or changing role within the Trust, please refer to section 2.5.

23. KEY PERFORMANCE INDICATORS (KPIS)

Please see service-specific SOPs as KPIs are based on individual service performance measures.

24. RESPONSIBILITIES

All Staff using SystmOne are required to follow this procedure. Senior management approval must be sought before deviating from any procedure or guideline; AND the reasons that the procedure or guideline was not followed must be clearly documented. All Staff have a responsibility for any records that they create or use in the course of their duties and this includes records from other services and/or organisations, as described in the SCFT Health Record Keeping Policy (SCFT 2018).



All Staff are responsible for ensuring that caseloads and patient records are kept up to date, and for ending referrals and finishing care when the patient no longer requires involvement from the service. All staff members with face-to-face contact are responsible for discussing record sharing consent with patients at first contact. Team leads are responsible for monitoring the task list within their unit to ensure the team are managing tasks within appropriate timescales. They are also responsible for ensuring a process is in place and adhered to for the management of unassigned tasks and tasks assigned to absent members of staff. Sponsors (usually managers or team leads) are expected to be familiar with the guidance on access to SystmOne as they are responsible for requesting Smartcards / unit access / training for new members of staff, and for requesting removal of staff access to the relevant SystmOne unit when this is no longer required. Sponsors are responsible for ensuring that appropriate members of their service / team have the required level of access to SystmOne to manage the records of patients with sensitive demographics. They must also ensure that this access is removed when no longer required. Senior Managers are responsible for promoting and implementing the procedure. They must authorise deviation from any policy and procedure and ensure that the reasons have been clearly documented. Service managers are responsible for notifying the Application Support team through the IT helpdesk as soon as possible of planned team or service changes. The Caldicott Guardian is responsible for ensuring that requests for permanent deletion of data from patient records are only approved if this is appropriate.

25. ASSOCIATED DOCUMENTS AND REFERENCES

Information Governance Alliance (IGA) 2016 Records Management Code of Practice for Health and Social Care 2016 [online] Available at: https://digital.nhs.uk/data-and-information/looking-after-information/data-security-and-information-governance/codes-of-practice-for-handling-information-in-health-and-care/records-management-code-of-practice-for-health-and-social-care-2016 [Accessed 29 October 2019] SCFT 2017 Medicines Policy [online] Available at: http://thepulse.sussex.nhs.uk/downloads/trustwide-policies-procedures/medicines-management/medicines-policy.pdf [Accessed 22 November 2019] NHS Digital 2019 Restricting Access to a Patient’s Demographic Record [online] Available at: https://digital.nhs.uk/services/demographics/restricting-access-to-a-patients-demographic-record [Accessed 29 October 2019]

https://digital.nhs.uk/data-and-information/looking-after-information/data-security-and-information-governance/codes-of-practice-for-handling-information-in-health-and-care/records-management-code-of-practice-for-health-and-social-care-2016




http://thepulse.sussex.nhs.uk/downloads/trustwide-policies-procedures/medicines-management/medicines-policy.pdf

http://thepulse.sussex.nhs.uk/downloads/trustwide-policies-procedures/medicines-management/medicines-policy.pdf

https://digital.nhs.uk/services/demographics/restricting-access-to-a-patients-demographic-record

https://digital.nhs.uk/services/demographics/restricting-access-to-a-patients-demographic-record



SCFT 2019 Procedure for Adoption & NHS Number Change – Electronic Record Keeping (SystmOne) [online] Available at: http://thepulse.sussex.nhs.uk/downloads/trustwide-policies-procedures/it-comms/adoption-change-NHSnumber.pdf [Accessed 22 November 2019] SCFT 2018 Health Record Keeping Policy [online] Available at: http://thepulse/downloads/trustwide-policies-procedures/governance/health-record-keeping.pdf [Accessed 29 October 2019] SCFT 2017 Registration Authority Policy [online] Available at: http://thepulse/downloads/trustwide-policies-procedures/it-comms/registration-authority.pdf [Accessed 7 February 2019] SCFT SystmOne Quick Reference Guides. Available online: http://thepulse/it/systmone/quick-reference-guides.htm [Accessed 29 October 2019]

26. DISSEMINATION AND IMPLEMENTATION

This policy will be made available on the intranet, and publicised through contact (the trust internal electronic newsletter).

27. CONSULTATION, APPROVAL, RATIFICATION & REVIEW

The writing of this policy has included consultation with the following individuals, groups and teams:

Application Support Team

Area Heads of Nursing and Governance

Clinical Service Managers

Community Nursing Taskforce

Community Child Health Information Service Manager

Digital Clinical Safety Team

Diversity and Inclusion Lead

Information Governance Team

IT Training Team

Medicines Management Team

Safeguarding Team The Health Records Group is responsible for approving the policy. The IG and Data Security Group is responsible for ratifying the policy. The policy will be reviewed 3 yearly by the Digital Clinical Safety Team. The ratification checklist has been completed.

http://thepulse.sussex.nhs.uk/downloads/trustwide-policies-procedures/it-comms/adoption-change-NHSnumber.pdf

http://thepulse.sussex.nhs.uk/downloads/trustwide-policies-procedures/it-comms/adoption-change-NHSnumber.pdf





http://thepulse/it/systmone/quick-reference-guides.htm

SCFT Standard Operating Procedure for SystmOne


APPENDIX 1: SYSTMONE TEMPORARY ACCESS PROCESS The SystmOne Temporary Access Process is for services with a high instance of short notice and temporary shift workers and for staff with smartcard problems out of hours: The SystmOne Temporary Access Process

APPENDIX 2: PROCESS FOR MANAGING TEMPORARY STAFF

ACCESS TO SYSTMONE

Refer to this process for guidance on managing access to SystmOne:

At the time of booking temporary staff for a shift When temporary staff arrive for a shift and cannot access SystmOne

Process for Managing Temporary Staff Access

http://thepulse.sussex.nhs.uk/it/systmone/SystmOne%20Temporary%20Access%20Process%20v1.docx

http://thepulse.sussex.nhs.uk/it/systmone/Process%20for%20Managing%20Temporary%20Staff%20Access%20to%20SystmOne.pdf


APPENDIX 3: CONFIDENTIALITY AGREEMENT FOR NON SCFT STAFF & STUDENTS ACCESS TO PATIENT INFORMATION

Confidentiality Agreement for Non-Sussex Community NHS Foundation Trust Employed Staff

Access to Person Identifiable Information1 and/or Information Systems

1 Purpose In order to ensure effective integrated services and teams these may comprise of members of staff who are employed by different organisations.

This agreement is applicable to persons working in integrated teams, who are not employees of Sussex Community NHS Foundation Trust who need to access, possess or handle confidential information about individuals in order to fulfil the requirements of their role. The agreement outlines that all information concerning patients, staff and the Service is strictly confidential. A breach of confidentiality constitutes serious misconduct and may lead to dismissal. The agreement outlines the responsibilities of both the non-Sussex Community NHS Foundation Trust employed staff member who is accessing confidential information, and the Service or Department who is responsible for providing and monitoring access to their systems (this includes paper-based and electronic systems). 2 Scope This agreement should be read in conjunction with the Sussex Community NHS Foundation Trust policies and procedures that govern the use of information, security and confidentiality. Non- Sussex Community NHS Foundation Trust employed staff members should ensure that they have read and understood these policies and procedures. This agreement applies to all confidential information (whether written, oral or otherwise) of Sussex Community NHS Foundation Trust that needs to be accessed, whether created before or after the date of this agreement. 3 Responsibilities

1 Definition of Person-Identifiable Data: Data that will identify an individual which may include any item such as

name; address, date of birth; NHS number. For the purpose of this agreement and use of systems, this does not include a member of staff’s name (used in isolation).

Confidentiality Agreement – Non-NHS Employed Staff


3.1 All information which may be derived from or be obtained in the course of

working within Sussex Community NHS Foundation Trust or which may come into the possession of the Non- Sussex Community NHS Foundation Trust employed staff member must be treated as confidential.

3.2 Sussex Community NHS Foundation Trust policies must be read and

understood and an Information Governance Training session must be undertaken (information regarding this can be obtained through the Information Governance Department). The Service or Department Lead is responsible for sourcing and arranging the Information Governance Awareness Training.

3.3 Work must only be undertaken by authorised agents of Sussex Community

NHS Foundation Trust who are aware of the requirements of the Data Protection Laws and their personal responsibilities under these laws to maintain the security of Sussex Community NHS Foundation Trust information.

3.4 Except with the prior written consent of Sussex Community NHS Foundation

Trust, no confidential information or any part thereof will be disclosed to any third party. Disclosure will only be made where it is necessary for the performance of tasks, which Sussex Community NHS Foundation Trust has authorised.

3.5 Access to information systems will be provided by Sussex Community NHS

Foundation Trust on receipt of the signed confidentiality agreement. 3.6. Precautions must be taken to ensure the confidentiality of information:

unauthorised access should be prevented by password protection and physical security such as locking cabinets and/or doors when offices are left unattended. Where possible, VDU screens should be positioned so they are visible only to the user. Unwanted paper records should be disposed of safely by shredding on site or use of approved confidential waste methods. No person-identifiable information is to be stored on removable storage devices (eg; CD, floppy disk, USB pens, memory sticks) without prior approval from the Caldicott Guardian. All laptops must be encrypted.

3.7. Any data or information sent from one place to another shall be carried out be

secure means possible. Any transfers of information (outside of daily case management) must be approved by the Caldicott Guardian.

3.8 Information which can identify any patient, or employee of Sussex Community

NHS Foundation Trust can only be transferred electronically if previously agreed by the Caldicott Guardian. This is essential to ensure compliance with strict NHS controls surrounding the electronic transfer of identifiable personal data and information and hence compliance with the Data Protection Laws. This will also apply to any direct-dial access to a computer held database at Sussex Community NHS Foundation Trust.



3.9 Where personal information is recorded in any identifiable form, it shall either be returned to the Service or Department on completion of the work or disposed of by secure means and where appropriate a certificate of secure disposal to be issued.

3.10 Sussex Community NHS Foundation Trust incident reporting processes must

be followed in respect to situations relating to any breaches of security and/or confidentiality of person-identifiable information.

3.12 Any security breaches will immediately be reported to Sussex Community

NHS Foundation Trust Information Governance Department, the Caldicott Guardian and the employing organisation.

3.13 Any agreed reports processed remotely will be checked and released by

Sussex Community NHS Foundation Trust prior to release for correlation. 4 Sussex Community NHS Foundation Trust, Service and External

Organisation Responsibilities 4.1 A senior member (or nominated Caldicott Guardian) of the external

organisation will be responsible for their staff and will ensure that they adhere to Sussex Community NHS Foundation Trust policies and procedures, and take any action necessary in cases of misuse.

4.2 The Service or Department Lead will ensure that access to Sussex

Community NHS Foundation Trust systems is managed appropriately. Regular checks will be undertaken to ensure only staff with current confidentiality agreements have access to systems.

4.3 The Service or Department Lead will ensure that renewal dates are set

appropriately and monitored for inappropriate access. 4.4 The Service or Department Lead will grant access to Sussex Community NHS

Foundation Trust information under the attached conditions and with the express consent of the Caldicott Guardian.

4.5 Sussex Community NHS Foundation Trust will instigate an incident reporting

processes for situations relating to any breaches of security and/or confidentiality of personal information.



Part A - Certification form: To be completed by the Service or Department responsible for the non-Sussex Community NHS Foundation Trust employed member of staff.

Name of Service/Department: _____________________________________ Location/Address _____________________________________ _____________________________________ On behalf of the above I certify as follows: Access to patient identifiable information is to be granted to the named below, subject to the terms and conditions in this contract. Access is to be granted for: ______________________________________(Name)

TYPE OF ACCESS COMMENTS

Justification for access to Sussex Community NHS Foundation Trust information

Signed: ______________________________________ Name: ______________________________________ Position in organisation: ______________________________________ Telephone Number: ______________________________________ Date: ______________________________________ Renewal / Expiry date: ______________________________________



Part B - To be completed by the non-Sussex Community NHS Foundation Trust employed member of staff and a senior member of the external organisation

Agreement outlining personal responsibility concerning security and

confidentiality of information (relating to patients, staff and the business of the organisation)

Through the duration of this agreement, you may acquire or have access to confidential information which must not be disclosed to any other person unless in pursuit of your duties as detailed in the contract between Sussex Community NHS Foundation Trust and your employer. This agreement includes all confidential information relating to the business of Sussex Community NHS Foundation Trust and person-identifiable information relating to its patients and employees. The Data Protection Laws regulates the use of all personal information and included electronic and paper records of identifiable individuals (patients and staff). Sussex Community NHS Foundation Trust is registered in accordance with this legislation. Any unlawful disclosures of Sussex Community NHS Foundation Trust information may result in legal action for you and your employer.

Declaration:

I the undersigned, understand that I am bound by a duty of confidentiality and agree to adhere to the conditions within the agreement and my personal responsibilities to comply with the requirements of Data Protection Laws and Sussex Community NHS Foundation Trust policies and procedures.

User Agreement

NAME OF ORGANISATION:

PRINT NAME:

NMC/GMC Number (if applicable)

SIGNATURE:

DATE:

CONTACT DETAILS:

Information Governance Training Date completed:

Senior Management Agreement (to be signed by nominated responsible person for the external organisation)

PRINT NAME:

SIGNATURE:

DATE:

CONTACT DETAILS:



A signed copy of this agreement must be retained by the Department and a copy sent to the Information Governance Department

Part C- To be completed by Sussex Community NHS Foundation Trust’s Information Governance Lead

Approval for Access to Person-Identifiable Information

Information Governance / Registration Authority

PRINT NAME:

SIGNATURE:

DATE:

CONTACT DETAILS:

Review Date:________________________________________


Confidentiality Agreement for Students/Trainees on Placement with Sussex Community NHS Foundation Trust

Access to Person Identifiable Information2 and/or Information Systems

2 Purpose In order to ensure effective integrated services and teams these may comprise of students or trainees on placement with Sussex Community NHS Foundation Trust.

This agreement is applicable to persons working in integrated teams, who are not employees of Sussex Community NHS Foundation Trust who need to access, possess or handle confidential information about individuals in order to fulfil the requirements of their role. The agreement outlines that all information concerning patients, staff and the Service is strictly confidential. A breach of confidentiality constitutes serious misconduct and may lead to dismissal. The agreement outlines the responsibilities of both the student/trainee who is accessing confidential information, and the Service or Department who is responsible for providing and monitoring access to their systems (this includes paper-based and electronic systems). 2 Scope This agreement should be read in conjunction with the Sussex Community NHS Foundation Trust policies and procedures that govern the use of information, security and confidentiality. Students and trainees should ensure that they have read and understood these policies and procedures. This agreement applies to all confidential information (whether written, oral or otherwise) of Sussex Community NHS Foundation Trust that needs to be accessed, whether created before or after the date of this agreement. 3 Responsibilities 3.3 All information which may be derived from or be obtained in the course of

working within Sussex Community NHS Foundation Trust or which may come into the possession of the student or trainee must be treated as confidential.

3.4 Sussex Community NHS Foundation Trust policies must be read and

understood and an Information Governance Training session must be undertaken (information regarding this can be obtained through the

2 Definition of Person-Identifiable Data: Data that will identify an individual which may include any item such as

name; address, date of birth; NHS number. For the purpose of this agreement and use of systems, this does not include a member of staff’s name (used in isolation).



Information Governance Department). The Service or Department Lead is responsible for sourcing and arranging the Information Governance Awareness Training.

3.3 Work must only be undertaken by authorised agents of Sussex Community

NHS Foundation Trust who are aware of the requirements of the Data Protection Laws and their personal responsibilities under these laws to maintain the security of Sussex Community NHS Foundation Trust information.

3.4 Except with the prior written consent of Sussex Community NHS Foundation

Trust, no confidential information or any part thereof will be disclosed to any third party. Disclosure will only be made where it is necessary for the performance of tasks, which Sussex Community NHS Foundation Trust has authorised.

3.5 Access to information systems will be provided by Sussex Community NHS

Foundation Trust on receipt of the signed confidentiality agreement. 3.7. Precautions must be taken to ensure the confidentiality of information:

unauthorised access should be prevented by password protection and physical security such as locking cabinets and/or doors when offices are left unattended. Where possible, VDU screens should be positioned so they are visible only to the user. Unwanted paper records should be disposed of safely by shredding on site or use of approved confidential waste methods. No person-identifiable information is to be stored on removable storage devices (eg; CD, floppy disk, USB pens, memory sticks) without prior approval from the Caldicott Guardian. All laptops must be encrypted.

3.7. Any data or information sent from one place to another shall be carried out be

secure means possible. Any transfers of information (outside of daily case management) must be approved by the Caldicott Guardian.

3.8 Information which can identify any patient, or employee of Sussex Community

NHS Foundation Trust can only be transferred electronically if previously agreed by the Caldicott Guardian. This is essential to ensure compliance with strict NHS controls surrounding the electronic transfer of identifiable personal data and information and hence compliance with the Data Protection Laws. This will also apply to any direct-dial access to a computer held database at Sussex Community NHS Foundation Trust.

3.9 Where personal information is recorded in any identifiable form, it shall either

be returned to the Service or Department on completion of the work or disposed of by secure means and where appropriate a certificate of secure disposal to be issued.

3.10 Sussex Community NHS Foundation Trust incident reporting processes must

be followed in respect to situations relating to any breaches of security and/or confidentiality of person-identifiable information.



3.12 Any security breaches will immediately be reported to Sussex Community NHS Foundation Trust Information Governance Department, the Caldicott Guardian and the employing organisation.

3.13 Any agreed reports processed remotely will be checked and released by

Sussex Community NHS Foundation Trust prior to release for correlation. 4 Sussex Community NHS Foundation Trust, Service and External

Organisation Responsibilities 4.6 A senior member (or nominated Caldicott Guardian) of the external

organisation will be responsible for their staff and will ensure that they adhere to Sussex Community NHS Foundation Trust policies and procedures, and take any action necessary in cases of misuse.

4.7 The Service or Department Lead will ensure that access to Sussex

Community NHS Foundation Trust systems is managed appropriately. Regular checks will be undertaken to ensure only staff with current confidentiality agreements have access to systems.

4.8 The Service or Department Lead will ensure that renewal dates are set

appropriately and monitored for inappropriate access and that access is terminated upon the student or trainee ending their placement.

4.9 The Service or Department Lead will grant access to Sussex Community NHS

Foundation Trust information under the attached conditions.

4.10 Sussex Community NHS Foundation Trust will instigate an incident reporting processes for situations relating to any breaches of security and/or confidentiality of personal information.



Part A - Certification form: To be completed by the Service or Department responsible for the non-Sussex Community NHS Foundation Trust employed member of staff.

Name of Service/Department: _____________________________________ Location/Address _____________________________________ _____________________________________ On behalf of the above I certify as follows: Access to patient identifiable information is to be granted to the named below, subject to the terms and conditions in this contract. Access is to be granted for: ______________________________________ (Name) Start date of placement: _________________ End date of placement: __________________

TYPE OF ACCESS (if accessing SystmOne please indicate the name of the unit/s)

COMMENTS

Justification for access to Sussex Community NHS Foundation Trust information:

Signed: ______________________________________ Name: ______________________________________ Position in organisation: ______________________________________ Telephone Number: ______________________________________ Date: ______________________________________



Part B - To be completed by the student or trainee

Agreement outlining personal responsibility concerning security and

confidentiality of information (relating to patients, staff and the business of the organisation)

Through the duration of this agreement, you may acquire or have access to confidential information which must not be disclosed to any other person unless in pursuit of your duties as detailed in your placement with Sussex Community NHS Foundation Trust. This agreement includes all confidential information relating to the business of Sussex Community NHS Foundation Trust and person-identifiable information relating to its patients and employees. The Data Protection Laws regulates the use of all personal information and included electronic and paper records of identifiable individuals (patients and staff). Sussex Community NHS Foundation Trust is registered in accordance with this legislation. Any unlawful disclosures of Sussex Community NHS Foundation Trust information may result in legal action for you and your employer.

Declaration:

I, the undersigned, understand that I am bound by a duty of confidentiality and agree to adhere to the conditions within the agreement and my personal responsibilities to comply with the requirements of Data Protection Laws and Sussex Community NHS Foundation Trust policies and procedures.

User Agreement

NAME OF UNIVERSITY:

PRINT NAME:

NMC/GMC NUMBER (IF APPLICABLE)

SIGNATURE:

DATE:

CONTACT DETAILS:

DATE INFORMATION GOVERNANCE TRAINING COMPLETED

A signed copy of this agreement must be retained by the Department and a copy sent to the Information Governance Department



Part C- To be completed by Sussex Community NHS Foundation Trust’s Information Governance Lead

Approval for Access to Person-Identifiable Information

Information Governance

PRINT NAME:

SIGNATURE:

DATE:

CONTACT DETAILS:

Review Date:________________________________________



APPENDIX 4: CONTACTING THE DIGITAL SERVICE DESK

This can be done on the phone: 4600 (internal) / 0300 303 4600 (07:00-18:00 Monday to Friday) or online through the Pulse: https://servicedesk.scft.nhs.uk/support/catalog/items?category_id=50000010283 Select the relevant Service Category in the menu at the left and then select from the options available

APPENDIX 5: REQUESTING CHANGES TO SYSTMONE

Changes have to be agreed across the service and in some cases across services where the same template or questionnaire is used. The Champion User Group is recommended as a forum to discuss service needs and changes.

1. The Request for Change is raised with a Digital Service Desk call (see Appendix 4). Please select SystmOne as the Service Category and then select the required option

2. The Request for Change is taken to the Change Advisory Board to consider the implications of the change to training, reporting, clinical safety and configuration. The Application Support Team may consult with the service to find the best possible solution.

3. Communication is sent out to inform all relevant users.

NB: changes which are specific to your own team which are not applicable for the rest of your service (e.g. addresses for letters and referrals) can be requested without consultation of the Champion User Group.

APPENDIX 6: SYSTEM-WIDE TASK TYPES

Guidance on how to manage the different system wide task types:

Task Types

https://servicedesk.scft.nhs.uk/support/catalog/items?category_id=50000010283%20%20%20

http://thepulse.sussex.nhs.uk/it/systmone/Task%20Types%20v1.0.pdf



RATIFICATION CHECKLIST IG AND DATA SECURITY GROUP - VIRTUAL

Agenda Item: The meeting administrator should be able to provide this

Procedure Title: SCFT Standard Operating Procedure for SystmOne

Procedure Author: Linda Skinner - Digital Clinical Safety Lead

Presented By: Lindsay Wells Head of Information Governance and Trust Data Protection Officer

Purpose: Ratification

Checklist for Ratification

1. Reason for Review:

Reason for the Procedure review:

a) New Procedure

This procedure combines into one document the previous SystmOne related Standard Operating Procedures which are published on the Pulse and due for review:

Access to SystmOne

Management of Tasks in SystmOne

Medications Sensitivities and Allergies in SystmOne

Recording and Updating Addresses and other Contact Details in SystmOne

Recording Deaths in SystmOne

Recording Safeguarding Concerns in SystmOne

SystmOne Alerts and Reminders

SystmOne: Managing Incorrect Entries in the Electronic Patient Record

SystmOne: Managing Sensitive Demographics

2. Summary

Please give a brief overview of the following: Purpose and scope of document

Purpose: To specify the processes required to ensure safety of patients through standardised use of SystmOne and documentation of information within the SystmOne patient record.

Scope: This document applies to all staff working within SCFT services using SystmOne, including temporary staff and students. It describes: o Access to SystmOne o Creation of Records o Access to Records o Record Sharing o Records Management o Tasks Management o Closing the Record o Discharge and Recording a Death

Any specific exclusions contained within the document (i.e. does not apply to certain staff / areas within the Trust)

Exclusions: This does not apply to staff working within services who are not using SystmOne for their patient records

Please summarise any significant changes from previous versions e.g. in response to new legislation or national guidance

No significant change to the content of the previous SOPs which have been combined into this document



3. Format

Has the standard SCFT template been used?

Yes Comments:

4. Consultation

Name / Group Member Response Y/N

Application Support Team Area Heads of Nursing and Governance Clinical Service Managers Community Nursing Taskforce Community Child Health Information Service Manager Digital Clinical Safety Team Diversity and Inclusion Lead Information Governance Team IT Training Team Medicines Management Team Safeguarding Team

Y- feedback incorporated into SOP

5. Dissemination/Implementation Process

This procedure will be made available on the intranet, and publicised through Contact (the Trust internal electronic newsletter).

6. Cost/Resource Implications

Does this procedure have any cost and/or resource implications?: N

Please provide details of the cost/resource implications: eg training, equipment, additional staff

Has this been agreed by the accountable Director? N/A

Name Job Title Date

7. Approval

Please state the name of the Group that has approved this document?

Name: Health Records Group

Date of Group Approval: Date: 29.11.19

8. Equality Analysis

Has the Equality Impact Assessment been completed?

No Comments: N/A for SOP

9. Review

Please state the timescale for review: 3 yearly



DECISION OUTCOME AND RECOMMENDATIONS

For completion by the Chair of the Group or Committee considering ratification.

Is the Committee / Group satisfied and assured that due process has been followed in order to produce or review the Procedure?

Yes

Comments:

Is the Committee / Group satisfied and assured with the consultation on the Procedure?

Yes

Comments:

Does anybody (Group or individual) else need to be consulted prior to ratification?

No

Please state who:

Other Comments

Outcome:

Was the Procedure Ratified?

Yes

Other comments:

Including strengths and good practice.

Additional actions required for ratification:

Must be SMART

Print Name: Diarmaid Crean

Job Title: Chief Digital and Technology Officer

Date: 17th December 2019

standard operating procedure for systmone

Documents