|GPCM-C-1||MESH MUST be used as the message transport mechanism|
MESH is the strategic platform for asynchronous messaging in the NHS.
Viewed very simply, MESH is like a post-restante service for electronic message delivery. Messages flow around the NHS using MESH as follows:
- Sender creates message and sends to the MESH server
- MESH server places the message in the destination mailbox
- Receiver collects the message from their inbox
Message senders and receivers have two options when connecting to the central MESH server: MESH API or the MESH client.
To registered practice
Where message senders create messages destined for a patient’s registered practice, MESH message automated message routing is encouraged.
Automated message routing enables a message sender to send a message to the MESH server without specifying a destination MESH mailbox ID. MESH takes care of routing the message to the mailbox of the patient’s registered GP practice. This simplifies the task of message creation for the sending organisation.
Rather than specifying the destination mailbox ID, the message sender simply specifies the NHS Number, Surname and Date of Birth of the patient in the message header.
Refer to details below in the MESH API and MESH client sections for how to do this.
To alternative care providers
Where message senders create messages destined for alternative care providers, for example a community pharmacy, the MESH API MUST be used lookup the receiving organisation’s MESH mailbox ID.
Details on how to use the MESH address lookup function can be found in the MESH API specification.
When using the MESH endpoint lookup service, the Mex-To HTTP header is populated according to following syntactic conventions.
_ character is used as the delimiter.
Date of birth is specified in
For example, when sending a message about a patient Mr Brian Smith, born 14 February 2001, with NHS Number 12345678, the Mex_To field will have the following value:
The MESH Client is an alternative means which organisations use to send and receive messages from the MESH central server infrastructure.
When using this automated means of message routing, the To_DTS field in the MESH message control (.ctl) file must be populated according to the same syntactic conventions described for the MESH API above.
Workflow ID configuration
All messages which are sent to MESH specify a Workflow ID which identifies the workflow a particular data transfer is part of.
Each GP Connect Messaging use case will be grouped and associated with a single Workflow ID which has been created use with messages generated by those use cases only.
Where the use case requires some form of ITK acknowledgement, an additional Workflow ID will be created to be used for acknowledgement messages generated for the use case.
Please refer to the applicable messaging use case details page for information on the Workflow ID to be used when generating particular messages. For example, when generating a message for the “Consultation Summary Report” use case, please refer to Consultation Summary Report.
Configuring MESH to enable message flow
The flow of messages through MESH is controlled through rules which are set in the following form:
Mailbox ID is allowed to
Send|Receive messages with
For example, to enable a consultation report message to flow from GP0001 to GP0002, two rules need to be set up in MESH configuration:
GP0001is allowed to
Sendmessages with workflow ID
GP0002is allowed to
Receivemessages with workflow ID
As GP Connect Messaging capabilities are delivered, MESH will therefore be configured to enable actual message flow between organisations. Note that the approach is based on explicit opt in to ensure particularly GP practices receive only those messages which they have consented to receive.