THE ELECTRONIC STAFF RECORD PROJECT
NATIONAL HEALTH SERVICE M-3992 ESR INTERFACE TO UIM INCIDENT REPORTING GUIDE Author:
Chris Price
Owner:
Paul Spooner
Creation Date:
29 December 2010
Last Updated:
21 June 2011
Version:
v 1.1
Classification:
Commercial in confidence
th st
Approvals:
Name
Paul Spooner
Title
NHS ESR Programme Director (Acting)
Name
Frank Rutley
Title
McKesson ESR Programme Director
M-3992 – ESR Interface to UIM Incident Reporting Guide
1. Document Control Change Record Date
Author
24/01/2011 16/02/2011 21/02/2011 03/03/2011 21/06/2011
Chris Price Chris Price Chris Price Chris Price Chris Price
Version 0.1 0.2 0.3 1.0 1.1
Change Reference Initial Draft Updated following review Updated following review Issued for sign off Updated to incorporate Registration enhancements deployed as part of ESR R11.
Reviewers Name
Position
Paul Spooner Lee Pacey Nick Adcock David Booth Jane Siddle
NHS ESR Programme Director (Acting) ESR NHS Development Manager ESR NHS Senior Development Advisor ESR NHS Interface Team Manager ESR RPP Registrations Project Manager (McKesson) ESR Service Support Manager (McKesson) ESR Service Manager (McKesson)
Patrick Stapleton Andy Parker
Distribution
Release v1.1
Copy No.
Name
Location
1 2
NHS Library Master
NHS RPP Project Library
Commercial in confidence
Page 2 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
2. Contents
1.
Document Control
2
Change Record
2
Reviewers
2
Distribution
2
2.
Contents
3
3.
Introduction
4
3.1.
Background
4
3.2.
Purpose
4
3.3.
Scope
4
3.4.
Assumptions
4
3.5.
Information Resources
5
4.
NHS CRS Smartcard Authentication and ESR Access
6
4.1.
NHS CRS Smartcard Authentication
6
4.2.
Access to ESR
8
5.
Interface Error/Incident Categories
10
5.1.
Business Errors
10
5.2.
Technical Errors
10
6.
Human Resources (HR) Users
11
6.1.
Position Updates
12
6.2.
Person Changes
13
6.3.
Summary
15
7.
Registration Authority (RA) Users
16
7.1.
RA Workbench Authentication Status
16
7.1.
Create/Re-open NHS CRS Person Requests
18
7.1.
Searching NHS CRS via the RA Workbench
19
8.
Worklist and CRS Position Downloads
22
8.1.
Worklists
22
8.2.
NHS CRS Access Control Positions
24
9.
Service Desk Summary
26
9.1.
Incidents raised with the McKesson ESR helpdesk
26
9.2.
Incidents raised with the NHS CfH service desk
26
10.
Appendix A – UIM Error Catalogue
Release v1.1
Commercial in confidence
27
Page 3 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
3. Introduction 3.1. Background Following the activation of the ESR Phase 2 Registrations functionality (including the bi-directional interface with UIM), a dependency is created on NHS Connecting for Health (NHS CfH), McKesson and the NHS ESR Central Team to address any incidents (user encountered problems) experienced and reported by the ESR user community during „business as usual‟ processes. The Registrations Partnership Project (RPP) deliverables include software components supplied by McKesson (ESR) and NHS CfH (User Identity Manager (UIM)). These software components have a high level of integration that is mostly seamless from the end user perspective. As McKesson and NHS CfH have their own service desks with different call logging processes, it was necessary to create an incident user guide to enable the user community to make informed decisions as to which service desk an incident should be raised. It is important for the user community to understand which components of the integrated solution are supported by each supplying organisation, this will ensure support calls are raised with the appropriate service desk and facilitate the timely resolution of reported incidents.
3.2. Purpose The purpose of this document is to provide an incident reporting guide to all NHS Organisations that have activated the ESR interface to UIM. It is not the intention of this document to create a new service desk reporting process; rather define the steps required for all NHS Organisations to utilise the current call logging procedures for both the McKesson ESR helpdesk (in line with the S-2350 ESR Help Desk User Guide for Live Customers available via kbase) and NHS CfH service desk. A quick reference error catalogue is also included within Appendix A providing guidance in the event of an error message relating to the interface being displayed in ESR.
3.3. Scope This document is intended for use by all NHS Organisations that have activated the ESR interface to UIM. The content is aimed specifically at the ESR user community in particular, but not limited to the Human Resources (HR) and Registrations Authority (RA) personnel. Components of the Registrations delivery that are considered to be within the scope of this guide are: -
Issues encountered with Smartcard authentication; Failure to access ESR following successful Smartcard authentication; Any updates to ESR forms and functionality introduced to facilitate integration with UIM; Issues relating to the ESR RA Workbench; Concurrent requests in ESR to facilitate the download of NHS CRS Access Control Positions and Worklists from UIM.
Any issue that manifests as a direct result of a local Desktop, Network or general Information Technology (IT) failure is outside the scope of this document. Any issues of this nature should be immediately raised with local IT helpdesks or IT service providers. Any incidents reported in UIM are also outside the scope of this document and should be raised with the NHS CfH service desk following local process/procedure.
3.4. Assumptions This document is aimed at those NHS Organisations that have implemented the ESR interface to UIM as part of their strategic approach to Integrated Identity Management (IIM). Therefore this document assumes: -
The ESR interface to UIM has already been activated at the NHS organisation. This would have involved a request being submitted to esr.smartcard@nhs.net and the successful completion of setup activities in UIM and ESR prior to activation. For further details regarding interface activation please refer to the IIM Initiation Guide which can be found at http://www.electronicstaffrecord.nhs.uk/esr-projects/integrated-identity-management/.
Release v1.1
Commercial in confidence
Page 4 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
3.5. Information Resources This section provides browser links to the entire IIM information repository. For further information regarding the project and its objectives, please refer to the websites/toolkits below. Title ESR-RPP0005 ESR interface to UIM implementation approach guide ESR-RPP0006 A quick reference guide to activating the ESR interface to UIM ESR-RPP0007 ESR set up pre-interface activation quick reference guide
ESR-RPP0008 ESR set up post interface activation quick reference guide
ESR online user manual
ESR Kbase ESR e-Learning Captivates ESR Integrated Identity Management website
UIM Implementation Guide (Link accessible via N3)
Developing a strategy for Integrated Management (Link accessible via N3) HR/RA Process Integration toolkit (Link accessible via N3)
Identity
Position Based Access Control (PBAC) Toolkit (Link accessible via N3) NHS CfH Integrated Identity Management website (Link accessible via N3) S-2350 ESR Help Desk User Guide for Live Customers
McKesson Information Point (MIP)
Release v1.1
Purpose Provides guidance regarding the implementation of the ESR interface to UIM. Provides an overview of the technical steps required to activate the ESR interface to UIM. Provides instructions regarding the ESR set-up activities that must be completed no later than 2 weeks prior to the activation of the ESR interface to UIM. Provides instructions regarding the ESR set-up activities that must be completed as soon as possible following the activation of the ESR interface to UIM. The standard ESR user manual covering all aspects of using the ESR solution including the new interface and RA functionality. Information repository containing ESR learning material and guidance. E-learning tools covering the end to end processes between ESR and UIM All user documentation regarding the ESR interface to UIM is available via the ESR website http://www.electronicstaffrecord.nhs.uk/esrprojects/integrated-identity-management/ Provides instructions regarding the UIM set-up activities that must be completed no later than 2 weeks prior to the ESR set-up activities being undertaken. Provides the structure to key decisions that need to be made by NHS organisations to realise the benefits of Integrated Identity Management. Helps NHS organisations move towards the integration of business processes between Human Resources and RAs, or between RAs and other identity capture processes. Describes how to simplify the assignment of access rights to the NHS CRS. All user documentation for UIM is on the NHS CfH NWW web site. This document describes the support provided to enable ESR Users to make best use of the services provided by McKesson UK under contract to the Department of Health. The McKesson Information Point is a self help knowledge based content management system which aims to provide up to date information on service support matters as a first line support point of call. The online service can be accessed by ESR Remedy users.
Commercial in confidence
Page 5 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
4. NHS CRS Smartcard Authentication and ESR Access There are two aspects of using an NHS CRS Smartcard that need to be addressed separately. Depending on where the user has a problem will determine which service desk the incident should be raised with. In summary, these activities are split between: 1) 2)
Smartcard authentication and; ESR access following successful Smartcard authentication.
These two activities are managed by a combination of events using software provided by both NHS CfH and McKesson. Identifying the point of failure is therefore critical in determining which service desk should be contacted in the event of any problems being experienced.
4.1. NHS CRS Smartcard Authentication Immediately following insertion of a Smartcard into the Smartcard Reader, the user should be presented with the following dialogue box and asked to enter their pass code.
If an older version of the Identity Agent (IA) software is installed then the following may be presented instead.
Release v1.1
Commercial in confidence
Page 6 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
If neither of these dialogue boxes are presented then there is likely to be a local problem with either the Desktop configuration (for example the IA software has not been installed onto the Desktop) or a local network error that is preventing the desktop from communicating with the Spine services over the NHS N3 network. This should be referred to local IT service desks and the local RA lead for resolution. Following the entry of the pass code into either of the previous dialogue boxes, and clicking the acceptance to proceed buttons, correct authentication is confirmed by the following “pop up” screen being presented to the user in the bottom right hand corner of the screen.
If the above “pop up” screen is not presented then the user has not been authenticated against the Spine and will not therefore be able to access ESR. If this screen is not displayed then this must be referred to local RA leads in the first instance to verify the validity of the Smartcard. If the Smartcard is valid, local IT service desks should confirm there are no network or communication issues at the organisation. If the Smartcard is valid and there are no known local network/communication issues but the user is unable to authenticate, then an incident should be raised with the NHS CfH service desk following local process/procedure. Note: Authentication can also be confirmed by placing the cursor over the IA icon on the bottom right hand side. The IA software will then provide the authentication status as shown below. „ACTIVE‟ confirms authentication has been successful.
Identity Agent (IA) icon „IDLE‟ confirms authentication has not been successful.
Identity Agent (IA) icon
Release v1.1
Commercial in confidence
Page 7 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
4.2. Access to ESR Following successful Smartcard authentication, ESR users are able to access ESR using the following link: https://esr.mhapp.nhs.uk/OA_HTML/xxnhs/smartcard/esrSmartcardLauncher.jsp If there are no issues with entry to ESR the user will be presented with the following dialogue box:
The above dialogue box is used by ESR to monitor that the user has valid access rights; the closure of this dialogue box will log the user out of ESR. The user will then be presented with the following depending on their existing access rights to ESR: If the user has one and only one ESR User account, and it is NHS CRS Smartcard enabled, then the user will be logged directly into ESR and presented with the main ESR Application menu as per the screen print below.
Release v1.1
Commercial in confidence
Page 8 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
If the user has more than one ESR User account and at least one ESR User account has been NHS Smartcard enabled, then they will be presented with a screen similar to the following and will need to select the required account.
If the user is not presented with either of the above screens access to ESR via Smartcard has been unsuccessful. The NHS CRS Smartcard familiarisation document available via http://www.electronicstaffrecord.nhs.uk/esr-projects/integrated-identity-management/ provides an overview of common problems and resolutions that have been identified during the deployment of Smartcards to ESR users. If it is not possible to determine the cause of the issue after reviewing the NHS CRS Smartcard familiarisation document then an incident should be raised with the McKesson ESR helpdesk via an organisations named Remedy user. Any error messages that are displayed should be captured in a screen print and added directly into the Remedy call to enable the service desk analysts to direct the call to the relevant team as efficiently as possible.
Release v1.1
Commercial in confidence
Page 9 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
5. Interface Error/Incident Categories Following the activation of the ESR interface to UIM it is possible that errors relating to interface functionality may be reported by ESR. These errors can be broadly categorised into business errors and technical errors.
5.1. Business Errors Business errors are typically identified as those that are reported by ESR and action can be taken by users to rectify the problem. Business errors are reported to ESR users via workflow notifications or via the RA workbench and largely made up of: a) Data errors caused by the format of data held in ESR not matching the validation required by UIM to function correctly (please refer to Appendix A for the error catalogue and action required). The vast majority of these errors will contain a clear „English‟ description (i.e. not technical) providing instructions of the actions required to resolve the error. b) Requests being rejected by an RA Agent in UIM. The RA Agent will typically provide the reason for the message being rejected which will be displayed in the ESR workflow notification. Business errors are reported via ESR workflow notifications or the RA Workbench and the majority can be resolved locally without intervention by the McKesson ESR helpdesk or NHS CfH service desk. As a rule, if it is not possible to correct the business error (following discussion with local RA personnel), an incident should be raised with the McKesson ESR helpdesk by the local named Remedy user.
5.2. Technical Errors Technical errors are typically those generated where a communication or technical error has occurred within the infrastructure. These could be generated by network failures, server failures (such as a database being unavailable) and messages not meeting the formatting standards imposed by each respective system. As ESR and UIM are both national NHS CRS compliant systems communicating through the NHS N3 network, local technical issues, such as local connection with N3, will need to be identified and resolved by local IT service desks. These kinds of errors will typically be identified at the point of authentication as described in section 4. Any technical errors encountered with ESR and UIM will be identified by the alert and monitoring processes that have been put in place to ensure connectivity is maintained at all times, excluding planned downtime. ESR and UIM will automatically detect when either system has encountered an outage (or loss of communication) and create a high priority incident directly to the McKesson technical teams to address (including referral to the NHS CfH service desk if required, see section 9). If any user experiences an unexpected loss of the ESR system and this is not due to local network/communication problems then this should be immediately reported to the McKesson ESR helpdesk by the local named Remedy user. Users should however try to re-authenticate and access ESR first, to confirm that the system is unavailable. If an unexpected loss of access to UIM is experienced, and this is not due to local network/communication problems then this should be raised immediately with the NHS CfH service desk following local process/procedure. Users should attempt to re-authenticate and access UIM first, to confirm that the system is unavailable.
Release v1.1
Commercial in confidence
Page 10 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
6. Human Resources (HR) Users Although one of the underlying benefits of IIM is the integration of HR and RA processes, this is not a prerequisite for the activation of the ESR interface to UIM. Consequently it is possible for HR and RA departments to have access to different areas of ESR functionality following the activation of the ESR interface to UIM. This section is applicable to ESR HR users regardless of whether they have access to the RA Workbench via the following User Responsibility Profiles (URPs). XXX HR Administration (With RA) XXX HR Data Entry (With RA) XXX RA Workbench XXX Recruitment and Applicant Enrolment Administration (with RA) This document is not intended as a functionality user guide and therefore assumes that the reader is familiar with the ESR functionality and terminology. This section specifically covers Position and Person updates, completed from the standard ESR forms. In order for Position and Person updates to be communicated to UIM via the interface it is necessary for the ESR person record to have a UUID, identity checked to e-GIF level 3 and associated to the appropriate NHS CRS Person record. This can be checked by navigating to the appropriate person record and selecting „View Photo from NHS CRS‟ from the Tools menu. If the Person record in question has not been associated with NHS CRS then the error message below will be displayed.
This can be rectified by undertaking the identity checks in ESR and then associating the ESR person record to the corresponding NHS CRS person record via the RA Workbench. The association can be completed by users with access to the RA User Responsibility Profiles (URPs). For further details regarding this process please refer to the ESR e-learning captivate sessions.
Release v1.1
Commercial in confidence
Page 11 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
6.1. Position Updates For ESR person records that are associated with NHS CRS, the following activities will result in a message being sent to UIM to either grant or revoke NHS CRS access rights: -
Linking an ESR Position to an NHS CRS Access Control Position; Unlinking an ESR Position from an NHS CRS Access Control Position; Assigning the ESR person record to an ESR position that is linked to an NHS CRS Access Control Position; Removing the ESR person record from an ESR position that is linked to an NHS CRS Access Control Position; Terminating the employment of the ESR person record; Changing the assignment status from „Active‟ to „Inactive‟ and vice versa.
For further details regarding the transactions in ESR that will result in messages being sent to UIM please refer to the ‘ESR-RPP0009 ESR Interface to UIM Business Process Scenarios’ document. The screen print below illustrates an ESR assignment to a position linked to an NHS CRS Access Control Position.
For „HR only‟ ESR users (i.e. ESR users without access to the RA Workbench) the changes to NHS CRS access rights, as conveyed by the NHS CRS Access Control Position(s), are invisible and do not require intervention from the RA Agent to approve the request in UIM. The transaction should therefore update both systems in near real time (there will be a few seconds delay due to processing time). If there has been a processing error, then this will trigger a workflow notification to be sent to the ESR user(s) that is assigned the „NHS CRS RA Agent‟ Notification role with the Subject of “CRS Business Error”. Opening the notification will give the user further details as to the cause of the failure. Business errors will mainly be attributed to data cleansing issues, therefore correcting these and making the update in ESR should resolve the issue. The CRS Error code present in the notification can be matched with the code found in the attachment embedded in Appendix A, this gives further guidance on resolving/escalating the incident. If it is not possible to resolve the problem then this should be raised with the McKesson ESR helpdesk via the local named Remedy user. If UIM does not acknowledge receipt of the message sent by ESR within 2 hours then a notification will be automatically sent to the ESR user(s) assigned the „NHS CRS RA Agent‟ Notification role with the Subject of “CRS Business Error” as illustrated below. Release v1.1
Commercial in confidence
Page 12 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
Opening the notification will provide details of the request and that acknowledgement has not been received from UIM. The messages will be sent every two hours.
If an ESR user receives the above workflow notification then this should be raised with the NHS CfH service desk following local process/procedure.
6.2. Person Changes For ESR person records that are associated with NHS CRS, the amendment of the following person details in ESR will result in a message being sent to UIM to update the corresponding person record in NHS CRS: Title Surname First name Middle name NI Number Date of Birth Email address (Person Form) Work phone number (Phones Form) Work mobile number (Phones Form)
Release v1.1
Commercial in confidence
Page 13 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
When an amendment is made in ESR the request is placed on a Worklist (or queue) in UIM and must be approved by an RA Agent (in UIM) before the change is applied. The granting of the request is a manual process and may therefore take several days depending on local RA processes. If however the request is not granted in UIM within 7 days then a workflow notification will be sent to ESR users with the „NHS CRS RA Agent‟ notification role as illustrated below.
Upon receipt of the above notification the first point of escalation should be for the RA Agent to grant the request in UIM. If the request has been granted, but the above notification is received, then a call should be raised with the NHS CfH service desk following local process/procedure. If there has been a processing error, then this will trigger a workflow notification to be sent to the ESR user(s) assigned the „NHS CRS RA Agent‟ Notification role with the Subject of “CRS Business Error”. Opening the notification will give the user further details as to the cause of the failure. Business errors will mainly be attributed to data cleansing issues, therefore correcting these and making the update in ESR should resolve the issue. The CRS Error code present in the notification can be matched with the code found in the attachment embedded in Appendix A, this gives further guidance on resolving/escalating the incident. If it is not possible to resolve the problem then this should be raised with the McKesson ESR helpdesk via the local named Remedy user. The following screen details a Person update that has received a notification with a Business error. In this example the message has failed because the employees name contains invalid characters. This can be resolved by removing the “” from the surname in ESR which will result in a further message being sent to UIM.
Release v1.1
Commercial in confidence
Page 14 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
6.3. Summary -
-
-
-
If the ESR user is given incorrect access rights after being assigned a position in ESR that is linked to an NHS CRS Access Control Position, this must be immediately escalated to the local RA team. It may be that the NHS CRS Access Control Position in UIM has been incorrectly defined, or incorrectly linked to an ESR Position. If a Position update is made in ESR but a workflow notification is reported stating that a UIM notification has been outstanding for 2 hours then a support call should be raised with the NHS CfH service desk. If an ESR workflow notification is received stating that a UIM grant has been outstanding for 7 days, this should be escalated to the local RA team for granting. If the RA person responsible for granting the person update in UIM states that the request has already been granted, raise with the NHS CfH service desk. If a workflow notification reports an error, first try and resolve locally depending on the error details using the error catalogue in Appendix A, otherwise raise a support call with the McKesson ESR helpdesk. If the notification states that the person update has been rejected, then refer to the RA person responsible for granting the request in UIM.
Any issues encountered with the general use of the ESR forms should be raised with the McKesson ESR helpdesk as per the existing process.
Release v1.1
Commercial in confidence
Page 15 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
7. Registration Authority (RA) Users Although one of the underlying benefits of IIM is the integration of HR and RA processes, this is not a prerequisite for the activation of the ESR interface to UIM. Consequently it is possible for HR and RA departments to have access to different areas of ESR functionality following the activation of the ESR interface to UIM. For the avoidance of doubt, this section is specifically aimed at users who DO have access to the RA Workbench via the RA User Responsibility Profiles (URPs). For these users, there is a set of additional functionality and web based forms that are used to communicate directly with UIM, in line with current RA responsibilities and actions. This document is not intended as a functionality user guide and therefore assumes that the reader is familiar with the ESR functionality and terminology. The ESR RA functionality which can be accessed by the URPs listed below allows ESR users to search UIM for NHS CRS person records, associate ESR person records to NHS CRS person records (and remove the association), Create NHS CRS Person records and Reopen NHS CRS person records that are „closed‟. Error messages regarding these activities are reported via the NHS CRS Authentication Status within the RA Workbench in addition to Workflow notifications. XXX HR Administration (With RA) XXX HR Data Entry (With RA) XXX RA Workbench XXX Recruitment and Applicant Enrolment Administration (with RA)
7.1. RA Workbench Authentication Status The advantage of using the RA Workbench is that the status of the message request can be easily identified under the field “NHS CRS Authentication Status” (please refer to the screen print below).
Release v1.1
Commercial in confidence
Page 16 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
The various statuses reported via the RA workbench are as follows: -
-
Not associated – means that the ESR person record is not associated with an NHS CRS person record; Associated – means that the ESR person record is associated with an NHS CRS person record; Request Pending – means that a request has been submitted by an ESR user but it has not yet been delivered to NHS CRS. Confirmation should be sent instantly, if this status does not change within a few minutes then a support call should be raised with the McKesson ESR helpdesk via an organisations local named Remedy user. Request Rejected – Means that a request has been rejected by NHS CRS due to either a Technical or Business error. Awaiting NHS CRS - means that a request is awaiting approval by an RA Agent in UIM. Any requests that stay at this status should be escalated to the RA team to action. Awaiting ESR action – means that NHS CRS has completed the request successfully, and further action is required in ESR. For example, a new person has been created or re-opened on NHS CRS as a result of a “Create/Re-open NHS CRS Person” request, so now the user can complete the operation by performing an „association‟ in ESR.
In order to view further details of the NHS CRS Authentication status select the appropriate request by double clicking the “show” link under the “Details” column.
Release v1.1
Commercial in confidence
Page 17 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
Further details, similar to the screen print below, will then be displayed. This particular example shows a „Create new user‟ request that has been rejected by the RA Agent in UIM. The reason for the rejection is stated within the notification.
7.1. Create/Re-open NHS CRS Person Requests There are two workflow notification roles available in ESR which ensure ESR users are notified of any errors returned from UIM in relation to „Create NHS CRS Person‟ and Re-open NHS CRS Person‟ requests: The role “NHS CRS Add Employee Errors” will receive workflows related to Employees and External Shared Service Staff; The role “NHS CRS Add Applicant Errors” will receive workflows related to Applicants. If a request to „Create NHS CRS Person‟ or „Re-open‟ NHS CRS Person‟ is rejected by UIM the NHS CRS authentication status will be set to „Rejected‟ on the RA Workbench and a workflow notification sent to ESR users assigned the above roles (as illustrated below).
The CRS Error code present in the notification can be matched with the code found in the attachment embedded in Appendix A, this gives further guidance on resolving/escalating the incident. If it is not possible to resolve the problem then this should be raised with the McKesson ESR helpdesk via the local named Remedy user. Release v1.1
Commercial in confidence
Page 18 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
7.2. Searching NHS CRS via the RA Workbench In order to associate an ESR person record with an NHS CRS person record, a search must first be performed against NHS CRS to find the appropriate record. The search can be undertaken via the RA workbench which includes the following tabs: -
-
-
Employees Associated with NHS CRS – This tab allows for the identification of ESR person records that are assigned ESR positions linked to NHS CRS Access Control Positions but have not been associated with NHS CRS; Employees with Protected Responsibilities – This tab allows for the identification of ESR person records that have access to ESR User Responsibility Profiles (URPs) that have been locked down (known as „protected‟ URPs) but are not associated with NHS CRS; All Employees – This tab allows any ESR employee to be queried, even those that are not linked to NHS CRS Access Control Positions or have access to protected ESR URPs.
The required ESR person record must first be identified using the search criteria within the tabs detailed above. This will then return the closest matching ESR records as illustrated below.
The ESR functionality will not allow a search to be performed against NHS CRS that is not e-GIF level 3 in ESR. If the employee is e-GIF level 3 validated then the „search/lookup NHS CRS‟ icon will be highlighted (if not, this will be dimmed and cannot be selected). Selecting a record by clicking on the “Search/Lookup NHS CRS” icon will navigate the ESR user to one of two screens: -
If the NHS CRS UUID is not populated, the RA Agent is taken to the NHS CRS Search screen. If the NHS CRS UUID is populated in ESR, it will be used to perform a direct lookup against NHS CRS and the RA Agent will be displayed with the NHS CRS Person details screen.
Release v1.1
Commercial in confidence
Page 19 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
NHS CRS Search Screen If the search against NHS CRS is successful then a number of potential matches will be returned from UIM as per the following screen print. A maximum of 10 results will be returned by UIM.
If no records are returned, contact an RA agent with UIM access to check that the necessary record exists in UIM (ONLY if you are sure that the employee does exist in UIM). If confirmation is received that the employee does exist in UIM then an incident should be raised with the McKesson ESR helpdesk via the local named Remedy user. If no valid records exist on NHS CRS then a new user should be created via the „Create NHS CRS Person‟ button. This will send a request to UIM to create a person records and, when granted in UIM, will be returned in subsequent searches. If the employee to be associated is present in the list then they must have a photograph. If the photograph is not displayed, then this must be raised with the RA team and the association must not be made. All employees are required to have a photograph in order to confirm their identity. Once the appropriate person record (as verified from their picture) is identified, they can be associated to the current ESR record by clicking on the photograph which will present the NHS CRS Person details screen. NHS CRS Person Details Screen The NHS CRS Person Details screen provides the ESR user with the person details held in NHS CRS as shown in the screen print on the following page. ESR users are able to undertake the following actions from this screen (dependant on the status of the NHS CRS person record): -
Associate Person Remove Association Re-open NHS CRS Person
Release v1.1
Commercial in confidence
Page 20 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
Any issues encountered with the RA workbench screens (i.e. screens not working as expected) should be raised with the McKesson ESR helpdesk via the local named Remedy user. Note: It is also possible for users to perform a search against NHS CRS via the ESR assignment form. This can be undertaken by navigating the ESR assignment and selecting „Search User on NHS CRS‟ from the Tools menu. This search can only be undertaken if the ESR person record has been e-GIF level 3 validated and will search for matching records on NHS CRS returning potential matches in the same way outlined above.
Release v1.1
Commercial in confidence
Page 21 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
8. Worklist and CRS Position Downloads As part of the ongoing maintenance of the ESR interface to UIM two concurrent requests have been created to allow for the download of Worklists and NHS CRS Access Control Positions as they are defined in UIM. The requests can be run by users with the „XXX Local Workstructures Administration‟ URP. -
NHS CRS Maintain Worklists NHS CRS Maintain Templates
Once downloaded to ESR, these can then be assigned to individuals (in the case of NHS CRS Access Control Positions and organisations (in the case of Worklists) as applicable. These jobs can only be run once in any 24 hours and will only run out of core hours (i.e. they will be temporarily placed on hold if run within core hours). The concurrent requests should only be run if new worklists/NHS CRS Access Control Positions are defined in UIM and will download those that are relevant to the NACS/ODS defined for the VPD (Virtual Private Database) in ESR.
8.1. Worklists The Worklist request is called “NHS CRS Maintain Worklists”. Submitting this request (as shown below) will trigger a download from UIM, to obtain all of the Worklist values created under a particular NACS/ODS. As with all ESR batch requests, it is possible to search for the concurrent request that has been submitted (via the view requests menu item), and identify whether it has completed normally (Status = Normal), completed with warnings (Status = Warning and request will be highlighted in yellow) or not completed (Status = Error and request will be highlighted in red).
To check that the request has completed as expected (Status = Normal or Warning) display the completion report by highlighting the request and clicking the „view output‟ button. The request will produce two reports; the first will detail the NACS codes that ESR has selected to be downloaded, as shown in the first Release v1.1
Commercial in confidence
Page 22 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
screen print below; the second will detail all of the Worklist values that have been downloaded into ESR, as per the second screen print. Any Worklists that have been updated will be clearly marked in the detailed report.
Release v1.1
Commercial in confidence
Page 23 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
Note: Following the worklist download a workflow notification will also be sent to the ESR user submitting the request as shown below. The notification can be opened and a report detailing the worklists that have been downloaded displayed.
If Worklists have been created or amended in UIM, and these do not appear in the completion report then this should be raised with the McKesson ESR helpdesk via the local named Remedy user. Please note that the Worklist request can only be run once in any 24 hour period and will run outside out of core hours. Allowances must therefore be made for this.
8.2. NHS CRS Access Control Positions The NHS CRS Access Control Positions request is called “NHS CRS Maintain Templates”. Submitting this request (as shown below) will trigger a download from UIM, to obtain all of the NHS CRS Access Control Positions created under a particular NACS/ODS. As with all ESR batch requests, it is possible to search for the concurrent request that has been submitted (via the view requests menu item), and identify whether it has completed normally (Status = Normal), completed with warnings (Status = Warning and request will be highlighted in yellow) or not completed (Status = Error and request will be highlighted in red).
Release v1.1
Commercial in confidence
Page 24 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
To check that the request has completed as expected (Status = Normal or Warning) display the completion report by highlighting the request and clicking the „view output‟ button. The request will produce two reports; the first will detail the NACS codes that ESR has selected to be downloaded; the second will detail all of the NHS CRS Access Control Positions that have been downloaded into ESR, as per the screen print below. Any NHS CRS Access Control Positions that have been updated will be clearly marked in the detailed report.
Note: Following the NHS CRS Positions download a workflow notification will also be sent to the ESR user submitting the request. The notification can be opened and a report detailing the worklists that have been downloaded displayed. If NHS CRS Access Control Positions have been created or amended in UIM, and these do not appear in the completion report, then this should be raised with the McKesson ESR helpdesk via the local named Remedy user. Please note that the NHS CRS Access Control Position request can only be run once in any 24 hour period and will run outside out of core hours. Allowances must therefore be made for this.
Release v1.1
Commercial in confidence
Page 25 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
9. Service Desk Summary Following the introduction of the ESR interface to UIM, changes have been introduced to the ESR service model in order to accommodate the possibility that incidents may need to be passed between the McKesson ESR helpdesk and NHS CfH service desk, and that the two organisations may need to work together in order to resolve issues. As previously stated the purpose of this guide is to assist ESR users in determining which service desk incidents should be logged with. This section describes what happens to calls once they have been logged with a service desk.
9.1. Incidents raised with the McKesson ESR helpdesk It is anticipated that incidents will be resolved within the Service Level Agreements (SLAs). Where calls cannot be resolved, they will initially be passed to the ESR technical teams for further analysis. If the incident relates to ESR functionality then this will be prioritised and worked on as applicable. If the ESR technical teams deem that the incident is caused by software outside of the ESR domain, then the Registration support model will be invoked as described below. A new Remedy queue has been created within the NHS ESR Central Team. This queue will be managed by members of the NHS Central Development and NHS ESR Data Teams who will act as a central contact point between the organisation that has reported the incident, the McKesson ESR helpdesk and the NHS CfH service desk. Once the McKesson technical teams have completed their analysis and identified that the call is not related to ESR functionality then the call will be passed to the NHS ESR Central Teams queue. Once received, the issue will be raised with the NHS CfH service desk. Any additional information required by the NHS CfH service desk will be made to the raising organisation via the NHS ESR Central Team. This also applies to questions that NHS CfH may have for the McKesson technical teams. If NHS CfH deems that the call is in fact related to ESR, then the Remedy call will be passed back to the McKesson technical teams instructing them to speak directly to the NHS CfH technical teams to expedite the resolution. If NHS CfH resolves the incident then the raising organisation will be notified via the NHS ESR Central Team, the Remedy call will then be passed for closure in the usual manner.
9.2. Incidents raised with the NHS CfH service desk The NHS CfH service desk will investigate the incident and if it relates to UIM or NHS CRS functionality then this will be addressed as appropriate within existing CfH SLAs. If after analysis the NHS CfH technical teams deem that the incident is caused by software outside of the NHS CRS/UIM domain, then the Registration support model will be invoked as outlined below. The NHS CfH service desk will raise a support call with the McKesson ESR helpdesk. NHS CfH will effectively be the customer/client of the call and liaise directly with the organisation that initially raised the call with the NHS CfH service desk if required. Any additional information required by the McKesson ESR helpdesk will be made to NHS CfH service desk which will liaise with the NHS organisation that raised the initial support call. If the outcome of the McKesson investigation is that the issue relates to ESR then a resolution will be addressed as appropriate. If the McKesson investigation determines that the support call requires resolution by NHS CfH then supporting evidence will be attached to the McKesson support call and passed to NHS CfH for further investigation and closure. Note: The service model described above is currently under review. Any changes to the service model will be communicated upon completion of the review.
Release v1.1
Commercial in confidence
Page 26 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
10. Appendix A – UIM Error Catalogue The spreadsheet embedded below lists the errors that UIM can return to ESR in the event of a message failure. This spreadsheet can be used as a guide to interpret how to address a message failure, be this by local data cleansing (if for example a name is too long) or by raising a call with the McKesson helpdesk or NHS CfH service desk as appropriate.
UIM error catalogue v0.1.xls
The spreadsheet contains a column named “Error code sent to ESR” and should be used to “look-up” any error codes that are reported via ESR workflow notifications, the RA workbench or NHS CRS person lookups as circled in the screen prints below. The “Action Required” column provides guidance with regards to resolving the incident that has been encountered. Where possible, the Error Code listed should be included with any incidents raised (with either helpdesk) to assist with the analysis and root cause identification. Error code returned via ESR workflow notification
Release v1.1
Commercial in confidence
Page 27 of 28
M-3992 – ESR Interface to UIM Incident Reporting Guide
Error code returned via ESR RA Workbench
Error code returned via NHS CRS Person Lookup performed in ESR
Release v1.1
Commercial in confidence
Page 28 of 28