MESH API - Sending PDF

I’m working on adding MESH functionality into our systems and am struggling to understand some of how MESH works.

As part of the send message endpoint you specify content type. Initially I was setting that to application/pdf, however the message was always received as application/octet-stream. I then spoke to NHS digital who said that all messages are sent in that manner, and that any header containing the content-type is ignored.

So my question: How does MESH know what document I’m sending? .pdf .doc or even just .txt

At the moment I’m sending the content as the base64_encoded string of the PDF, but have no idea how it is being received at the client end as I don’t yet have access to a mailbox with a GUI!


MESH is a transport like TCP/IP and JMS. It doesn’t really have message layer where you specify message metadata like this.
From what I understand the workflowId is associated with messaging layer. For example some workflowId’s will specify the payload is always HL7v2 ORU_R01 messages, others such as those for Transfer of Care will state the payload is a HL7 FHIR Message with FHIR Document.

So MESH doesn’t understand the payload (or need to), it knows who the message is going to, where it is from and the workflowId. The receiving system needs to know how to handle the payload according to the workflowId.

Graham, as Kev, says MESH is just the transport. Our experience is that the different consuming systems have different encoding approaches - it’s trial and error to get it right. We have an RESTFUL API that we’ve put in front of MESH that allows PDF documents to be delivered into GP Systems for NHS Contracted services. At the moment this uses the Kettering approach to actually define the message to deliver. Happy to see if we can help commercially if that would benefit you organisation. We have a simple JSON API with a connection and per message cost. Paul.

Thanks Kev and Paul for your comments.

All our messages will be PDFs being delivered to GP practices. Most of our clients use Docman/EMIS or SystmOne. Do these systems have integration with MESH?

Originally I was thinking the practice would receive our PDF into their MESH inbox (like email) and then manually file. I’ve already developed our backend to send and receive messages with the MESH API - it seems I just need to get the encoding right.

From what you say about workflows, might it be possible to get NHS Digital to create a new workflow ID for our documentation?

If you search this site for Kettering XML you will find a number of threads on this subject.

So the payload format is Kettering XML, I don’t know what the workflow Id’s are though.

The workflow IDs are used by the consumer systems to understand what type of document it is that’s coming in. Some consumers are sensitive about this.


Thanks @mayfield.g.kev and @paultargett

I’ll look into Kettering XML and have a chat with a few of our client practices to try and figure out what’s required!

This came on my radar this week.

It’s a ‘fag packet’ and not official but should show nucleus for the concept of a NHS send document standard.

The structure is here NHS Digital FHIR Implementation Guide
with an example NHS Digital FHIR Implementation Guide

Document metadata is on this page NHS Digital FHIR Implementation Guide (would expect this to align with NRLS but as FHIR R4)

@mayfield.g.kev That NHS send document standard looks promising. Do you know if TTP\Emis Support the standard for Transfer of care.

Transfer of Care uses ITK3 (STU3) Send Payload Message Definition

I’ve heard a rumour that will be uplifted to R4 FHIR.

@mayfield.g.kev Thank you for the info. I will take a look at the ToC ITK3 spec.