Note: This has been superceded by the Send Document v2.0.0 specification
Message flows
The following diagram illustrates how messages flow between the sending (originating) organisation and the registered practice via MESH to fulfil this use case:
The diagram above depicts a successful message flow where registered practice message processing validates and matches the initial message successfully to a patient. This involves the following steps:
| Step | Event | Description |
|---|---|---|
| 1 | Consultation report message | |
| 1a | After the consultation is complete, a trigger at the sending organisation results in a FHIR Message being constructed which includes a PDF describing the consultation. | |
| 1b | The MESH client at the sending organisation sends the message to the MESH server where it awaits collection by the registered practice. | |
| 1c | The MESH client at the registered practice collects the message from the MESH server and makes it available to other registered practice system components for onward processing. | |
| 1d | The message is processed at the registered practice. | |
| 2 | Infrastructure acknowledgement ITK Response | |
| 2a | When the consultation report message is passed from the MESH client for processing at the registered practice, the message is first validated to ensure that its structure is correct. An ITK3 Response message is generated which indicates the success of message processing at a technical level - this is known as an infrastructure acknowledgement. |
|
| 2b | The MESH client at the registered practice sends the message to the MESH server where it awaits collection by the originating organisation. | |
| 2c | The MESH client at the originating organisation collects the message from the MESH server. The ITK Response is then available to other originating system components for onward processing. | |
| 2d | The acknowledgement message is processed as appropriate by the originating organisation. | |
| 3 | Business acknowledgement ITK Response | |
| 3a | When the consultation report message is passed from the MESH client for processing at the registered practice, after successful message validation, the subject of the message contents - the patient - is looked up to ensure that patient is known and registered at the practice. An ITK3 Response message is generated which indicates the success of patient matching - this is known as a business acknowledgement. |
|
| 3b | The MESH client at the registered practice sends the message to the MESH server where it awaits collection by the originating organisation. | |
| 3c | The MESH client at the originating organisation collects the message from the MESH server and makes it available to other originating organisation system components for onward processing. | |
| 3d | The acknowledgement message is processed as appropriate by the originating organisation. |
Message flows
The following processing steps must take place at the originating organisation system (the sender) to create the message - as described in step 1a above.
| Step | Description |
|---|---|
| 1 | Initiate process to create for consultation report message. Refer to Send Trigger for guidance on available options. |
| 2 | Create the ITK3 payload: Construct a PDF description of the encounter. |
| 3 | Wrap the payload as an ITK3 message, requesting infrastructure and business acknowledgements. |
| 4 | Create the MESH message. Specify NHS Number, DOB and Surname in MESH metadata to enable MESH to route to registered practice. |