|
|
Legitimate Relationships Implementation Manual |
|||
|
Programme |
NPFIT |
DOCUMENT NUMBER |
||
|
Sub-Prog/Project |
Comms & Messaging |
NPFIT-FNT-TO-DPM-0602 |
||
|
Prog. Director |
Paul Jones |
|||
|
Sub-Prog/Proj Mgr |
Ken Lunn |
|||
|
Author |
C&M Development Team |
Version No. |
3.2 |
|
|
Contact |
Richard Kavanagh |
Status |
Issued |
|
Contents
1.1 Domain Status
2 Storyboard
3 Application Roles
3.1 Legitimate Relationship Requestor - REPC_AR010000UK10
3.2 Legitimate Relationship Receiver - REPC_AR020000UK10
3.3 Legitimate Relationship Query Placer - QUPC_AR010000UK10
4 Trigger Events
4.1 Create Request - REPC_TE010000UK10
4.2 Confirm LR - REPC_TE020000UK10
4.3 LR Status Change Request - REPC_TE040000UK10
4.4 Status Change Request Confirmed - REPC_TE050000UK10
4.5 Query Confirmation - QUPC_TE010000UK10
4.6 Respond Confirmation (Short) - REPC_TE070000UK10
4.7 Respond Confirmation (History) - REPC_TE080000UK10
4.8 Query Details - QUPC_TE020000UK10
4.9 Respond Details (Simple) - REPC_TE090000UK10
4.10 Respond Details (Complete) - REPC_TE100000UK10
4.11 Query Batch Confirmation - QUPC_TE030000UK01
4.12 Respond Batch Confirmation - REPC_TE110000UK01
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
5.5 Query Batch Legitimate Relationships Confirmation Interactions
6 Interactions
6.1 Request Create LR - REPC_IN010000UK15
6.2 Confirm LR Created - REPC_IN020000UK13
6.3 Request Status Change - REPC_IN040000UK15
6.4 Confirm Status Change Request - REPC_IN050000UK13
6.5 Query Confirmation Request - QUPC_IN010000UK30
6.6 Confirm LR - Short Response - QUPC_IN030000UK14
6.7 Confirm LR - History Response - QUPC_IN040000UK30
6.8 Query Details - QUPC_IN020000UK15
6.9 LR Details - Simple Response - QUPC_IN060000UK30
6.10 LR Details - Complete Response - QUPC_IN070000UK30
6.11 Query Batch Confirmation Request - QUPC_IN090000UK01
6.12 Confirm LR - Batch Response - QUPC_IN250000UK01
7 Message Definitions
7.1 Create Request - REPC_MT010101UK15
7.2 Confirm Request -REPC_MT020101UK11
7.3 Request Status Change - REPC_MT040101UK14
7.4 Confirm Status Change -REPC_MT050101UK11
7.5 Query LR Confirmation- QUPC_MT010101UK30
7.6 Confirm LR - Short Response - REPC_MT070101UK13
7.7 Confirm LR - History Response -REPC_MT080101UK30
7.8 Query LR Details -QUPC_MT020101UK14
7.9 LR Details - Simple Response -REPC_MT090101UK30
7.10 LR Details - Complete Response -REPC_MT100101UK30
7.11 Query Batch LR Confirmation- QUPC_MT030101UK01
7.12 Confirm LR - Batch Response - REPC_MT130101UK01
8 Glossary of Terms
9 Change History
9.1 Changes for v3.2
9.1.1 Changes to Specific Interactions
9.1.2 Changes to IM document
9.1.3 Changes to Tabular Views
Change History
|
In Version |
Author |
Date |
Amendment Details |
|
0.1 |
Core Technical Team |
12/01/2004 |
First draft version |
|
1.0 |
Core Technical Team |
13/02/2004 |
Revisions and corrections prior to issue |
|
2.0 |
Core Technical Team |
10/05/2004 |
Change Request DACM-CR-21. Changes and corrections to P1R1. These are amendments to the implementation manual and have no impact on the business requirements: Details of changes made are given in section 10.
|
|
2.1 |
Core Technical Team |
25/06/2004 |
Change Request NPFIT-NDA-COM-LG-0266. Details of changes made are given in Section 10.2. |
|
2.2. |
Core Technical Team |
16/07/2004 |
Fixed broken hyperlinks. |
|
2.3 |
Core Technical Team |
04/08/2004 |
Change Request DACM-CR-42. Change Request DACM-CR-44. Details of these changes are outlined at the end of this document. |
|
2.4 |
Core Technical Team |
03/09/2004 |
Includes new generic Control Act Wrapper, new SDS OIDs and updated Agent SDS CMETs. |
| 2.5 | Core Technical Team | 22/10/2004 | Change Request DACM-CR-48. Details of changes made are given in section 10. |
| 2.6 | Core Technical Team | 06/12/2004 | Includes changes to failure messages and message
identifiers. Changes to tabular views referred in MIM-CR-194. Removal of
Section 8. Details of changes made are given in section 9. |
| 2.7 | Core Technical Team | 09/03/2005 | Change Request MIM-CR-0301, MIM-CR-0300, MIM-CR-0302.MIM-CR-0469, MIM-CR-0466 Details of changes made are given in Section 9. |
| 3.0 | Core Technical Team | 06707/2005 | Change Requests MIM-CR-0491, MIM-CR-0487, MIM-CR-0486., MIM-CR-0555, MIM-CR-0551, MIM-CR-0610. Details of changes made are given in Section 9. |
| 3.1 | Core Technical Team | 23/09/2005 | Change Requests MIM-CR-0629, MIM-CR-0631. Details of changes made are given in Section 9. |
| 3.2 | C&M Development Team | 14/12/2005 | Change Requests MIM-CR-0640, MIM-CR-0645, MIM-CR-0657. Details of changes made are given in Section 9. |
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 with a Health Care Professional (or workgroup) or Other Person
- Query Legitimate Relationships for specified patient.
- Query Legitimate Relationship for a Health Care Professional (or workgroup) or Other Person with a list of patients
1.1 Domain Status
This domain has been given a status of 'Draft' because of the addition of a Batch Interaction (QUPC_IN090000UK01) and response (QUPC_IN250000UK01). All other interactions are unchanged and shall be considered Normative.
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 who 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.
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 new second 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. 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 the creation of a different type of legitimate relationship: a Subject Access Request 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 that the state change was successful.. The relationship remains active for a set period of time (controlled through national time-based parameter settings) before expiring automatically.
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
|
Structured Name |
Create Request |
|
Type |
User Based |
|
State Transition |
Active |
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
|
Structured Name |
Confirm LR |
|
Type |
User Based |
|
State Transition |
Active |
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.
4.11 Query Batch Confirmation - QUPC_TE030000UK01
Description
|
Structured Name |
Query Batch Confirmation |
|
Type |
User Based |
|
State Transition |
Active |
The Query Batch Confirmation trigger event signals that a new query has been started in order to search for a LR record for a Health Care Professional (or workgroup) or Other Person with a list of patients.
4.12 Respond Batch Confirmation - REPC_TE110000UK01
Description
|
Structured Name |
Respond Batch Confirmation |
|
Type |
User Based |
|
State Transition |
Active |
Response Confirmation trigger event signals that the Query LR Confirmation is successful and response shall be returned to sender.
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
5.5 Query Batch Legitimate Relationships Confirmation 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 |
|
|
Receiving Role |
LR System |
|
|
Trigger Event |
Create Request |
|
|
Transmission Wrapper |
Send Message Payload |
|
|
Control Act Wrapper |
Control Act |
|
|
Message Type |
Create Request |
Receiver Responsibilities
|
Reason |
Interaction |
|
LR System confirms creation of LR with a Confirm LR created. |
|
|
If LR not created then Application Acknowledgement message sent to requestor |
6.2 Confirm LR Created - REPC_IN020000UK13
A positive response to the Creation Request.
|
Sending Role |
LR System |
|
|
Receiving Role |
LR Requestor |
|
|
Trigger Event |
Respond Create LR |
|
|
Transmission Wrapper |
Application Acknowledgement |
|
|
Control Act Wrapper |
Control Act |
|
|
Message Type |
Confirm Request |
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 |
|
|
Receiving Role |
LR System |
|
|
Trigger Event |
LR Status Change Request |
|
|
Transmission Wrapper |
Send Message Payload |
|
|
Control Act Wrapper |
Control Act |
|
|
Message Type |
Request Status Change |
Receiver Responsibilities
|
Reason |
Interaction |
|
LR System confirms SC of LR with a Confirm Status Change |
|
|
LR System rejects SC of LR with an Application Acknowledgement Response |
6.4 Confirm Status Change Request - REPC_IN050000UK13
A positive response to the Status Change Request.
|
Sending Role |
LR System |
|
|
Receiving Role |
LR Requestor |
|
|
Trigger Event |
Status Change Request Confirmed |
|
|
Transmission Wrapper |
Application Acknowledgement |
|
|
Control Act Wrapper |
Control Act |
|
|
Message Type |
Confirm Status Change |
6.5 Query Confirmation Request - QUPC_IN010000UK30
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 |
|
|
Receiving Role |
LR System |
|
|
Trigger Event |
Query Confirmation |
|
|
Transmission Wrapper |
Send Message Payload |
|
|
Message Type |
Query LR Confirmation |
Receiver Responsibilities
|
Reason |
Interaction |
|
LR System retrieves LR results and sends short response to placer |
|
|
LR System retrieves LR results and sends History response to placer |
|
|
LR System does not retrieve records, failed response sent to placer |
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 |
|
|
Receiving Role |
Query Placer |
|
|
Trigger Event |
Respond Confirmation (Short) |
|
|
Transmission Wrapper |
Application Acknowledgement |
|
|
Control Act Wrapper |
Query Acknowledgement Response |
|
|
Message Type |
Confirm LR – Short Response |
6.7 Confirm LR - History Response - QUPC_IN040000UK30
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 |
|
|
Receiving Role |
Query Placer |
|
|
Trigger Event |
Respond Confirmation (History) |
|
|
Transmission Wrapper |
Application Acknowledgement |
|
|
Control Act Wrapper |
Query Acknowledgement Response |
|
|
Message Type |
Respond LR – History Response |
6.8 Query Details - QUPC_IN020000UK15
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 |
|
|
Receiving Role |
LR System |
|
|
Trigger Event |
Query Details |
|
|
Transmission Wrapper |
Send Message Payload |
|
|
Message Type |
Query LR Details |
Receiver Responsibilities
|
Reason |
Interaction |
|
LR System retrieves LR details and sends Simple response to requestor |
|
|
LR System retrieves LR details and sends complete response to requestor |
|
|
LR System does not retrieve records, failed response sent to requestor |
6.9 LR Details - Simple Response - QUPC_IN060000UK30
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 |
|
|
Receiving Role |
Query Placer |
|
|
Trigger Event |
Respond Details (Simple) |
|
|
Transmission Wrapper |
Application Acknowledgement |
|
|
Control Act Wrapper |
Query Acknowledgement Response |
|
|
Message Type |
LR Details - Simple Response |
6.10 LR Details - Complete Response - QUPC_IN070000UK30
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 |
|
|
Receiving Role |
Query Placer |
|
|
Trigger Event |
Respond Details (complete) |
|
|
Transmission Wrapper |
Application Acknowledgement |
|
|
Control Act Wrapper |
Query Acknowledgement Response |
|
|
Message Type |
LR Details - Complete Response |
6.11 Query Batch Confirmation Request - QUPC_IN090000UK01
A query to LR Systems to ascertain whether or not an active Legitimate Relationship exists for a list of patients.
It also requires an entity to be entered. The query is designed for one type of entity, either the SDS User details or Other Person details of those involved in the LR to be entered.
|
Sending Role |
Query Placer |
|
|
Receiving Role |
LR System |
|
|
Trigger Event |
Query Confirmation |
|
|
Transmission Wrapper |
Send Message Payload |
|
|
Message Type |
Query Batch LR Confirmation |
Receiver Responsibilities
|
Reason |
Interaction |
|
LR System retrieves Confirm LR Batch Response |
|
|
LR System does not retrieve records, failed response sent to requestor |
6.12 Confirm LR - Batch Response - QUPC_IN250000UK01
Response from LR System to confirm the existence of current (active) LR records between a list of patients and an individual User Role Profile (NCRS User) or Other Person.
|
Sending Role |
LR System |
|
|
Receiving Role |
Query Placer |
|
|
Trigger Event |
Respond Batch Confirmation |
|
|
Transmission Wrapper |
Application Acknowledgement |
|
|
Control Act Wrapper |
Query Acknowledgement Response |
|
|
Message Type |
Respond LR – Batch Response |
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 either a Health Care Professional or a workgroup. If the LR is created manually then a reason for access code must be given.
The Other Person is only a placeholder for future use.
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 either a Health Care Professional or a workgroup.
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_MT010101UK30
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 or Other Person to be entered.
The Other Person is only a placeholder for future use.
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_MT080101UK30
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 Health Care Professionals or workgroups 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_MT090101UK30
The message contains basic details for a Legitimate Relationship record held on the LR Database, showing the Health Care Professionals or workgroups involved in Legitimate Relationships with the specified patient.
The Other Person is only a placeholder for future use.
7.10 LR Details - Complete Response -REPC_MT100101UK30
The message contains the full details for a Legitimate Relationship record held on the database, showing the Health Care Professionals or workgroups involved in Legitimate Relationships with the specified patient.
The Other Person is only a placeholder for future use.
7.11 Query Batch LR Confirmation- QUPC_MT030101UK01
The requestor sends a message to the LR system with a query as to whether or not an active LR exists for each patient in a specified list of patients. With Batch requests, no historic response is available.
The NHS number is a query parameter item.
This query is in relation to a SDS User or Other Person identified with an NHS Number, but not both.
The Other Person is only a placeholder for future use.
7.12 Confirm LR - Batch Response - REPC_MT130101UK01
The LR System searches the database and responds with a message to the requestor with whether there exists (or otherwise), a current (active) LR 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 active LR exists then the value field shall be 'false'.
A reason for failure will only be included in relation to a particular patient where a failure to locate a Legitimate Relationship record is due to an inability to locate a Legitimate Relationship party specified in the request, and thus no Boolean value can be offered.
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. |