Contents

Change History

1    Overview

The Legitimate Relationship (LR) Messaging Service enables an electronic relationship to exist between a patient and either a Health Care Professional, NHS Organisation workgroup or another person. It ensures that security levels for access to patient records are maintained on LR Systems.

The message definitions accessible from within this document have been defined to support a number of business processes, namely:

• Create a Legitimate Relationship
• Change of Status of a Legitimate Relationship
• Query Legitimate Relationship for specified patient and Health Care Professional (or workgroup)
• Query Legitimate Relationships for specified patient.

2    Storyboard

Mr. Chips falls from his ladder whilst painting his house on Christmas Day 2003.  He can hardly walk and is concerned that his leg might be broken.  He gets a taxi to the Accident & Emergency department at his local hospital.  The A&E receptionist registers Mr. Chips asks him to sit down and wait.

The registration is recorded on the A&E registration system function which is part of an LSP-provided application.  The system function automatically creates a legitimate relationship for the combined A&E/radiology department Work Group, sending a Create Legitimate Relationship Request message for the self-referral. The relationship is confirmed by a Legitimate Relationship Creation Response, thereby enabling all the clinicians and clinical support workers in the Work Group to access Mr. Chips’ records.

The inclusion of radiology in this Work Group was a policy decision, made because X-rays are frequently needed for A&E patients, and A&E patients are invariably sent to radiology on an ad hoc basis not via a formal transfer.

Mr Chips’ name is called and he hobbles over to the desk where Sarah Fish, the A&E triage nurse, sits.  Sarah pulls up details about Mr. Chips on her computer screen: the registration details provided plus other clinical information about his previous NHS encounters and health (like the fact that he is a diabetic) that may be pertinent to the A&E visit.

Sarah enters identifiers for Mr. Chips in the system function designed for triage.  In order to verify the existence of the legitimate relationship with Mr. Chips, the A&E application automatically issues a Legitimate Relationship Confirmation Request to ensure that Sarah has a Legitimate Relationship with Mr. Chips. Since Sarah has logged on using a Role Profile containing the A&E/Radiography Work Group, the existence of this “active” relationship is confirmed by the NASP through a Legitimate Relationship Confirmation Short Response.  Following the confirmation, the application displays relevant clinical information about Mr. Chips, and allows the Sarah to update his records.

[Note that, in theory, such a request could be deemed unnecessary as the A&E application had already created the legitimate relationship, and could have stored data to make the NASP request unnecessary.  Such a physical design would be possible for the LSP, although care would need to be taken that the LR did not “freeze” or “expire” as a result of other events (e.g. possibly from other applications) in the time period between creation and the need for confirmation of the active relationship.]

The nurse asks him a few questions about his health and records these on the system.  She has a quick look at Mr. Chips’ leg, advises him that he should wait to see a doctor, but warns him that he has another three hours to wait.  Mr. Chips hobbles away and resumes his original seat.  Finally, Mr. Chips is asked to come through to speak to the A&E registrar, Julie Salt.  Julie has already called up Mr. Chips’ record.

In order to access the patient’s records, Julie Salt uses the same system function, with the same process of legitimate relationship confirmation, as was performed by Sarah Fish.

After a thorough examination, Dr. Salt records a few details and advises Mr. Chips that he should have an X-ray. He consents to this, and so Julie records an order request to radiology department.  A porter arrives with a trolley and Mr. Chips is moved and parked near the X-ray department to wait in another queue.

When used in other hospitals, the A&E clinical application might create a Legitimate Relationship between the patient and a Work Group whose identity is a managed policy value for that application. In this hospital there is no value set because there is no need to create the relationship since, by policy, the one created when the patient entered A&E already embraces the radiology department. In hospitals operating a policy in which Radiography and A&E are in different work groups the application might well be configured to create a Legitimate Relationship with a “Radiology” Work Group.

However in this hospital there is no Work Group specified so this particular order request does not require the creation of a new legitimate relationship to radiology.  

The radiographer confirms Mr. Chips’ identity and then pulls up on his screen the notes taken by Julie Salt.  He helps Mr. Chips into position, takes some X-rays, and asks a porter to wheel the patient back to A&E.

