ESR_Interface_to_UIM_TCS_Guide_v1.2

Version 1 of 27

Electronic Staff Record Implications of the Transforming Community Service (TCS) Programme for the ESR interface to UIM

1. Introduction and Definition Integrated Identity Management (IIM) combines the currently separate processes within Registration Authority and Human Resource teams, for capturing and managing employee identity. Furthermore, IIM introduces greater efficiency when controlling access to records on computer systems linked to the NHS Spine. There are two technical solutions available to support an organisations approach to IIM:

• User Identity Manager (UIM) stand alone; or • UIM and the ESR Interface.

The use of the new tools is a requirement of the NHS Employment Checks section of the ‘Informatics Guidance’, and ‘NHS Operating Framework 2010/11’ which states that NHS organisations should develop action plans to use the UIM and ESR tools, to comply with NHS employment check standards and achieve productivity gains. UIM is the new software for managing Smartcards, which replaced Calendra in March 2011. Organisations were encouraged to adopt UIM before 31st March 2011 as support for Calendra was withdrawn from this date.

The Transforming Community Services (TCS) programme supports the vision of the Government’s White Paper, ‘Equity and Excellence: Liberating the NHS’, to put patients at the heart of the NHS; and provide them with accountability, more choice and better control over their care. TCS is key to the Quality, Innovation, Productivity and Prevention (QIPP) agenda, which is crucial to achieving the efficiency savings set out in the White Paper, whilst continuing to innovate, deliver high quality and increase the focus on prevention and supported self care. TCS is working closely with the Strategic Health Authorities (SHAs) to ensure that Primary Care Trusts (PCTs) separate commissioning of services from provision, commencing April 2011, as smoothly and as effectively as possible.

The TCS programme will have implications for the local configuration of the tools that have been introduced to support IIM (i.e. UIM and the ESR interface). The purpose of this document is to provide an overview of the implications that the TCS Programme may have for organisations that have implemented, or are considering implementing, the ESR interface to UIM as part of their strategic approach to IIM. This guidance compliments, and should be read in conjunction with, the ‘Migration of Spine Smartcard Users OMS Process for User Migration’ document provided by NHS Connecting for Health (CfH).

Version 1 of 27

2. IIM Background Information: Implementing UIM and the ESR Interface IIM allows NHS organisations to make significant cost savings, by combining the parallel activities involved in verifying employee identity, and allowing access to electronic patient records on computer systems linked to the NHS Spine. User Identity Manager (UIM) software, recently made available by CfH, is faster and more efficient and introduces an electronic, paperless system for the NHS.

An interface between the ESR solution and UIM has been developed to support IIM. Human Resource (HR) functions currently update ESR when changes are made regarding an employee’s assignment. The ESR interface to UIM will be triggered by such changes and will automatically update an individual’s access rights to NHS computer systems linked to the NHS Spine; reflecting the needs of their new position. The interface will enable NHS organisations to manage access control via a single point of data entry, i.e. the change to an employee’s position within ESR, thereby generating further savings for the NHS.

IIM requires NHS organisations to clearly understand the positions and associated access rights of all employees. As the NHS continues to transform and modernise, IIM offers organisations a greater ability to respond to structural change quickly and easily, by having a clear understanding of their workforce. NHS organisations should therefore proceed with implementing IIM without delay in line with the Informatics Guidance published alongside the NHS Operating Framework 2010/11. Further details regarding the implementation of IIM are available within the ‘IIM Initiation Guide’ which also includes hyperlinks to more detailed implementation guidance.

3. The ESR interface to UIM In advance of interface activation organisations are required to undertake a number of pre-requisite set-up activities as outlined in the ‘ESR interface to UIM implementation approach guide’. The set-up activities have implications for the way in which messages are sent to UIM post interface activation and is therefore relevant to the TCS discussion.

3.1. Interface pre-requisites and configuration The UUID data load, UIM set-up and ESR set-up are fundamental pre-requisite activities and dictate how messages are sent to UIM following the activation of the interface;

• UUID Data Load Organisations deploying the interface will have a number of employees in ESR who have access to NHS CRS applications and will therefore already have a record on the Spine User Directory (SUD). For the ESR interface to function, the employee records in ESR need to be matched and then linked to their equivalent records in the Spine User Directory (SUD). The actual link between the two systems at employee level is achieved by adding the Unique User Identifier (UUID) from the SUD record into the ESR employee record.

Organisations requesting activation of the interface are offered a free data load service by the NHS ESR Data Team. This facilitates the loading of the UUID and e-GIF flag into ESR, for all matching records between ESR and NHS CRS. The data load ensures that all ESR person records are linked to the appropriate record on NHS CRS prior to the activation of the interface. It is not possible for the NHS ESR Data Team to perform UUID data loads post interface activation.

• UIM set-up activities A number of set-up activities need be undertaken in UIM prior to the activation of the interface. The UIM set-up activities include the definition of at least one NHS CRS Access Control Position and Worklist. Worklists, or lists of actions to be addressed, are how users of UIM manage all types of transactional processing related to the granting and revocation

Version 1 of 27

of access for users of NHS CRS applications. For more information on implementing UIM refer to the ‘UIM Implementation Guide’.

• ESR set-up activities Upon completion of the UIM set-up activities, organisations must undertake the ESR set-up activities at their VPD (Virtual Private Database) in advance of the interface being activated. The set-up activities include the download of the worklist(s)1 previously defined in UIM and assigning this to the ESR workstructure hierarchy along with the organisations’ ODS (Organisation Data Service) code. The worklist and ODS code(s) assigned to the ESR workstructure dictate where the ESR interface sends messages following activation as illustrated below. Please refer to Appendix A for further details.

For more information regarding the ESR set-up activities refer to the ‘ESR interface to UIM implementation approach guide’ and ‘ESR set up pre-interface activation quick reference guide’.

3.2. The ESR interface to UIM: How it works Post activation, the ESR interface ‘takes control’ of person details in UIM for all employees on ESR who:

• Are identity checked to e-GIF level 3 (e-GIF flag set to ‘Y’ in ESR) and; • Have a UUID entered against their ESR person record. Following this, a user in UIM cannot make any changes to the person details in UIM (at any organisation), and person detail changes undertaken in ESR will overwrite those held in UIM (following a grant step by an RA Agent in UIM). Additionally, following the activation of the interface the NHS CRS Access Control Positions that have been defined in UIM can be downloaded to ESR and linked to ESR positions. The ESR interface will ‘control’ access rights for all employees on ESR who are assigned to an ESR position which is linked to an NHS CRS Access Control Position. The linking of an ESR position to an NHS CRS Access Control Position will result in existing access rights in UIM (at the ODS code assigned to the ESR workstructure) being overwritten and replaced with the Access Rights conveyed by the NHS CRS Access Control Position(s). Following the position linking of ESR positions to NHS CRS Access Control Positions, the person details and access rights will be controlled by ESR and cannot be edited in UIM, until such time that the employee leaves the organisation (and is terminated on ESR) or no longer has an active assignment to an ESR position that is linked to an NHS CRS Access Control Position. Access rights at other ODS codes not managed via the interface will not be controlled by ESR and can be amended directly in UIM.

