Merging organisations

The steps outlined should be taken to ensure continuity of data flows that can be correctly attributed to the pre and post merge organisations and to enable continuing access to data extracts.

Organisational mergers of NHS care providers do not always result in an immediate merger of IT facilities and systems to enable a single flow of CDS to SUS. During a merger transition, CDS data can flow for multiple sites from multiple senders and providers must take extra care to avoid inadvertent deletion or duplication of records in SUS.

A number of approaches can be taken but the solution will be dependent upon the range of local systems and services in use at the merging organisations, including for example

• Patient administration systems 
• A&E systems 
• Maternity systems 
• Critical Care systems
• CDS preparation methods
• Data warehouse set-up
• XML translation solutions 
• CDS submission methods

We will focus on the issues common to all organisations, such as the use of the organisation code data items within the submission methods used. This will help determine an appropriate approach for the local situation. 

Merging organisations will each have a different

• CDS Interchange Sender Identity, 
• CDS Sender Identity, and 
• Organisation Code (Code of Provider)

Merged organisations should attempt to move to using their new Provider Codes as soon as possible after the merger date. The new Organisation Code should be used from the point at which the merger is effective. The CDS Activity Date should determine which period the activity belongs to. For example, as the Admitted Patient Care (APC) CDS is submitted at episode level, the Provider Code in effect at episode end should be used for submission. If the change happens at year-end, data relating to that year should continue to flow from the predecessor sender using the existing Organisation Codes. Data for the next year should use the new Organisation Code.

CDS Interchange Sender Identity is used to identify the organisation that submits a CDS interchange. It comprises a 10 character EDIFACT id with a 5 character ‘local tail’ making a total of 15 characters. Typically it might look like 190000099900001 where 1900000999 is the EDIFACT id and 00001 is the ‘local tail’

A new organisation can obtain a unique 10 character EDIFACT id from Addressing Registration. The remaining 5 characters are decided locally and configured within the XML translation software. It is recommended that these 5 characters are used to uniquely identify the various sending applications in use at the organisation. Each organisation is responsible for managing this themselves.

The CDS Interchange Sender Identity is carried in the CDS Interchange Header and only one can be sent per interchange.

SUS uses the CDS Interchange Sender Identity to sequence interchanges at the 15 character level. SUS assumes that the order received from the EDT client is the order in which interchanges should be processed. It is therefore suggested that merged organisations using a single 10 character EDIFACT code consider having different 15 character variants of CDS Interchange Sender Identity for each translation application to prevent any problems due to incorrect sequencing.

The CDS Authentication process is enabled by a table of ‘allowed pairs’ of CDS Sender Identity Codes and CDS Interchange Sender Identity Codes. To comply with CDS Authentication each CDS Sender Identity must be associated with only one CDS Interchange Sender Identity. This means that if a single XML translation application is used by a merged Provider and the pre-merge Providers submit separate interchanges, each of the Providers must use a different CDS Sender Identity. Interchanges that do not comply with CDS Authentication will be rejected.

CDS Authentication only uses the first 10 characters of the CDS Interchange Sender Identity. For example, 190000099900001 and 190000099900002 will be regarded as the same code

A CDS SR1 Sender Registration Form must be submitted to the National Service Desk (NSD) to enable the relationship of these codes to be set up for the merged organisation. If data is to continue to flow from more than one CDS Sender Identity, this will need to be done as many times as there are flows under the new Organisation Code (see ‘Summary of Steps’).

SUS will accept CDS messages in XML files provided by either NET Change or BULK update submission methods. There are a number of fields in the CDS that are used as update keys for the SUS database and these are dependent upon the method used.

How each of the merging organisations currently sends CDS is important as it will impact on the submission method chosen by the new organisation. The following submission scenario should be considered throughout this section:

Trust A (ODS code RZA) merges with

Trust B (ODS code RZB) to become

Trust C (new ODS code RZC) on 1 April

Trust A’s new ODS Site code = RZCAB

Trust B’s new ODS Site code = RZCYZ

Note that the ODS codes given above are for illustration only and senders should substitute their own codes as allocated by ODS where appropriate. Note also that organisation codes are used in a number of different CDS items such as Organisation Code (Code of Provider) and Site Code (of Treatment) and the use of pre and post-merger codes in examples applies equally in whichever item an ODS code change is required.

In order to ensure that SUS will update historical data as well as new data, CDS records should always be sent using their original CDS Sender ID (an ODS code). If the CDS Interchange Sender ID (a 15- digit EDI Number) has changed the new EDI address must be registered to use the old ODS code or the interchange will fail CDS Authentication.

The provider code is not required for either submission method, but making this the same value for data from all sites will ensure correct spell construction for spells from episodes across sites.

Within an interchange, SUS identifies the CDS Sender Identity, taking all 5 characters into account.

