This page provides guidance on how systems which send a consultation report should initiate the message creation action.
The following two principles should guide the implementation choice:
|a Send Consultation Report message MUST be sent for 100% of practice encounters to ensure that the registered practice care record is an accurate statement of care delivered in a primary care setting
|the Send Consultation Report send facility MUST be implemented in such a way as to minimise administrative burden on the 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 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 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 practice encounter is saved.
Any additional 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 send a 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 practice is simply requesting that information about the 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 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:
|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
|Step 2 - a PDS lookup of the patient MUST be performed to determine the ODS code of the registered practice of the patient
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:
|the message sender system MUST send the consultation report within 3 hours after the consultation was created or last update
Dealing with deleted consultations
Deletions are rare but do happen. For example, where a consultation was recorded against the wrong patient. In the event of a deletion the following sender requirement MUST be fulfilled:
|the sender system MUST give a warning message to the user. The warning message MUST include the
consultation date and the patient's
registered GP practice
PDF Format and business process
Please refer to Send Consultation Report - Business Requirements for business requirement context for the creation of the message together with details of the PDF format to be used.