1 Worklists, or lists of actions to be addressed, are how users of UIM manage all types of transactional processing related to the granting and revocation of access for users of NHS CRS applications.

ESRVPD 1

UIMODS A

Worklist A

Flow of messages from ESR to UIM/NHS CRS

Version 1 of 27

4. The ESR interface to UIM: Implications of TCS In response to the TCS challenge organisations will undergo restructuring which will result in staff members crossing organisational boundaries. This will need to be reflected in both NHS CRS/UIM (i.e. within the ODS code) and ESR (i.e. within the VPD). The movement of staff within NHS CRS is supported by the NHS CfH ODS Team. The movement of staff within ESR is supported by the ESR Central Team. Further details are provided below:

• NHS CRS/ODS restructure – The NHS CfH Organisation Data Service (ODS) is provided by NHS Connecting for Health. It is responsible for the publication of all organisation and practitioner codes and national policy and standards with regard to the majority of organisation codes, and encompasses the functionality and services previously provided by the National Administrative Codes Service (NACS). The NHS CfH ODS Team also has a set of tools which are used to migrate user roles and profiles between organisations on NHS CRS. These tools are collectively known as the Organisation Migration Service (OMS). As support for Calendra was withdrawn from 31st March 2011, organisations are currently migrating users so that access to NHS CRS applications is managed via UIM or the ESR interface. At the time of the ODS migration it is therefore possible for an organisation to be managing user access to NHS CRS via a combination of Calendra, UIM and the ESR interface. The ‘Migration of Spine Smartcard Users OMS Process for User Migration’ document provides guidance to organisations regarding the migration of users from one ODS code to another, regardless of the system(s) being used to manage access. The migration can be completed manually or facilitated by the NHS CfH ODS Team.

• ESR/VPD restructure – Staff members will also need to be transferred across ESR VPDs and two tools are available to support organisations during this process.

o ESR technical merge/de-merge - A demerge from an ESR perspective can be defined as the complete transfer of a group of employees from one Employing Authority to another (normally under TUPE regulations). The ESR technical de-merge will result in a complete transfer of employees and the removal of their records from the Source Employing Authority VPD. A merge from an ESR perspective is where one or more whole ‘source’ Employing Authorities are joined to a new or existing ‘target’ Employing Authority. The ESR merge/de-merge is a complex process requiring considerable preparatory work by both the Source/Target Employing Authorities and requires the involvement of the ESR Central Team. A technical merge/de-merge is generally recommended where the number of staff transferring Employing Authorities is greater than 1002.

o ESR Inter Authority Transfer (IAT) – The Inter-Authority Transfer (IAT) functionality within ESR is designed to remove the manual processes associated with NHS Staff Transfer Forms and therefore reduce the amount of data entry following the appointment of existing NHS staff from other NHS Organisations. Following an IAT historical records of employees will remain with the Source Employing Authority VPD and limited history will be transferred to the Target Employing Authority VPD. Organisations are able to initiate an Inter Authority Transfer without the involvement of the ESR Central Team. An IAT is generally recommended where the number of staff transferring is less than 100.

The movement of staff across NHS CRS ODS codes and ESR VPDs is likely to take place within differing timeframes. Local configuration changes will therefore need to be applied to the ESR interface to ensure functionality remains operational at all times throughout the restructuring process. Subsequent sections of this document provide guidance for those organisations undergoing structural change that have activated, or are planning to activate, the ESR interface to UIM. 2 Subject to ESR merge/de-merge availability/capacity.

Version 1 of 27

4.1. Implications of TCS for organisations that have activated the ESR interface The implications that TCS will have for organisations that have activated the ESR interface to UIM will vary depending on the timing of the ODS restructure relative to the VPD restructure and whether the movement of staff will be facilitated by the ESR technical merge/de-merge or IAT functionality. It is however anticipated that the ODS restructuring will take place prior to the ESR restructuring. The timeline of events is therefore expected to be as follows;

1) Organisations will legally merge prior to the ODS and ESR VPD restructure3. 2) The ODS re-structure will take place prior to the ESR VPD restructure. 3) The ESR VPD restructure will be the final stage of the process.

The conflicting timeframes of the above activities mean that configuration changes will need to be applied in ESR to ensure the interface remains operational at all times. The diagram below depicts the scenario where the provider arm of a Primary Care Trust (PCT) is being transferred to an Acute Trust (although is applicable to other scenarios). The dashed line illustrates the relationship between the ESR VPD and the NHS CRS ODS code to which staff members within each VPD may have access to NHS CRS applications.