Code Rnn is different from Rnn00 and both are different from Rnn01.

SUS then checks the report start and end date combination against the existing database.

1. If the sender has not previously sent data for the CDS REPORT PERIOD START DATE and CDS REPORT PERIOD END DATE the records will be applied to the database – even if data for the same period has been sent. E.g. if data is sent for 01 May to 31 May and then resent with an earlier extract date but for the 01 May to 30 May the interchange will be applied, Copyright © 2016, NHS Digital. All rights reserved. 25 deleting later records except for the ones on 31 May.

2. If data has previously been sent for exactly the same report period start and end dates, SUS will check the CDS EXTRACT DATE and CDS EXTRACT TIME. If this date is greater than or equal to the equivalent date and time in any interchange previously applied to SUS, the interchange will be applied to the database. However, if the extract date and time is less than any interchange previously processed by SUS, the interchange will not be applied (although it will be recorded that the transaction took place). These interchanges are identified in SUS Tracker as ‘Not Applied’.

When an interchange is applied to SUS, all the matching data is deleted between the report start and end date (where the CDS Extract Date and Time is equal to or later than the existing records in the same CDS report period). The records in the BULK interchange are then applied. Matching records have

• The same Bulk Replacement Group (BRG)
• The same CDS Sender Identity
• A CDS Activity Date (episode end date for FCEs) between the CDS Report Period Start and End dates in the new interchange

Changing the CDS Sender Identity of a record can have two effects

1. A new code that has not previously been received by SUS for the interchange report period will cause duplication of those previously submitted records of the same included Bulk Replacement Groups holding the original sender code.

2. Records with a code that has been received previously will replace those existing records in SUS for the same sender code, interchange report period and included Bulk Replacement Groups – which will not be a direct replacement of like for like records. Data senders with more than one data flow should take note of this consequence when merging those flows.

It is possible to update records sent before the merger as long as the same pre-merge CDS Sender Identity is used. Any records migrated to a different Patient Administration System (PAS) as the result of a merger may also be updated in SUS by using the original CDS Sender Identity.

If the merging organisations intend to continue to have separate CDS submissions they should use the new organisation codes RZC where appropriate but will need to make sure they use different CDS Sender Identities:

Trust A, formerly RZA, may register as Sender Code RZCAB

Trust B, formerly RZB, may register as Sender Code RZCYZ

If Trust A and Trust B both use RZC without site suffix identifiers, this will contravene CDS Authentication.

For NET interchange records the CDS Sender Identity, CDS Unique Identifier and CDS Applicable Date and CDS Applicable Time are checked against SUS and then applied according to CDS Type

• For CDS Update Type = 9, if a CDS Unique Identifier is not on the database for that CDS Sender Identity, the record is added
• For CDS Update Type = 9, if one or more records are found for the same CDS Sender Identity with the same CDS Unique Identifier, it will replace them with those in the interchange where the CDS Applicable Date and Time is later than the CDS Applicable Date and Time on the existing record
• If a record with matching CDS Sender Identity and CDS Unique Identifier has previously been sent as BULK, the CDS Applicable Date and Time will be compared to the CDS Extract Date and Time on the existing record

It is possible to send a NET delete record, CDS Update Type = 1. This can be thought of as a ‘self-delete‘ record where all records it finds a match with (i.e. the same CDS Sender Identity and Unique CDS Identifier) will be deleted (marked on the database as logically deleted) and the NET delete record will then delete itself.

Certain CDS types allow NET change to update/delete an existing record containing a different CDS type. These are listed in the table below:

For all other CDS types (listed below) NET change will only update/delete an existing record containing the same CDS type: Incoming CDS Type:010 020, 021, 030, 040, 050, 060, 070, 080, 090, 100, 110, 150, 160, 170, 210

To maintain Separate Multiple Data Flows

• Records to be updated must be sent with their original CDS Sender Identity
• CDS Unique Identities must remain the same through every version of the individual CDS record

If the merging organisations intend to continue with separate CDS submissions they will need to ensure the CDS Unique Identifier is unique across the new organisation. System suppliers should be able to provide details on the method of generating this data item and further details can be found on the NHS Data Dictionary.

CDS Unique Identifier is applied at the event record level. This means each episode in an APC CDS should have a different value, as should each Outpatient or A&E attendance.

If there is replication of CDS Unique Identifiers then this should be resolved before the merger date. This is illustrated in the following example:

If two merging organisations use the same PAS supplier they should follow NHS Data Dictionary guidance in the construction of the CDS Unique Identifier. This stipulates that a trust specific element is used.

Two different patients with the same PAS identifier number (e.g. patient master index entry number), 0123456 and same chronological event on each PAS (e.g. first APC episode in first non-elective spell on system) may be identified in a CDS extracted separately from each PAS as BRZAAB0123456_1_1 and BRZBYZ0123456_1_1.

