Search loading...


Explore and Make use of Nationally Defined Messaging APIs


Triggering message creation

Options for triggering the creation of a consultation report message

This page provides guidance on how systems which send a consultation report should initiate the message creation action.

Guiding principles

The following two principles should guide the implementation choice:

GPCM-SD-076 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
GPCM-SD-077 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:

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

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 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:

GPCM-SD-135 the sender system MUST give a warning message to the user. The warning message MUST include the patient name, NHS number, 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.


All content is available under the Open Government Licence v3.0, except where otherwise stated