`

3 VPD restructure refers to the movement of staff from one ESR VPD to another. This can be facilitated by Inter Authority Transfer (IAT) or technical merge/de-merge. Please refer to section 4 of this document for further details.

VPD 1 (PCT) (Commissioner +

Provider)

VPD 2 (Acute) (Provider)

ODS A(Commissioner

+ Provider)

ODS B (Provider)


Provider)


ODS A(Commissioner)

ODS B (Provider)

ODS B(Provider)

VPD 1 (PCT) (Commissioner)


ODS A(Commissioner)

ODS B

(Provider)

Commissioner and Provider staff are employed at VPD 1 and have access to NHS CRS applications at ODS A. Provider staff employed at VPD 2 have access to NHS CRS applications at ODS B.

Following a legal merge Provider staff at VPD 1 transfer from ODS A to ODS B as part of the ODS restructure. The ESR Employment record however remains at VPD 1 until the ESR restructure is complete.

Provider staff at VPD 1 transfer to VPD 2 as part of the ESR restructure. This is the final stage of the restructuring process from the perspective of the ESR interface to UIM.

Provider arm staff Transfer to VPD 2

Provider arm staff transfer from ODS A to ODS B

Version 1 of 27

There are a number of activities that need to be undertaken by organisations to ensure that the interface remains operational throughout the above restructuring process.

• Step 1 – Source VPD completes an ESR ‘soft split’.

• Step 2 – Undertake the ODS restructure/migration

• Step 3 – Configure ESR following the ODS restructure • Step 4 – Complete the ESR VPD restructure/migration.

Note: If your organisation is planning to undertake the VPD re-structure in advance of the ODS restructure please refer to section 4.2. 4.1.1. Step 1 – Complete the ESR ‘Soft Split’ The NHS ESR Central Team has already instructed NHS organisations to prepare for the forthcoming NHS re-organisation by deploying a ‘soft split’ within ESR by the end of March 2011 (as communicated by ESR User Notice 1241 available from http://esr.novosolutions.net/).

A “soft split” is where a VPD is restructured and the data partitioned by the use of separate Organisational Structures and Payrolls within the single VPD (as illustrated below). This allows the sub-organisations to be represented within ESR as separate organisational units, prior to any technical separation of the data. The ESR soft split also enables each partition of the ESR workstructure hierarchy to be assigned an ODS code - This functionality will be described in subsequent sections of this document and provides ESR with the flexibility of managing access at multiple ODS codes from a single VPD (i.e. following the ODS restructure but before the ESR restructure has taken place). .

Organisations that have already activated the ESR interface to UIM should ensure that staff members being transferred as part of the restructure are assigned NHS CRS Access Control Positions that are unique to the sub-organisation (i.e. NHS CRS Access Control Positions must not be common to staff members remaining with the source organisation). Completing this activity as part of the ‘soft split’ will facilitate subsequent configuration of ESR following ODS restructuring.4

If your organisation has any queries in relation to the completion of the ESR ‘soft split’ then a Remedy support call should be raised with the McKesson helpdesk as soon as possible (via the local named Remedy user at your organisation).

4 This activity need only be completed as part of the soft split for organisations proceeding with Scenario 1/Option 1 and Scenario 2/Option 1 as outlined in step 3 of this document.

VPD 1 (PCT)

VPD1 (Commissioner)

VPD1(Provider)

ODS A (Commissioner

+ Provider)

Soft split completed in ESR which has separated commissioner and provider services within the ESR VPD.

Version 1 of 27

4.1.2. Step 2 – Undertake the ODS restructure The ODS restructure is supported by the NHS CfH ODS Team using the OMS tools to migrate users, associated access profiles and NHS CRS Access Control Positions from one ODS code to another. It is possible that at the time of the ODS restructure user access to NHS CRS applications at a single organisation will be managed by a combination of Calendra, UIM and the ESR interface.

In order to facilitate the migration of users, the NHS CfH ODS Team needs to understand the management system(s) in use within each organisation, and more specifically, which users are associated with each management system. The ‘Migration of Spine Smartcard Users OMS Process for User Migration’ document has been prepared by NHS CfH and details the business process for each type of user migration and the work required by organisations prior to the migration of Smartcard users. The process outlined within this document involves organisations identifying the following:

• Which users need to be migrated; • The management system currently used to manage each user; • Any NHS CRS Access Control Positions requiring migration; • The migration method to be used to transfer a user from one ODS to another.

This document is intended to be read alongside the CfH guidance and provides supplementary information about how the ESR interface to UIM can be configured to accommodate the ODS restructure. The actual transfer of users from one ODS code to another should be completed in line with the business processes and migration methods as defined within the ‘Migration of Spine Smartcard Users OMS Process for User Migration’ document. 4.1.3. Step 3 – Configure ESR following the ODS restructure The way in which the ESR interface to UIM can be configured to accommodate the ODS restructure will be influenced by the interface activation status at both the Source and Target VPD. The various scenarios and configuration options are outlined below. It is only necessary to read the section relevant to the interface activation status of your organisation:

• Scenario 1 - Source VPD and Target VPD have both activated the interface; For users that have transferred from ODS A to ODS B: o Option 1 – Manage person details and access rights at ODS B via the

interface at VPD 1 (recommended option if ESR restructure will be facilitated by ESR merge/de-merge);

o Option 2 - Continue to manage person details and access rights via the interface at VPD1/ODS A and manage access rights at ODS B via UIM or Calendra (recommended option if ESR restructure will be facilitated by IAT).

• Scenario 2 - Source VPD has activated the interface but the Target VPD has not; For users that have transferred from ODS A to ODS B: o Option 1 – Manage person details and access rights at ODS B via the

interface at VPD 1 (recommended option if ESR restructure will be facilitated by ESR merge/de-merge);

o Option 2 - Continue to manage person details and access rights via the interface at VPD1/ODS A and manage access rights at ODS B via UIM or Calendra (recommended option if ESR restructure will be facilitated by IAT).

• Scenario 3 - Source VPD has not activated the interface but the Target VPD has; • Scenario 4 - Neither the Source VPD nor Target VPD have activated the interface.

The following section describes the various ways in which the ESR interface to UIM can be configured to ensure it remains operational throughout the ODS restructure and accurately reflects the movement of staff between ODS codes. The approach adopted by organisations will depend on how access to NHS CRS applications will be managed ongoing. Process flows summarising each of the above scenarios are provided within Appendix C.

Version 1 of 27

Scenario 1 - Source and Target VPD have both activated the interface. The diagram below illustrates the relationship between the ESR VPD and NHS CRS ODS code following the ESR soft split. The interface is active at both ESR VPDs.

There are 2 options available to organisations to accommodate the transfer of users from ODS A to ODS B.

Option 1 – Manage person details and access rights at ODS B via the interface at VPD 1 (recommended option if ESR restructure will be facilitated by ESR merge/de-merge). The transfer of staff members from VPD 1 to VPD 2 is likely to take place after the ODS restructure. In the interim (i.e. following the ODS restructure) the ESR interface to UIM can be configured to ensure access continues to be managed via the interface at VPD 1 for those users that have migrated to ODS B. This can be achieved by entering the appropriate ODS code and worklist against the ESR workstructure hierarchy as illustrated below.

VPD 1(PCT)

Interface Active

VPD1 (Commissioner)

VPD1(Provider)

ODS A(Commissioner

+ Provider)

ODS B (Provider)

VPD 1 (PCT)

Interface Active

VPD1 (Commissioner)

ODS A (Commissioner)

ODS B(Provider)

VPD 2 (Acute)

Interface Active

ODS B (Provider)

Flow of messages from ESR to UIM via the interface



Flow of messages from ESR to UIM via the interface VPD1

(Provider)

VPD 2 (Acute)

Interface Active

ESR hierarchy following the soft split

Predecessor positions

Version 1 of 27

Additional considerations regarding the above configuration.

• NHS CRS access rights and person details for those users that have transferred to ODS B will continue to be managed via the interface at VPD 1 (until the ESR restructure has been completed). Employees not assigned ESR positions linked to NHS CRS Access Control Positions can continue to have access at ODS B managed via UIM or Calendra. Upon completion of the ESR restructure access rights can be controlled via the interface at VPD 2.

• If the users that have transferred to ODS B still require access to ODS A (i.e. for NHS CRS applications that have not yet migrated to ODS B) this can be achieved via the definition of predecessor positions at ODS B in UIM – this will ensure interface driven changes to access at ODS B are also applied to ODS A .

• User access profiles at ODS A for users managed via Calendra, UIM or the ESR interface can be transferred to ODS B by the NHS CfH ODS Team in line with the business process/migration method for each category of user.

• The NHS CfH ODS Team can facilitate the transfer/mapping of NHS CRS Access Control Positions from ODS A to ODS B (i.e. if an equivalent position already exists in the Target ODS).

• The NHS CfH ODS Team can facilitate the copying of NHS CRS Access Control Positions from ODS A to ODS B (i.e. if an equivalent position does not already exist in the Target ODS).

• A number of configuration changes will need to be applied locally in ESR to achieve the above configuration at VPD 1. These configuration changes are outlined below.

Configuration changes required in ESR The activities outlined below need to be completed locally in ESR at VPD1.

• Action 1 – VPD 1 needs to submit a Service Request (SR) for ODS B to be added against VPD 1. This request should be submitted via Remedy no later than 2 weeks prior to the ODS restructure. ODS B must be added to VPD 1 prior to Action 2.

• Action 2 – The NHS CRS Access Control Positions and Worklists defined in UIM (these may have been created/copied by the ODS Team) at ODS B will then need to be downloaded to VPD 1 using the standard ESR interface functionality.

• Action 3 – All users transferring from ODS A who have access managed via the interface must be assigned to NHS CRS Access Control Positions that have been defined in ODS B. This can be undertaken in 2 ways:

o Automatically – If the users are being migrated by the NHS CfH ODS Team, and the migration method is ‘ESR to ESR’, then a file will be generated by NHS CfH which will automatically assign the NHS CRS Access Control Positions in ODS A to the corresponding positions in ODS B.

o Manually – If the migration method is not ‘ESR to ESR’, or the ODS Team is not being used to facilitate the migration, then the users will need to be linked to positions in ODS B manually (via the ESR functionality). This will grant access to the NHS CRS Access Control Position at ODS B.

• Action 4 – When all users have been updated (i.e. assigned positions applicable to ODS B) the ODS code and worklist should be updated at the appropriate level in the ESR hierarchy at VPD 1. Please refer to Appendix A for further details.

• Action 5 – The NHS CRS Supplementary Role and RA Agent Notification Role should be reviewed in ESR at VPD 1 as appropriate.

• Action 6 – Predecessor links should be removed from the NHS CRS Access Control Positions in UIM at a time agreed with ODS A and ODS B.

Refer to Appendix A for essential information regarding the amendment of ODS codes in ESR.

Version 1 of 27

Option 2 – Continue to manage person details and access rights via the interface at VPD1/ODS A and manage access rights at ODS B via UIM or Calendra (recommended option if ESR restructure will be facilitated by IAT).


• Access rights for users that have migrated to ODS B would continue to be sent to ODS A via the interface, until the NHS CRS Access Control Positions have been unlinked from ESR Positions at VPD 1.

• The unlinking of the positions for those users transferring from ODS A must have been completed prior to any subsequent ESR technical de-merge (if access to ODS A is no longer required).

• Person detail updates will continue to be sent to ODS A via the interface following an update to person details at VPD 1 until such time that the ESR restructure has been completed.




• If the users being transferred to ODS B still require access to ODS A (i.e. for NHS CRS applications that have not yet migrated to ODS B) this can be achieved via the definition of predecessor positions at ODS B in UIM. The definition of predecessor positions at ODS B will also provide users with continued access to ODS A and ODS B following an ESR IAT from VPD 1.

• The staff members can be linked to NHS CRS Access Positions in VPD 2 upon completion of the ESR restructure.

Configuration changes required in ESR No additional configuration changes will be required in ESR at VPD 1. However, the users that have transferred to ODS B will need to be unlinked from NHS CRS Access Control Positions at VPD 1 within a timeframe agreed with ODS A and ODS B.

ODS B (Provider)

VPD 1(PCT)

Interface Active

VPD1 (Commissioner)

ODS A


Flow of messages fromESR to UIM via the interface

VPD 2 (Acute)

Interface Active


ODS B(Provider)

VPD1(Provider)

Access managed via UIM

Version 1 of 27

Scenario 2 - Source VPD has activated the interface but the Target VPD has not. The diagram below illustrates the relationship between the ESR VPD and NHS CRS ODS code following the ESR soft split. The source VPD has activated the interface but the target VPD has not.

Following the ODS merge organisations have the following options with regards to the management of users transferring from ODS A to ODS B.

Option 1 – Manage person details and access rights at ODS B via the interface at VPD 1 (recommended option if ESR restructure will be facilitated by ESR merge/de-merge). The transfer of staff members from VPD 1 to VPD 2 is likely to take place after the ODS restructure. During the interim (i.e. following the ODS restructure) the ESR interface to UIM can be configured to ensure access continues to be managed via the interface at VPD 1 for those users transferring to ODS B. This can be achieved by entering the appropriate ODS code and worklist against the ESR workstructure hierarchy as illustrated below.

VPD 1 (PCT)

Interface Active

VPD1 (Commissioner)

VPD1(Provider)

ODS A (Commissioner

+ Provider)

VPD 2 (Acute)

Interface Inactive

ODS B (Provider)



VPD 1 (PCT)

Interface Active

VPD1 (Commissioner)


ODS B(Provider)


VPD1(Provider)

VPD 2 (Acute)

Interface Inactive

ODS B (Provider)




Version 1 of 27


• NHS CRS access rights and person details for those users that have transferred to ODS B will continue to be managed via the interface at VPD 1 (until the ESR restructure has been completed). Employees not assigned ESR positions linked to NHS CRS Access Control Positions can continue to have access at ODS B managed via UIM or Calendra. Upon completion of the ESR restructure access rights can be controlled via the interface at VPD 2.

• If the users that have transferred to ODS B still require access to ODS A (i.e. for NHS CRS applications that have not yet migrated to ODS B) this can be achieved via the definition of predecessor positions at ODS B in UIM – this will ensure interface driven changes to access at ODS B are also applied to ODS A .




• A number of configuration changes will need to be applied locally in ESR to achieve the above configuration at VPD 1. These configuration changes are outlined below.

Configuration changes required in ESR The activities outlined below need to be completed locally in ESR at VPD1.

• Action 1 – VPD 1 needs to submit a Service Request (SR) for ODS B to be added against VPD 1. This request should be submitted via Remedy no later than 2 weeks prior to the ODS restructure. ODS B must be added to VPD 1 prior to Action 2.

• Action 2 – The NHS CRS Access Control Positions and Worklists defined in UIM (these may have been created/copied by the ODS Team) at ODS B will then need to be downloaded to VPD 1 using the standard ESR interface functionality.

• Action 3 – All users transferring from ODS A who have access managed via the interface must be assigned to NHS CRS Access Control Positions that have been defined in ODS B. This can be undertaken in 2 ways:



• Action 4 – When all users have been updated (i.e. assigned positions applicable to ODS B) the ODS code and worklist should be updated at the appropriate level in the ESR hierarchy at VPD 1. Please refer to Appendix A for further details.


• Action 6 – Predecessor links should be removed from the NHS CRS Access Control Positions in UIM at a time agreed with ODS A and ODS B.

Refer to Appendix A for essential information regarding the amendment of ODS codes in ESR.

Version 1 of 27

Option 2 – Continue to manage person details and access rights via the interface at VPD1/ODS A and manage access rights at ODS B via UIM or Calendra (recommended option if ESR restructure will be facilitated by IAT).


• Access rights for users that have migrated to ODS B would continue to be sent to ODS A via the interface, until the NHS CRS Access Control Positions have been unlinked from ESR Positions at VPD 1.

• The unlinking of the positions for those users transferring from ODS A must have been completed prior to any subsequent ESR technical de-merge (if access to ODS A is no longer required).

• Person detail updates will continue to be sent to ODS A via the interface following an update to person details at VPD 1 until such time that the ESR restructure has been completed.

• User access profiles at ODS A for users managed via Calendra, UIM or the ESR interface can be transferred by the NHS CfH ODS Team in line with the business process/migration method for each category of user.



• If the users being transferred to ODS B still require access to ODS A (i.e. for NHS CRS applications that have not yet migrated to ODS B) this can be achieved via the definition of predecessor positions at ODS B in UIM. The definition of predecessor positions at ODS B will also provide users with continued access to ODS A and ODS B following an ESR IAT from VPD 1.

• The staff members can be linked to NHS CRS Access Positions in VPD 2 upon completion of the ESR restructure.

Configuration changes required in ESR No additional configuration changes will be required in ESR at VPD 1. However, the users that have transferred to ODS B will need to be unlinked from NHS CRS Access Control Positions at VPD 1 within a timeframe agreed with ODS A and ODS B.

ODS B (Provider)

VPD 1 (PCT)

Interface Active

VPD1 (Commissioner)

ODS A



VPD 2 (Acute)

Interface Inactive


ODS B(Provider)

VPD1(Provider)


Version 1 of 27

Scenario 3 - Source VPD has not activated the interface but the Target VPD has. The diagram below illustrates the relationship between the ESR VPD and NHS CRS ODS code following the ESR soft split. The Source VPD has not activated the interface but the Target VPD has.

The diagram below illustrates the relationship between the ESR VPD and NHS CRS ODS code following the ODS restructure. There are no immediate changes required to the configuration of the ESR interface to UIM. The interface will continue to manage access for employees at VPD 2 as illustrated below. All staff members associated with VPD 1 will continue to be managed via UIM.

VPD 1(PCT)

Interface Inactive

VPD1 (Commissioner)

VPD1(Provider)


VPD 2 (Acute)

Interface Active

ODS B (Provider)


ODS B(Provider)

VPD 1(PCT)

Interface Inactive

VPD1 (Commissioner)

VPD1(Provider)

ODS A(Commissioner

+ Provider)

VPD 2 (Acute)

Interface Active

ODS B (Provider)




Version 1 of 27

Supplementary information regarding the above configuration.

• User access profiles at ODS A for staff members managed via Calendra or UIM can be transferred to ODS B by the CfH ODS Team in line with the business process for each category of user.

• The NHS CfH ODS Team can facilitate transfer/mapping of Access Control Positions from the ODS A to ODS B (i.e. if an equivalent position already exists in the Target ODS).

• The NHS CfH ODS Team can facilitate the copying of NHS CRS Access Control Positions from ODS A to ODS B (i.e. if an equivalent position does not already exist in the target ODS).

• If the users being transferred to ODS B still require access to ODS A (i.e. for NHS CRS applications that have not yet migrated to ODS B) this can be achieved via the definition of predecessor positions at ODS B in UIM.

Configuration changes required in ESR No configuration changes are required at VPD 1 or VPD 2 following the ESR soft split (above) and ODS merge. The interface will continue to manage access for employees at VPD 2 as illustrated below. All staff members associated with VPD 1 will continue to be managed via UIM.

The staff members can be linked to NHS CRS Access Positions at VPD 2, and therefore managed via the interface, upon completion of the ESR restructure.

Version 1 of 27

Scenario 4 - Neither the Source VPD nor Target VPD has activated the interface. The diagram below illustrates the relationship between the ESR VPD and NHS CRS ODS code following the ESR soft split.

No configuration changes are required at the Source or Target VPD following the ESR soft split (above) and ODS merge. Users at both ODS will continue to be managed via UIM.

Supplementary information regarding the above configuration. User access profiles and NHS CRS Access Control Positions at ODS A for staff members managed via Calendra/UIM can be migrated to ODS B by the CfH ODS Team in line with the business process/migration method for each category of user. Configuration changes required in ESR No configuration changes are required at VPD 1 or VPD 2 as neither organisation has activated the interface.

The interface can be subsequently activated at both VPDs. The NHS CRS Access Control Positions can then be downloaded and linked to ESR positions to manage NHS CRS Access via the interface.

VPD 1 (PCT)

Interface Inactive

VPD1 (Commissioner)

VPD1(Provider)

VPD 2 (Acute)

Interface Inactive

ODS B (Provider)


ODS B(Provider)

VPD 1(PCT)

Interface Inactive

VPD1 (Commissioner)

VPD1(Provider)

ODS A(Commissioner

+ Provider)

VPD 2 (Acute)

Interface Inactive

ODS B (Provider)





Version 1 of 27

4.1.4. Step 4 – Complete the ESR VPD restructure The final stage of the restructuring process from the perspective of the ESR interface to UIM is the movement of staff between ESR VPDs. This activity can be facilitated by the ESR technical merge/de-merge or Inter Authority Transfer (IAT) functionality. Organisations should be aware that the transfer of staff via IAT or merge/de-merge will have implications for the ESR interface.

a) ESR technical merge/de-merge The UUID and e-GIF flag associated with ESR employee records will be transferred as part of the merge/de-merge process. Additional considerations for organisations planning to undertake a technical merge/de-merge are outlined below;

• If Source VPDs have activated the ESR interface to UIM but the Target VPD has not, it will not be possible to complete the ESR technical merge/de-merge until the Target VPD has activated the interface. It is therefore recommended that organisations undergoing restructure undertake a co-ordinated approach to IIM.

• If the Target VPD has activated the interface but the Source VPD(s) has not, the technical merge/de-merge can still be completed. Upon completion of the VPD merge/de-merge the transferring employees can be linked to NHS CRS Access Control Positions at the Target VPD and managed via the interface. The NHS CRS Access Control Positions defined in UIM at the Source ODS can be transferred to the Target ODS and utilised by ESR at the Target VPD.

• If the Target VPD has activated the interface but the Source VPD(s) has not it is recommended that a UUID data load is completed at the Source VPD in advance of the technical ESR merge/de-merge. This will ensure the UUID and e-GIF flag for employees are transferred from NHS CRS as part of the merge/de-merge activity – If a UUID load is not undertaken Identity checks will need to be completed and recorded in ESR in order for the staff members to be managed via the interface. It is not possible to perform a UUID load for VPDs post interface activation.

• Links between ESR Positions and NHS CRS Access Control Positions that exist at the source VPD at the time of the de-merge will be copied across to the Target VPD.

b) ESR Inter Authority Transfer (IAT) The Inter-Authority Transfer (IAT) functionality within ESR is designed to remove the manual processes associated with NHS Staff Transfer Forms and therefore reduce the amount of data entry following the transfer of NHS staff from other NHS Organisations. Following IAT historical records of employees will remain with the Source Employing Authority VPD and limited history will be transferred to the Target Employing Authority VPD. The UUID and e-GIF flag associated with ESR employee records will not be transferred as part of the IAT process. Additional considerations for organisations planning to undertake an IAT are outlined below;

• The UUID and identity checks will not be transferred as part of an IAT. The identity checks will therefore need to be recorded in ESR at the Target VPD post IAT in order for the employees to be managed via the interface. The recording of identity checks in ESR and ‘association’ via the interface will also need to be completed for transferring ESR users to maintain ESR access via NHS CRS Smartcard.

• An IAT requires a termination of employment at the Source Employing Authority. If the Source VPD has activated the ESR interface the termination will result in the interface revoking all access (at the ODS controlled via the interface) for all employees that have access managed via the interface. Following the IAT access rights can be managed via the interface at the Target VPD. Alternatively access rights can be managed via UIM (not the preferred option).

• If the Target VPD has activated the interface but Source VPD(s) have not, the NHS CRS Access Control Positions defined in UIM at the Source ODS can be transferred to the Target ODS and utilised by ESR at the Target VPD.

Appendix B summarises the interface status of Source/Target VPDs and the implications this may have for the ESR interface and restructuring (i.e. ESR technical merge/de-merge and IAT).

Version 1 of 27

4.2. What if my organisation completes the VPD restructure in advance of the ODS restructure?

It is anticipated that organisations will complete the ESR VPD restructure after the ODS restructure has taken place. The implications this may have for the interface have been explained in detail in previous sections of this document.

The following section provides guidance for the scenario where the ESR VPD restructure takes place in advance of the ODS restructure. The diagram below illustrates the scenario where the provider arm of a Primary Care Trust (PCT) is being transferred to an Acute Trust (although is applicable to other scenarios). The VPD restructure is taking place in advance of the ODS restructure. The dashed line illustrates the relationship between the ESR VPD and the NHS CRS ODS code to which staff members within each VPD may have access to NHS CRS applications.


Provider)


ODS A (Commissioner +

Provider)

ODS B (Provider)





ODS B (Provider)

Commissioner and Provider staff are employed at VPD 1 and have access to NHS CRS applications at ODS A. Provider staff employed at VPD 2 have access to NHS CRS applications at ODS B.

Following a physical merge Provider staff at VPD 1 transfer from VPD 1 to VPD 2 as part of the ESR restructure. The users that have transferred still however require NHS CRS access at ODS A until the ODS restructure is complete.

Provider staff at VPD 1 transfer to VPD 2 as part of the ESR restructure. This is the final stage of the restructuring process from the perspective of the ESR interface to UIM.

Provider arm staff transfer from ODS A to ODS B

Provider arm staff transfer from VPD 1 to VPD 2



ODS A (Provider)

ODS B (Provider)

Version 1 of 27

The diagram below illustrates the scenario where the source and target VPD have both activated the interface and staff members are being transferred from VPD 1 to VPD 2 (in advance of the ODS restructure).

The implications that the transfer of staff across VPDs will have for the ESR interface to UIM will depend on whether it is being facilitated via IAT or ESR de-merge.

• Inter Authority Transfer (IAT) An IAT requires a termination of employment at the Source Employing Authority VPD. In the above scenario the termination will result in the interface revoking all access at ODS A for users that have access rights managed via the interface at VPD 1. Following the IAT access rights can be managed via the interface at VPD 2 (at ODS B) by linking ESR positions to NHS CRS Access Control Positions. If access needs to be maintained at ODS A this can be accommodated by defining predecessor positions in UIM at ODS B. Alternatively access rights can be managed at ODS A via UIM. This is illustrated below:

Please refer to Appendix B for further details regarding the IAT and implications for the ESR interface to UIM.

VPD 1 (PCT)

Interface Active

VPD1 (Provider)

ODS A (Commissioner + Provider)

VPD 2 (Acute)

Interface Active

ODS B (Provider)



Provider services transferring from VPD 1 to VPD 2

VPD1 (Commissioner)



Including employees from VPD 1


ODS B(Provider)

ODS A(Provider)

Access rights managed via the interface

Access rights to ODS A managed via UIM or the interface (using predecessor positions only)

Employees from the provider arm have transferred to VPD 2

VPD1 (Commissioner)


Version 1 of 27

• ESR technical Merge/de-merge

The NHS ESR Central Team strongly recommends that the ODS restructure is completed in advance of any ESR technical merge/de-merge. If the ODS restructure cannot be completed in advance of the ESR merge/de-merge it is possible for the existing interface configuration defined at the source VPD to be transferred to the target VPD (as illustrated below), this will ensure the interface remains operational and maintains access at the required ODS codes. This approach is not however recommended by the NHS ESR Central Team.

.

Upon completion of the ESR VPD restructure access to ODS A and ODS B for employees at VPD 2 can be controlled via the interface. The following activities would however need to be completed in ESR following the subsequent ODS restructure (i.e. when users transfer from ODS A to ODS B).

• Action 1 – All users managed via the interface that have been transferred from VPD 1 to VPD 2 must be assigned to NHS CRS Access Control Positions defined in ODS B. This can be undertaken in 2 ways:



• Action 2 – When all users have been updated (i.e. assigned NHS CRS Access Control Positions applicable to ODS B) the ODS code and worklist should be updated at the appropriate level in the ESR hierarchy at VPD 2 (i.e. to reflect ODS B). Please refer to Appendix A for further details.


• Action 4 – Predecessor links should be removed from the NHS CRS Access Control Positions in UIM at a time agreed with ODS A. and ODS B.

Please refer to Appendix A for essential information regarding the amendment of ODS codes in ESR.

Please refer to Appendix B for further details regarding the ESR merge/de-merge and implications for the ESR interface to UIM.

VPD 1 (PCT)

Interface Active

VPD1 (Provider)


VPD 2 (Acute)

Interface Active

ODS B (Provider)



Provider services transferring from VPD 1 to VPD 2

VPD1 (Commissioner)

VPD2 (Provider)

Transferred from VPD 1

ODS A (Provider)

Version 1 of 27

4.3. Guidance for organisations considering the activation of the ESR interface to UIM It is recommended that organisations changing their services as part of the TCS programme undertake a co-ordinated approach to IIM as this will ensure a smooth transition of services. Note: If organisations have completed the ESR VPD restructuring in advance of the ODS restructuring and wish to activate the interface, it is recommended that the Target Employing Authority uses the interface to control access at the new/existing ODS code only. Any access required at the previous ODS can be managed via UIM until the ODS restructure has been completed; at which point the staff members can be assigned ESR Positions linked to NHS CRS Access Control Positions and managed via the interface.

As part of the implementation activities the UUID load should however be undertaken against both ODS codes to ensure all UUIDs are loaded against the ESR VPD. This should be specified when the data load is requested via [email protected].

IMPORTANT NOTE: It is not possible to complete a UUID load or manually enter UUIDs after the interface has been activated at a VPD. Post interface activation the UUIDs can only be populated via the interface person lookup functionality (which requires mandatory Identity Checks to have been recorded in ESR).

Version 1 of 27

5. Next Steps • If your NHS organisation has not yet made a strategic decision regarding your IIM

implementation approach (i.e. UIM and the ESR interface or UIM standalone), then this should be progressed immediately. The decision should be made at Board/Executive level in line with the recommendations in the ‘Developing a Strategy for Integrated Identity Management’ toolkit. The considerations outlined within this guidance with regards to TCS should be considered where appropriate.

• If your NHS organisation has made the strategic decision to implement UIM standalone, then implementation activities should be progressed in line with the ‘User Identity Manager Implementation Guide’. UIM replaces Calendra after March 2011 and from this date, NHS organisations will not be able to manage existing or issue new Smartcards using Calendra.

• If your NHS organisation has made the strategic decision to implement the ESR interface to UIM and wishes to become a fast follower, then an interface activation date should be requested from the NHS ESR Central Team via [email protected] as soon as possible. The interface activation dates that are available to fast follower organisations are detailed in the ‘IIM Initiation Guide’. Further details regarding the required implementation activities are available in the ‘ESR Interface to UIM Implementation Approach Guide’.

• The NHS ESR Central Team has already instructed NHS organisations to prepare for the forthcoming NHS re-organisation by deploying a ‘soft split’ within ESR by the end of March 2011 (as communicated by ESR User Notice 1241). Organisations are advised to proceed within this piece of work immediately.

• If organisations will be utilising the NHS CfH ODS Team to facilitate the migration of users between ODS codes, this should be progressed in line with the ‘Migration of Spine Smartcard Users OMS Process for User Migration’ document provided by NHS Connecting for Health (CfH).

• Upon completion of the ODS restructure the ESR interface to UIM should be configured as detailed in the various scenarios within this document.

o Scenario 1 - Source VPD and Target VPD have both activated the interface; o Scenario 2 - Source VPD has activated the interface but the Target VPD has not; o Scenario 3 - Source VPD has not activated the interface but the Target VPD has; o Scenario 4 - Neither the Source VPD nor Target VPD have activated the interface.

6. Further information5 All project related documentation and learning resource is available via the following links;

• UIM: http://nww.connectingforhealth.nhs.uk/iim (requires N3 access)

• ESR: http://www.electronicstaffrecord.nhs.uk/esr-projects/integrated-identity-management

• If your organisation has any questions regarding this document or the implications of TCS for the ESR interface to UIM these should be directed to [email protected] or your ESR RPP Project Manager.

5 The links within this document to information on the NHS Connecting for Health Integrated Identity Management website require access to the NHS N3 network.

Version 1 of 27

Appendix A – Essential information regarding amendments to the ESR ODS code The ESR workstructure hierarchy (or organisation hierarchy) is used to maintain three critical values that support the ESR interface to UIM:

• ODS Code; • NHS CRS Worklist; • NHS CRS Sponsor.

The organisation hierarchy within ESR is an inverted tree-like data structure that defines organisational attributes including the parent-child relationship between individual units. Within ESR all employees and assignments must be linked to an organisation unit, therefore it is possible to determine the path from the assignments organisation unit upwards to the top level of the hierarchy. With respect to the ODS, NHS CRS Worklist and NHS CRS Sponsor, ESR will use the values defined for the organisation unit to which the person is linked for all messages sent to UIM. If the organisation unit does not have a value the hierarchy will be traversed until a value is found (a value must be specified against the trust level hierarchy in ESR).

Following ODS restructure it is possible that a ‘new’ ODS code will need to be allocated to an ESR VPD so that it can be assigned to the ESR hierarchy. If an ODS code needs to be added against an ESR VPD an SR should be raised via Remedy. The ODS code will then be added to the VPD and available for assignment to the ESR hierarchy.6 IMPORTANT NOTE: Updating the ODS code assigned to the ESR hierarchy will result in the interface initiating messages to grant access against new ODS code before revoking access against the old ODS code for all users that have access managed via the interface (within the org unit). Organisations that have activated the ESR interface to UIM must therefore complete the following activities before updating the ODS code in the ESR organisation hierarchy:

• Action 1 – All users managed via the interface in the organisation hierarchy being updated must be assigned to NHS CRS Access Control Positions at the target ODS code. This can be undertaken in 2 ways:

o Automatically – If users are being migrated by the NHS CfH ODS Team, and the migration method is ‘ESR to ESR’, then a file will be generated by NHS CfH which will automatically assign the NHS CRS Access Control Positions in source ODS to the corresponding positions in the target ODS.

o Manually – If the migration method is not ‘ESR to ESR’, or the ODS Team is not being used to facilitate the migration, then the users will need to be linked to positions in the target ODS manually (via the ESR functionality). This will grant access to the NHS CRS Access Control Position at ODS B.

• Action 2 – When all users have been updated (i.e. assigned positions applicable to the target ODS) the ODS code and worklist should be updated at the appropriate level in the ESR hierarchy at the VPD (i.e. within the ESR soft split).


6 It is not possible to assign an ODS code to an organisation below level 3 in the ESR workstructure hierarchy.

ESR hierarchy Level 1





ESR traverses the organisation hierarchy until an ODS, Worklist and Sponsor has been identified. This information is then included on messages sent to UIM

Version 1 of 27

Appendix B – ESR Merge/de-merge and IAT Options Appraisal Matrix The matrix below can be to understand the implications of an ESR IAT or merge/de-merge depending on the interface status at source and target VPDs.

Interface status of Target VPD(s) at the time of the ESR merge/de-merge/IAT Interface status of Source VPD(s) at the time of ESR

de-merge/IAT

Interface Active Interface Inactive (Organisation(s) should consider activating the interface as part of a joint project

approach with the Source VPD)

Interface Active ESR technical merge/de-merge • The technical merge/de-merge will allow employees from the Source Employing

Authority to be transferred to the Target Employing Authority and continue to be managed via the interface.

• Links between ESR Positions and NHS CRS Access Control Positions at the source Employing Authority VDP will be copied across to the Target VPD.

• The UUID and e-GIF flag for employees will be transferred from the Source Employing Authority to the Target Employing Authority.

ESR IAT • The IAT will result in Employees at the Source Employing Authority VPD being

terminated which will revoke access at the ODS code being managed via the interface at the Source VPD (for employees who have access managed via the interface).

• Post IAT the employees can be managed via the interface at the Target VPD by linking ESR positions to NHS CRS positions.

• The UUID and e-GIF flag for employees will not be transferred from the Source Employing Authority. The employees will therefore need to have their identity checked and recorded in ESR at the Target VPD in order for them to be managed via the interface.

ESR technical merge/de-merge • The Target VPD must activate the interface in advance of the technical de-

merge. ESR IAT • The IAT will result in Employees at the Source Employing Authority being

terminated in ESR which will revoke access at the ODS code being managed via the interface (for employees who have access managed via the interface). The employees will then need to be managed via UIM unless the ESR interface is subsequently activated.

• The Target VPD can realise the benefits of the interface by activating after the IAT.

Interface Inactive (Organisation(s) should consider

activating the interface)

ESR technical merge/de-merge • It is recommended that the Source VPD completes a UUID data load prior to the

technical de-merge. The UUID and e-GIF flag will then be transferred to the Target employing authority as part of the de-merge activity.

• Transferring staff members can then be managed via the interface at the Target VPD by linking ESR positions to NHS CRS Access Control Positions.

• The Source VPD can realise the benefits of the interface by activating after the technical de-merge.

ESR IAT • Post IAT the transferring employees can be managed via the interface at the

Target VPD by linking ESR positions to NHS CRS positions. • The UUID and e-GIF flag for employees will not be transferred from the Source

Employing Authority. The employees will therefore need to have identity checked and recorded in ESR in order for them to be managed via the interface.

• The Source VPD can realise the benefits of the interface by activating after the IAT.

ESR technical merge/de-merge • Staff members will continue to be managed via UIM both before and after the

ESR de-merge activity. • The Source and Target VPD can realise the benefits of the interface by

activating after the technical de-merge. ESR IAT • Staff members will continue to be managed via UIM both before and after the

de-merge. • The Source and Target VPD can realise the benefits of the interface by

activating after the IAT.

Version 1 of 27

Appendix C – ESR Interface to UIM Merge/De-merge Process Flows Process flows providing an overview of each of the migration scenarios discussed within this document are available for download from the ESR IIM Web page (http://www.electronicstaffrecord.nhs.uk/esr-projects/integrated-identity-management). ESR_UIM_Interface_TCS_Proces_Flows.pdf

Version 1 of 27

Frequently Asked Questions

Will ODS restructuring have any implications for NHS CRS Smartcard enabled ESR access? Earlier sections of this document have described in detail how the NHS CfH ODS Team can facilitate the transfer of access profiles and NHS CRS Access Control Positions from one ODS code to another. This activity will migrate access rights to all NHS CRS compliant applications from the source ODS code to the target ODS code.

It is important to note that access to ESR via NHS CRS Smartcard requires a user to have an Job Role/Activity Code on NHS CRS (i.e. this is not ODS specific). Any ODS restructure should not therefore impact access to ESR via NHS CRS Smartcard (so long as the user continues to have a Job Role/Activity Code assigned to an ODS code in NHS CRS and a UUID in ESR).

Following ODS restructure it is possible that organisations may need to assign a different ODS code to their ESR workstructure hierarchy. This activity will not impact user access to ESR (i.e. the ODS code stored in ESR does not affect ESR access via NHS CRS Smartcard) but will have significant implications for those organisations that have activated the ESR interface to UIM. Please refer to Appendix A for essential information regarding the amendment of ODS codes in ESR.

Where should I direct questions regarding the implications that TCS may for the ESR interface to UIM? If your organisation has any questions regarding the implications of TCS for the ESR interface to UIM these should be directed to [email protected] or your ESR RPP Project Manager.

Where should I direct questions in relation to the ODS restructure? If your organisation has any questions regarding the ODS restructure these should be directed to the NHS CfH ODS Team via [email protected]. Further guidance in relation to the ODS restructure is available via the ‘Migration of Spine Smartcard Users OMS Process for User Migration’ document provided by NHS Connecting for Health (CfH).

What are the implications of an ESR merge/de-merge or IAT (Inter Authority Transfer) for organisations that have already activated the ESR interface to UIM? A summary of the key points in relation to the ESR merge/de-merge and IAT is available within Appendix B (options appraisal matrix).

My organisations ODS code is changing should I update this immediately in ESR? Following ODS restructure it is possible that a ‘new’ ODS code will need to be allocated to an ESR VPD so that it can be assigned to the ESR hierarchy. If an ODS code needs to be added against an ESR VPD an SR should be raised via Remedy. The ODS code will then be added to the VPD and available for assignment to the ESR hierarchy.

IMPORTANT NOTE: Organisations that have activated the ESR interface to UIM should review the migration scenarios outlined within this document, and the supplementary information within Appendix A, before updating the ODS code in ESR.

How do I arrange an ESR technical merge/de-merge for my organisation? As communicated by ESR User Notice 1397 on 13th May 2011, the Department of Health after careful consideration has declined the funding request to support the increased merge/de-merge activity as a result of the TCS programme. As a consequence of this decision, users are advised to begin to plan alternative methods of transferring the staff, via manual migration and Inter Authority Transfer capability, available within ESR. The NHS ESR Central Team and McKesson are currently assessing the impact of the funding decision and will review how the existing merge/de-merge capacity within the ESR contract can be optimized. Further details will continue to be communicated via ESR User Notices.

Version 1 of 27

Queries in relation to the ESR technical merge/de-merge should be directed to the McKesson helpdesk via Remedy (via the local named Remedy user at your organisation). Where can I obtain further information regarding the ESR technical merge/de-merge and Inter Authority transfers (IATs)? Further details are available via kbase and the ESR online user manual (available via kbase).

ESR_Interface_to_UIM_TCS_Guide_v1.2

Documents

Transcript of ESR_Interface_to_UIM_TCS_Guide_v1.2