If both appear in their respective CDS extracts as 0123456_1_1 local processing should add the trust prefixes before sending to SUS. It is possible to send data using a single CDS flow before a PAS merger takes place, so this action will enable an easier transition to a future single CDS flow.

It is recommended that the merging organisations do not move to using the new organisation code RZC in the prefix until any PAS merger takes place, even if a single CDS flow is adopted. The merging organisations should however use the new organisation codes RZC where appropriate for provider or site code but will need to make sure that they use different CDS Sender Identities

Trust A, formerly RZA, may register as Sender Code RZCAB

Trust B, formerly RZB, may register as Sender Code RZCYZ

If Trust A and Trust B both use RZC without site suffix identifiers, this will contravene CDS Authentication.

To initiate and use Single Combined Data Flow

Once the decision has been taken to move to a single combined CDS flow it is important that the Sender code in all CDS is populated with the new organisation Copyright © 2016, NHS Digital. All rights reserved. 28 code of RZC and site code fields with the appropriate ODS registered new site code

To prepare SUS to receive data as a single NET CDS, the following actions should be taken

• DELETE existing records with the old ODS codes by submitting a NET delete using CDS Unique Identifier with their original ODS Sender Code
• RESUBMIT historic records with activity from the date of the merger with their new CDS Unique Identifier and with the new RZC sender code. These could be sent from an existing EDI address or from a new EDI Address specific to the merged organisation as long as either is authenticated to send RZC records

These actions will:

• replace data that relates to activity subsequent to the merger but which carries codes for the pre-merge organisations
• provide data that holds the correct organisation codes at a given point in time
• allow all data for the new organisation to be updated or replaced as part of local business as usual processes for the single combined data flow

Trusts using or planning to use NET change should be careful to manage changeover to a single PAS as they will need to ensure that previously generated CDS Unique Identifiers are not reused for different records.

This situation would typically occur where merging trusts separately employ different methods for their SUS submissions.

To extend the previous example, Trust A (RZA) is a NET sender; Trust B (RZB) uses BULK.

It is possible for senders to use NET change and BULK update according to which method is most suited for the interchange and CDS type they are sending to SUS. However, mixing NET and BULK for the same CDS Types is not recommended and carries associated risks.

• NET will replace all the records with the same CDS Unique Identifier for the sender providing the Applicable Date is equal to or later than the previous record(s) Extract Date. It is possible to send a BULK interchange with many records with the same CDS Unique Identifier for the same sender, thus if all the records in a BULK interchange have the same CDS Unique Identifier and a subsequent NET change delete record is sent with that CDS Unique Identifier, it follows that all the BULK records will be deleted.
• NET change cannot identify records without a CDS Unique Identifier; therefore it cannot be used to replace BULK records that have been submitted without a CDS Unique Identifier. This could result in BULK records effectively being duplicated, with one version with a CDS Unique Identifier and one without. 
• BULK will update all NET records for the CDS Sender Identity, CDS Report Period Start and End Date combinations irrespective of Extract Dates and Applicable Dates. This will also happen regardless of the contents of the CDS Unique Identifier field.

For example, if a provider were to submit APC General Episodes (CDS type 130) on a regular basis using NET and then submit APC Delivery Episodes (CDS type 140) data using BULK, the BULK maternity submission will overwrite all existing NET APC records within the BULK report period submitted for all sender/recipient pairs found

The above highlights the two main risks of mixing NET and BULK:

• A BULK submission will delete all NET submissions, irrespective of applicable date
• If BULK has not used a CDS Unique Identifier, multiple records can be replaced by a single NET record

Where separate data flows are maintained organisations need to ensure that the CDS Copyright © 2016, NHS Digital. All rights reserved. 29 Unique Identifier is unique across the new organisation by checking with system suppliers that no records on any local system have the same value in this field. Both NET and NULK submissions from the merged organisations should carry this data item. This will support any eventual merger onto a single system.

The merging organisations should use the new organisation codes RZC where appropriate but will need to make sure that they use different CDS Sender Identities

Trust A, formerly RZA, may register as Sender Code RZCAB

Trust B, formerly RZB, may register as Sender Code RZCYZ

If Trust A and Trust B both use RZC without site suffix identifiers, this will contravene CDS Authentication.

Once the decision has been taken to move to a single combined CDS flow it is important that the sender code in all CDS is populated with the new organisation code of RZC and site code fields with the appropriate new ODS registered site code.

Guidance on when Hospital Provider Spells should be closed and reopened, including the associated administrative codes to record for the discharge and admission events generated, can be found on the NHS Data Dictionary.

The merge process involves the closing and opening of organisations so patients in hospital must be discharged from the closing organisation on the merge date and immediately admitted by the successor organisation.

The organisation codes where each spell closes should be used to submit the related APC CDS. This will register where the activity took place at the correct point in time.