The radiographer enters the patient’s identifiers, and another Legitimate Relationship Confirmation Request is issued automatically by the radiology software.  A matching Legitimate Relationship Confirmation Short Response message is issued confirming the relationship with the radiographer, just as it had been for Sarah Fish and Julie Salt, enabling access to Mr. Chips' records. The radiology software integrates with PACS, allowing the X-rays to be stored digitally on the LSP system. 

The porter leaves Mr. Chips in a hidden corner of A&E.  He falls asleep for ten hours.  He wakes to realise he has been forgotten and shouts for attention.  Eventually he is seen by the A&E consultant, Dr. Mushpea, who looks up his details and reviews the X-rays of his leg.

The A&E software issues another Legitimate Relationship Confirmation Request for Dr. Mushpea.  The NASP software is designed to check whether the relationship has “timed out”.  To do this for Mr. Chips, the NASP software must, as it always does for such requests, access the setting in the Directory giving the acceptable time period between accesses for this A&E/radiology Work Group for self-referrals. The setting indicates that Legitimate Relationships of this kind “freeze” eight hours after the last access.  Given ten hours have passed since the radiographer accessed the record and used the legitimate relationship, the relationship has frozen, and so the NASP software responds in the negative.

The application doesn’t give up there however. It checks the User Role Profile of Dr. Mushpea and establishes that he has the Business Function of “emergency care” as part of his profile. This enables the application to automatically create a new “active” self-claimed relationship between Dr. Mushpea and Mr. Chips (again through a matching pair of “Create Legitimate Relationship Request” and response messages. This time, the relationship is between Dr. Mushpea as an individual and the Mr. Chips; the A&E/Radiography Work Group is not involved as a whole. In course of time this relationship will freeze in line with the inactivity time-out value set by national policy for Legitimate Relationships of this kind.

All of this legitimate relationship checking and creation is invisible to the user, Dr. Mushpea.

There is no fracture evident, so his leg is strapped. Dr. Mushpea says goodbye to Mr. Chips.  In the days that follow, Mr. Chips decides he will complain about being neglected in A&E.  He decides to get hold of evidence from the hospital showing the time between being seen in radiology and being seen again by Dr. Mushpea.  He writes to the hospital with a Subject Access Request, asking for all information recorded over the previous year. A special section of the IT department in the local hospital (the “Subject Access Work Group”) processes all Subject Access Requests.  They receive the request and record it in their system.

The receipt of a Subject Access Request triggers a type of legitimate relationship.  A system function in the LSP software used by the IT Department to record Subject Access Requests automatically triggers a Create Legitimate Relationship Request.  A Legitimate Relationship Creation Response is returned, confirming the new relationship between Mr. Chips and the Subject Access Work Group.

Users who are members of the Subject Access Request Work Group process the request and output and collate all the information about Mr. Chips.

This includes extracting details of all the legitimate relationships between Mr. Chips and system users accountable to the hospital that were in a state of either “active” or “frozen” in the last year.  A system function within the LSP software allows for such a data enquiry. The user inputs a Legitimate Relationship Record Details Request and is returned a Complete Legitimate Relationship Record Details Response.

When the outputs have been posted to Mr. Chips, the IT Department records the closure of the Subject Access Request on the system.

The closure of the Subject Access Request changes the state of the legitimate relationship between the Subject Access Request Work Group and Mr. Chips. This is performed automatically when the closure is recorded by the LSP software which triggers a Legitimate Relationship Status Change Request.  A Legitimate Relationship Status Change Response message is returned to give confirmation of the state change from “active” to “frozen”.

3    Application Roles

The applications involved in Legitimate Relationships processes play specific roles.  These, along with the interactions associated with each role, are identified below.

3.1    Legitimate Relationship Requestor - REPC_AR010000UK10

An individual or an end application may request the creation of a legitimate relationship. Prior to creation the details of the application/ user are verified. This application may also act as a regulator and validator of who may access specified patient records.

Legitimate Relationships Requestor Interactions

3.2    Legitimate Relationship Receiver - REPC_AR020000UK10

The LR System performs two inseparable functions; it holds all the recorded LRs and acts as Query Fulfiller, providing details of LR records relating to specified patients in response to a retrieval request.

Legitimate Relationship System Interactions

Legitimate Relationship System as Query Filler Interactions

3.3    Legitimate Relationship Query Placer - QUPC_AR010000UK10

The Legitimate Relationship Query Placer is the initiator of a request to retrieve from the LR System, LR records for the patient identifier provided in a retrieval request.

Legitimate Relationship Query Placer Interactions

4    Trigger Events

4.1    Create Request - REPC_TE010000UK10

Description

The Create Request Legitimate Relationship trigger event signals that a new LR record to be created between the patient and the Health Care Professional or Workgroup or other person.

4.2    Confirm LR - REPC_TE020000UK10

Description

The Respond Create LR trigger event signals that the result of the Create Request is successful and has been created on the LR System.

 

4.3    LR Status Change Request - REPC_TE040000UK10

Description

Structured Name	LR Status Change Request
Type	User Based
State Transition	Active

 

Status Change (SC) event trigger signals the LR system to change the status of the current LR for the specified patient.

4.4    Status Change Request Confirmed - REPC_TE050000UK10

Description

Structured Name	Status Change Request Confirmed
Type	User Based
State Transition	Active

 

The Respond SC trigger event signals that the result of the SC Request is successful and has been changed on the LR System.

 

4.5    Query Confirmation - QUPC_TE010000UK10

Description

Structured Name	Query Confirmation
Type	User Based
State Transition	Active

 

The Query Confirmation trigger event signals that a new query has been started in order to search for a LR record for a specified patient and Health Care Professional (or workgroup).

 

4.6    Respond Confirmation (Short) - REPC_TE070000UK10

Description

Structured Name	Respond Confirmation (Short)
Type	User Based
State Transition	Active

 

Response Confirmation (Short) trigger event signals that the Query LR Confirmation is successful and response type of ‘Short’ shall be returned to sender.

 

4.7    Respond Confirmation (History) - REPC_TE080000UK10

Description

Structured Name	Respond Confirmation (History)
Type	User Based
State Transition	Active

 

Response Confirmation (History) trigger event signals that the Query Confirmation is successful and response type of ‘History’ shall be returned to sender.

 

4.8    Query Details - QUPC_TE020000UK10

Description

Structured Name	Query Details
Type	User Based
State Transition	Active

 

The Query Details trigger event signals a new request to retrieve and return the contents of all Legitimate Relationship records for the patient held on the database, in order to determine which individuals or workgroups are involved in a Legitimate Relationship with the specified patient for a (optional) specified time period.

 

4.9    Respond Details (Simple) - REPC_TE090000UK10

Description

Structured Name	Respond Details (Simple)
Type	User Based
State Transition	Active

 

The Respond Details (Simple) trigger event signals a retrieval message containing basic details for a Legitimate Relationship record held on the LR System, showing the individuals or workgroups involved in Legitimate Relationships with the specified patient.

 

4.10    Respond Details (Complete) - REPC_TE100000UK10

Description

Structured Name	Respond Details (Complete)
Type	User Based
State Transition	Active

 

The Respond Details (Complete) trigger event signals a retrieval message containing the full details for a Legitimate Relationship record held on the LR System, showing the individuals or workgroups involved in Legitimate Relationships with the specified patient.

 

---

 

5    Interaction Diagrams

5.1    Create LR Request Interactions

5.2    Status Change Interactions

5.3    Query Legitimate Relationships Confirmation Interactions

5.4    Query Legitimate Relationship Details Interactions

---

 

6    Interactions

6.1    Request Create LR - REPC_IN010000UK15

A request to create a Legitimate Relationship between a specified patient and an individual, workgroup or Other Person.

 

Sending Role	LR Requestor	REPC_AR010000UK10
Receiving Role	LR System	REPC_AR020000UK10
Trigger Event	Create Request	REPC_TE010000UK10
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	Create Request	REPC_MT010101UK15

 

 

Receiver Responsibilities

Reason	Interaction
LR System confirms creation of LR with a Confirm LR created.	REPC_IN020000UK13
If LR not created then Application Acknowledgement message sent to requestor	MCCI_IN010000UK13

 

6.2    Confirm LR Created - REPC_IN020000UK13

A positive response to the Creation Request.

 

Sending Role	LR System	REPC_AR020000UK10
Receiving Role	LR Requestor	REPC_AR010000UK10
Trigger Event	Respond Create LR	REPC_TE020000UK10
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	Confirm Request	REPC_MT020101UK11

 

6.3    Request Status Change - REPC_IN040000UK15

A request to change the status of a Legitimate Relationship between a specified patient and an individual, workgroup or Other Person. Business rules stipulate that the User will know the LR Identifier of the record that is to be to changed.

 

Sending Role	LR Requestor	REPC_AR010000UK10
Receiving Role	LR System	REPC_AR020000UK10
Trigger Event	LR Status Change Request	REPC_TE040000UK10
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	Request Status Change	REPC_MT040101UK14

 

 

Receiver Responsibilities

Reason	Interaction
LR System confirms SC of LR with a Confirm Status Change	REPC_IN050000UK13
LR System rejects SC of LR with an Application Acknowledgement Response	MCCI_IN010000UK13

 

6.4    Confirm Status Change Request - REPC_IN050000UK13

A positive response to the Status Change Request.

 

Sending Role	LR System	REPC_AR020000UK10
Receiving Role	LR Requestor	REPC_AR010000UK10
Trigger Event	Status Change Request Confirmed	REPC_TE050000UK10
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Control Act	MCAI_MT040101UK03
Message Type	Confirm Status Change	REPC_MT050101UK11

 

6.5    Query Confirmation Request - QUPC_IN010000UK15

A query to LR Systems to confirm if a LR exists for a specified patient.

The request must include the level of response required (Short or History). It also requires either the SDS User details, workgroup or Other Person details of those involved in the LR.

 

Sending Role	Query Placer	QUPC_AR010000UK10
Receiving Role	LR System	REPC_AR020000UK10
Trigger Event	Query Confirmation	QUPC_TE010000UK10
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Message Type	Query LR Confirmation	QUPC_MT010101UK15

 

 

Receiver Responsibilities

Reason	Interaction
LR System retrieves LR results and sends short response to placer	QUPC_IN030000UK14
LR System retrieves LR results and sends History response to placer	QUPC_IN040000UK14
LR System does not retrieve records, failed response sent to placer	QUQI_IN010000UK14

 

6.6    Confirm LR - Short Response - QUPC_IN030000UK14

Response from LR System to confirm the existence of current (active) LR between a patient and a User, workgroup or Other Person.

 

Sending Role	LR System	REPC_AR020000UK10
Receiving Role	Query Placer	QUPC_AR010000UK10
Trigger Event	Respond Confirmation (Short)	REPC_TE070000UK10
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Query Acknowledgement Response	QUQI_MT030101UK03
Message Type	Confirm LR – Short Response	REPC_MT070101UK13

 

 

6.7    Confirm LR - History Response - QUPC_IN040000UK14

Response from LR System to confirm the existence of current (active) or previous LR records between a patient and a User, workgroup or Other Person.

 

Sending Role	LR System	REPC_AR020000UK10
Receiving Role	Query Placer	QUPC_AR010000UK10
Trigger Event	Respond Confirmation (History)	REPC_TE080000UK10
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Query Acknowledgement Response	QUQI_MT030101UK03
Message Type	Respond LR – History Response	REPC_MT080101UK13

 

6.8    Query Details - QUPC_IN020000UK14

A query to LR Systems for details of LR between a specified patient and an individual or workgroup. The request also includes the level of response required (Simple or Complete).

If no Time period is specified, only current active relationships will be returned in the response. If a user has been warned that patient has dissented, then override dissent flag will be set to ‘1’ –Override. ReasonCode and addition text must be given if dissent flag set to ‘1’.

 

Sending Role	Query Placer	QUPC_AR010000UK10
Receiving Role	LR System	REPC_AR020000UK10
Trigger Event	Query Details	QUPC_TE020000UK10
Transmission Wrapper	Send Message Payload	MCCI_MT010101UK12
Message Type	Query LR Details	QUPC_MT020101UK14

 

 

Receiver Responsibilities

Reason	Interaction
LR System retrieves LR details and sends Simple response to requestor	QUPC_IN060000UK15
LR System retrieves LR details and sends complete response to requestor	QUPC_IN070000UK15
LR System does not retrieve records, failed response sent to requestor	QUQI_IN010000UK14

 

6.9    LR Details - Simple Response - QUPC_IN060000UK15

The response message contains basic details for LR records held on the database, showing the individuals or workgroups involved in LRs with the specified patient.

The effective date denotes the date and time at which the LR was Frozen. The presence of this date is also used to indicate that the status of the LR is frozen. Expired relationships are not returned.

 

Sending Role	LR System	REPC_AR020000UK10
Receiving Role	Query Placer	QUPC_AR010000UK10
Trigger Event	Respond Details (Simple)	REPC_TE090000UK10
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Query Acknowledgement Response	QUQI_MT030101UK03
Message Type	LR Details - Simple Response	REPC_MT090101UK15

 

 

6.10    LR Details - Complete Response - QUPC_IN070000UK15

The response message contains the full details for LR records held on the LR Systems, showing individuals or workgroups involved in LRs with the specified patient.

 

Sending Role	LR System	REPC_AR020000UK10
Receiving Role	Query Placer	QUPC_AR010000UK10
Trigger Event	Respond Details (complete)	REPC_TE100000UK10
Transmission Wrapper	Application Acknowledgement	MCCI_MT020101UK12
Control Act Wrapper	Query Acknowledgement Response	QUQI_MT030101UK03
Message Type	LR Details - Complete Response	REPC_MT100101UK15

 

 

---

 

7    Message Definitions

7.1    Create Request - REPC_MT010101UK15

The message allows an individual or application to request a Legitimate Relationship be created between a specified patient and an individual, workgroup or Other Person. If the LR is created manually then a reason for access code must be given.

 

The 'OtherPerson' is modelled as only a placeholder for future use and not to be used in P1R2.

 

            

 

7.2    Confirm Request -REPC_MT020101UK11

The LR System holding the Legitimate Relationships (LR) data shall send a message back to the requestor confirming that a LR has been created.

 

            

 

7.3    Request Status Change - REPC_MT040101UK14

The message allows an individual or application to request the status of Legitimate Relationship be changed between a specified patient and an individual or workgroup.

 

The 'OtherPerson' is modelled as only a placeholder for future use and not to be used in P1R2.

 

 

            

 

7.4    Confirm Status Change -REPC_MT050101UK11

The LR System holding the Legitimate Relationships (LR) data shall send a message back to the requestor confirming that the status change has been successful.

 

            

 

7.5    Query LR Confirmation- QUPC_MT010101UK15

The requestor sends a message to the LR system with a query of whether a LR exists for a specified patient.

 

The NHS number is a query parameter item. The query also sends the levels of response required, either ‘Short’ or ‘History’.

 

This message requires the UserID, UserRoleProfile and optional Workgroups to be entered. This forces the 'OtherPerson' option to be unavailable.

 

The 'OtherPerson' is modelled as only a placeholder for future use and not to be used in P1R2.

            

 

7.6    Confirm LR - Short Response - REPC_MT070101UK13

The LR System searches the database and responds with a message to the requestor with whether a current (active) LR exists for the patient, whose NHS number was included in the search parameter. If an LR does exist then the value field shall be 'true'. If no LR exists then the value field shall be 'false'.

 

            

 

7.7    Confirm LR - History Response -REPC_MT080101UK13

The LR System searches the database and responds with a message to the requestor with whether a LR exists for the patients whose NHS number was included in the search parameter. The response shall indicate an existence of a LR records (current or frozen) for the patient. If an LR does exist then the value field shall be 'true'. If no LR exists then the value field shall be 'false'.

 

            

 

 

7.8    Query LR Details -QUPC_MT020101UK14

The message notifies the LR System of a query message to retrieve and return the contents of all Legitimate Relationship records for the patient held on the database, in order to determine which individual or workgroup are involved in a Legitimate Relationship with the specified patient for a (optional) specified time period.

 

Required parameters for this query are:-

• patient NHS number
• Response Format (Simple or Complete)
• DissentOverride

 

The Time Period to which the LR relate is an optional parameter. If no value entered, then only current relationships will be returned in the response.

 

The LR's that shall be returned are Legitimate Relationships which are not expired and where:

LR Start Date & Time <= Request End Date and LR Freeze Date & Time is NULL or

LR Start Date & Time <= Request End Date and LR Freeze Date & Time => Request Start Date.

 

            

 

7.9    LR Details - Simple Response -REPC_MT090101UK15

The message contains basic details for a Legitimate Relationship record held on the LR Database, showing the individuals or workgroups involved in Legitimate Relationships with the specified patient.

 

The 'OtherPerson' is modelled as only a placeholder for future use and not to be used in P1R2.

 

            

 

7.10    LR Details - Complete Response -REPC_MT100101UK15

The message contains the full details for a Legitimate Relationship record held on the database, showing the individual or workgroup involved in Legitimate Relationships with the specified patient.

 

The 'OtherPerson' is modelled as only a placeholder for future use and not to be used in P1R2.

 

            

 

---

 

8    Glossary of Terms

Legitimate Relationship	A Legitimate Relationship is a relationship between a clinician (or NHS organisation work group) and a patient, that gives the clinician, or workgroup member, certain levels of entitlement to access that patient’s health record maintained on National Systems.
Health Care Professional	A Clinician involved in the Legitimate Relationship.
Workgroup	A team of clinicians who work together within an NHS organisation, to provide healthcare.

 

 

9    Change History

9.1    Changes for v2.6

 

9.1.1    General Changes

 

• All relevant interactions have been updated to include the new Control Act & Transmission wrappers
   
• All amended artefacts have been re-versioned.
   
• Interaction Diagrams have been updated to include re-versioned artefacts.

• The queryId attribute has been removed from all query messages as the Message.Id attribute in the Transmission level wrapper is regarded as sufficient identification for a query.
   

• The id attribute has been removed from the focal act of all request messages as the Message.Id attribute in the Transmission level wrapper is regarded as sufficient identification for a request. Similarly references in response messages to an original request have been removed.

• Four trigger events, four interactions and four message type have been removed as all errors will be reported in the Control Act wrapper and not in separately defined payloads.

9.1.2    Changes to Trigger Event

• Reject LR - REPC_TE020000UK10

This trigger event has been removed as all errors will be reported in the Control Act wrapper and not in separately defined payloads.

• Status Change Failure Response - REPC_TE060000UK10

  This trigger event has been removed as all errors will be reported in the Control Act wrapper and not in separately defined payloads.

   

• Failed Response Confirmation - REPC_TE110000UK10

  This trigger event has been removed as all errors will be reported in the Control Act wrapper and not in separately defined payloads.

   

• Failed Query Details - REPC_TE120000UK10

  This trigger event has been removed as all errors will be reported in the Control Act wrapper and not in separately defined payloads.

 

9.1.3    Changes To Specific Interactions

• Request Create LR

The interaction artefact identifier has changed from REPC_IN020000UK12 to REPC_IN020000UK13 to reflect changes to the wrappers and message type.

This interaction (REPC_IN030000UK13) has been removed as all errors will be reported in the Control Act wrapper and not in separately defined payloads.

The interaction artefact identifier has changed from REPC_IN050000UK12 to REPC_IN050000UK13 to reflect changes to the wrappers and message type.

This interaction (REPC_IN060000UK13) has been removed as all errors will be reported in the Control Act wrapper and not in separately defined payloads.

The interaction artefact identifier has changed from QUPC_IN010000UK14 to QUPC_IN010000UK15 to reflect changes to the wrappers and message type.

The receiver responsibilities table has been simplified to "Query failed" and "Query successful" due to the change in the way errors are reported.

The interaction artefact identifier has changed from QUPC_IN030000UK13 to QUPC_IN030000UK14 to reflect changes to the wrappers and message type.

The interaction artefact identifier has changed from QUPC_IN040000UK13 to QUPC_IN040000UK14 to reflect changes to the wrappers and message type.

This interaction (QUPC_IN050000UK13) has been removed as all errors will be reported in the Control Act wrapper and not in separately defined payloads.

The interaction artefact identifier has changed from QUPC_IN020000UK13 to QUPC_IN020000UK14 to reflect changes to the wrappers and message type.

The receiver responsiblities table has been simplified to "Query failed" and "Query successful" due to the change in the way errors are reported.

The interaction artefact identifier has changed from QUPC_IN060000UK14 to QUPC_IN060000UK15 to reflect changes to the wrappers and message type.

The interaction artefact identifier has changed from QUPC_IN070000UK14 to QUPC_IN070000UK15 to reflect changes to the wrappers and message type.

This interaction (QUPC_IN080000UK13) has been removed as all errors will be reported in the Control Act wrapper and not in separately defined payloads.

• REPC_MT010101UK14 - Create Request - CreateRequest.Id attribute has been removed as the Message.Id attribute in the Transmission level wrapper is regarded as sufficient identification for the request.
  
  The message artefact identifier has changed from REPC_MT010101UK14 to REPC_MT010101UK15 to reflect changes to the RMIM.
   

• REPC_MT020101UK10 - Confirm LR - CreateRequest Act and inFulfillmentOf act relationship have been removed as the Message.Id attribute in the Transmission level wrapper is regarded as sufficient identification for the request.
  
  The message artefact identifier has changed from REPC_MT020101UK10  to REPC_MT020101UK11 to reflect changes to the RMIM.
   

• REPC_MT030101UK12 - Reject LR Request  has been removed as all errors will be reported in the Control Act wrapper and not in separately defined payloads.
   
• REPC_MT040101UK13 - Request Status Change - SCRequest.Id attribute has been removed as the Message.Id attribute in the Transmission level wrapper is regarded as sufficient identification for the request.
  
  The message artefact identifier has changed from REPC_MT040101UK13 to REPC_MT040101UK14 to reflect changes to the RMIM.
   
• REPC_MT050101UK10 - Confirm Status Change - SCrequest act and inFulfillmentOf act relationship have been removed as the Message.Id attribute in the Transmission level wrapper is regarded as sufficient identification for the request.
  
  The message artefact identifier has changed from REPC_MT050101UK10 to REPC_MT050101UK11 to reflect changes to the RMIM.
   
• REPC_MT060101UK12 - Reject Status Change Request has been removed as all errors will be reported in the Control Act wrapper and not in separately defined payloads.
   
• REPC_MT070101UK12 – Confirm LR - Short Response -

  The LRConfirmationRequest act and inFulfillmentOf act relationship have been removed as the Message.Id attribute in the Transmission level wrapper is regarded as sufficient identification for the request.
  
  The message artefact identifier has changed from REPC_MT070101UK12 to REPC_MT070101UK13 to reflect changes to the RMIM.

• REPC_MT080101UK12 – Confirm LR - History Response -

  The LRConfirmationRequest act and inFulfillmentOf act relationship have been removed as the Message.Id attribute in the Transmission level wrapper is regarded as sufficient identification for the request.
  
  The message artefact identifier has changed from REPC_MT080101UK12 to REPC_MT080101UK13 to reflect changes to the RMIM.

• REPC_MT090101UK14 – LR Details - Simple Response -

  The DetailsRequest act and inFulfillmentOf act relationship have been removed as the Message.Id attribute in the Transmission level wrapper is regarded as sufficient identification for the request.
  
  The message artefact identifier has changed from REPC_MT090101UK14 to REPC_MT090101UK15 to reflect changes to the RMIM.
       

• REPC_MT100101UK14 – LR Details - Complete Response - The DetailsRequest act and inFulfillmentOf act relationship have been removed as the Message.Id attribute in the Transmission level wrapper is regarded as sufficient identification for the request.
  
  The message artefact identifier has changed from REPC_MT100101UK14 to REPC_MT100101UK15 to reflect changes to the RMIM.