This page provides guidance on how systems which send a federated consolation summary should initiate the message creation action.
The following two principles should guide the implementation choice:
|GPCM-SD-076||a Send Federated Consultation Report message MUST be sent for 100% of federated practice encounters to ensure that the registered practice care record is an accurate statement of care delivered in a primary care setting|
|GPCM-SD-077||the Send Federated Consultation Report send facility MUST be implemented in such a way as to minimise administrative burden on the federated practice|
The following solution is presented as the preferred option:
Automated message creation
The message creation process is hidden from the clinician – in a similar way that synchronisation with Summary Care Record (SCR) takes place without the involvement of a clinician, the GP Principal Clinical System is responsible for the background task of ensuring that the registered practice record is updated.
Where the encounter details at a federated practice are updated later (for example, at the end of a clinic), an additional message would result to ensure that the latest complete picture of the encounter was made available to the registered practice. Note that each additional federated encounter summary message would contain a complete encounter summary, and not simply the delta to the previous instance.
The trigger for the background process would be at or near the time when a federated practice encounter is saved.
Any additional federated consultation report could be clearly marked as such. As the GUID of the encounter is present in the ITK3 SenderReference field, all messages associated with that encounter can be identified.
As the process to generate and sent a federated consultation report is automated, message priority cannot be set, as this would require a review by the clinician. As a result, the message priority of all messages for this use case will be set to
routine indicating that the federated practice is simply requesting that information about the federated practice encounter be attached to the registered practice record.
Where specific actions are required at the registered practice as a result of the encounter, the federated practice clinician will follow existing business processes.
Defining whether message should be sent
Irrespective of the means of triggering message creation, the first step the sending system must perform is to ascertain whether a message must be sent to the registered practice.
The message sender performs the following steps to ascertain whether a message should be sent to the registered practice:
|GPCM-SD-083||Step 1 - if the patient registration type of the patient record at the appointment hosting practice is Regular (GMS/PMS), meaning, the registered practice care record is already up-to-date, then a message MUST NOT be sent|
|GPCM-SD-084||Step 2 - a PDS lookup of the patient MUST be performed to determine the ODS code of the registered practice of the patient|
|GPCM-SD-085||Step 3 - the system at the appointment hosting practice determines whether the registered practice is in the same federation as the hosting organisation ODS code using the local federation definition; this check MUST pass for the message to be sent, else the message MUST NOT be sent|
Steps 2 and 3 are required as should the message not be destined for another practice in the federation, MESH mailbox configuration at the target practice would cause any message to be undeliverable. MESH will be configured to allow message flow for this use case only within a federation boundary.
Additionally, in a scenario where both the sending and receiving practice are operating the same GP principal clinical system, updating the registered practice may be performed directly within that system infrastructure.
Defining when message should be sent
The message sender MUST fulfil these time period requirements:
|GPCM-SD-096||the message sender system MUST send the federated consultation report a configurable time period after the consultation was created or last update|
|GPCM-SD-097||where a consultation is updated within the configurable time period of the last update, the time delay to sending the consultation report MUST be from the later update|
|GPCM-SD-099||where a consultation is updated after the configurable time period (and therefore the consultation report has already been sent) a new consultation report MUST be sent (after the configurable time period)|
|GPCM-SD-100||each GP practice MUST be able to set its own a configurable time period|
|GPCM-SD-101||where a GP practice has not set its own configurable time period the value MUST default to three hours|
The message sender must adhere to the following requirements:
PDF Format and business process
Please refer to Send Federated Consultation Report - Business Requirements for business requirement context for the creation of the message together with details of the PDF format to be used.