The impact of this will be to inflate the number of admissions and discharges across all NHS organisations, but will not affect counts for the individual constituents.

In this situation, SUS PbR and the HRG grouper will regard activity at each provider organisation as separate spells. Spell construction will therefore be affected by the merger and agreements should be made to avoid double-payment for the affected spells. This may include a one-off regrouping exercise using the actual admission and discharge dates and one set of provider codes to determine the appropriate tariff.

Reopened spells will have an admission method of '81' (non-emergency transfer) and an admission source of '51,'52' or '53' (hospital ward) and will not count as a readmission.

When organisations separate they may or may not revert to their pre-merge organisation codes depending on the new configuration of services. Advice on which codes to use should be sought from the Organisation Data Service (ODS).

Much of the guidance applicable to mergers is equally valid for demergers in that each organisation resulting from the split should be regarded as a new sender in relation to SUS. The same steps will need to be completed and particular attention should be given to ensuring that activity is attributed to the correct provider at the correct point in time.

Until such time as the provider function becomes a separate statutory body either in its own right or as the result of a merger with another provider organisation, both parts of such an organisation will use the same organisation code. It may be appropriate to introduce local procedures to limit the access to data held on SUS of Copyright © 2016, NHS Digital. All rights reserved. 30 individual staff working in the different functions of such organisations.

In order to maintain access to extracts for pre and post-merger organisations, it is necessary for the new organisation code to be added to existing Smartcards. Existing RBAC functionality should remain against pre-merge organisation codes and be copied against the new code.

The ODS team can transfer existing users across to the new organisation using the Organisation Migration Service (OMS). The reconfiguration lead in your organisation should have this scheduled as part of the wider reconfiguration plan.

At the discretion of the organisations concerned, some of the planning for these steps can be undertaken before the merge takes place.

After registration of the new organisation with ODS, in order to successfully submit data to SUS and maintain access to SUS extracts, the following steps need to be completed:

Step 1: Review and decide submission configuration

Merging organisations should review their current sending configuration in terms of internal data flows, number of XML translation applications and CDS Interchange Sender and Sender Identity codes in use.

The decision to consolidate flows does not need to be made straight away, and it may not be appropriate for this to occur, but to comply with CDS Authentication, individual sites and systems within the new organisation must use unique CDS Interchange Sender Identity and CDS Sender Identity combinations. The new organisation must therefore make use of the relevant ODS site codes as the CDS Sender Identities to differentiate multiple CDS data flows for the same provider by using the last 2 digits of the Organisation Code.

Step 2: Register for CDS Authentication

Complete a CDS SR1 Sender Registration form and submit it. 

Step 3: Enable CDS Authentication and access to extracts

NHS Digital to update:

Organisation code and parent-child mapping tables to ensure staff can access new and historic data for the organisation.

CDS Authentication table with new unique legitimate relationships between CDS Interchange Sender and the CDS Sender.

We will notify the end user when this process is complete.

Step 4: Local update of smartcards

The local Registration Agent (RA) must ensure all smartcards have access profiles granted against the new organisation. The ODS Organisation Migration Service (OMS) can help if necessary.

Step 5: Review and decide submission strategy

The merged organisation should review the manner in which it sends data to SUS in terms of the submission method used and whether it is appropriate to consolidate flows. This decision may influence Step 1 but may be deferred until such time as any merger of supporting systems such as PAS has taken place. The submission strategy should support data flows so that data from different sources does not conflict to cause either duplication or inadvertent deletion of SUS data

Step 6: Update SUS to create correct point in time position

It is essential that data held on SUS represents the correct position of all organisations pre and post-merger. This step should include resubmitting data with the new organisation code for activity relating to the post-merge period.

This merger checklist summarises the tasks that merging organisations should complete in order to maintain CDS flows and access to SUS data extract

Obtain new organisation code from Organisation Data Service (ODS) 

Update smartcards 

• New organisation codes must be added to cards 
• May need to contact Organisation Migration Service (OMS)

Review current submission configuration

• Single or Multiple XML translation applications

Implement new submission configuration

• May need to obtain new EDI address(es) from Addressing Registration 
• May need contact with current XML translation supplier(s) 
• Register new sender codes using SR1 form to comply with CDS Authentication

Update SUS data to represent correct point in time position for pre and post-merge organisations.

Notify NHS Digital that data from merged organisations will be flowing under new codes.

Review current submission strategy across new organisation

• All BULK/All NET/Combination of BULK and NET
• May need to check uniqueness of CDS Unique Identifier across existing PAS applications or data warehouses within new organisation

Implement new submission strategy if different

• May need to prepare SUS to update historical records using NET by resubmitting data with appropriate CDS Unique Identifier.

The main stages in this checklist are equally applicable to organisations separating as part of a demerger.