Sending documents to MESH

We are exploring sending clinical documents to MESH. Could someone please explain in lay terms ( I am not a developer) what formats are accepted by GP systems receiving data from Secondary Care via MESH?
Currently we send documents to Docman and accounts in 2 different formats required locally: pdf and tiff. Does sending via MESH mean that we would now able to send in one, common format accepted by all GP systems used in England and what is it?
Also, how do we test it? Would we need access to all GP test systems or do we verify results in MESH?
We would like to start with Endoscopy reports (text only – no images) from Unisoft and then send discharge summaries and clinic letters.
Many thanks

this is a link to a similar conversation on linkedin
and a related conversation on this forum E-discharge: standard clinical headings required by Dec

Thank you. I have some more questions.

  1. Have standards for sending Endoscopy eports electronically been published? We outsource building our interfaces to an external company so need to avoid re-building it if there are changes coming soon.
  2. The link to CDA introduction contains this phrase:
    A CDA document on FHIR is a defined and complete information object that can include text, images, sounds, and other multimedia content.
    And then an example of a discharge summary on the same website contains a jpg file (although it is just an image of a signature as I understand it). So what I am trying to establish is that all GP systems can now consume data in the same format, without any embedded attachments and we no longer have to worry about which GP needs a pdf and which ones needs a tiff etc. Could someone who has connection to MESH please comment on how this works in practice? (again in lay terms please)

You might want to join INTEROPen to get some answers to your questions.

The links below are quite technical :

(MESH) ITK3 way of sending information

You also have the transfer of care initiative for letters (outpatient and discharge letters) which builds on MESH+ITK3

Hi, MESH is just the transport it gets a file from A to B. The web site has some docmentation on this. You need to be able to adopt a protocol on top of that that does something with the documents. We have an API service for delivering documents to GP systems over MESH that works every day for TPP and EMIS. The GP systems have problems with different document formats and deal with them differently. You will note that the FHIR profiles are marked as alpha.


When I was working in a NHS trust or board it wasn’t just sending letters to GP’s, we also had letters going to community, document management systems, etc. Things we did (I’m going to use a letter/post office analogy):

Paper: Try to stick to common formats. So the letters were PDF’s or html (html tends to work for both of the main GP suppliers). We tried to avoid TIFF because it has a number of issues (converting scans to PDF was a big one).
FHIR documents (as used by transfer of care) are another format to consider as this can include coded data (e.g. conditions, medications, procedures, etc) to be sent and makes it easier for a computer to process the document (e.g. update the medical record). FHIR documents can easily be converted to PDF or html if the receiving system can’t process them.
I’ve not done much with images but DICOM seems to be the standard.

Envelope: This is also called the metadata, you need metadata to:
identify the patient,
what type of document it is,
what specialty it came from,
what organisation wrote it,
date document was created,
the author,
We don’t have a common NHS standard at present but this works very well and I would recommend looking at it this as a model for metadata [For FHIR Documents (/transfer of care) this metadata would be included in the Composition].

Postal Service To send to GP’s you are probably going to to use MESH (+ FHIR ITK3).
As I mentioned earlier we also sent documents to document stores and other health providers. To do this we used FHIR bundles as the internal standard for our post office (trust integration engine), the Bundles contained both the metadata (DocumentReference) and actual document (pdf, html, etc).
Our TIE/post office would inspect the metadata and work out where the document needed to be sent, it would also convert the metadata to other formats (e.g. kettering) if needed and then send the document to the end system (via MESH, N3, API, etc). The TIE also converted all incoming letters to the same ‘canonical’ format.
Moving to a standard format took more time to begin with but once built adding in new services was a lot quicker. This has been done at several NHS boards/trusts over the last few years.

1 Like

Thank you. It is very helpful. I am still digesting it.
I have one more question. Since MESH is not doing any conversion itself and is just a transfer tool then our TIE will need to know in advance which type of file to send. We obviously store this information on our TIE for local practices but how do we find this info for the rest of the country as we get quite a few patients out of the area? Is there a centrally maintained file or a website which would contain all this data (which practice uses which system and what type of files it can accept?).

Hi Kevin,

regarding e- Discharge in FHIR message to MESH, regarding the MESH API, can you give some more details about this ?

thank you


I am also fairly new to all this and I have recently started sending kettering via MESH (I may be behind the times but it is a start). We asked NHS digital for a complete list of practices and their mailboxes, but they have told me we should be doing the lookup via their “MESH Endpoint Lookup Service”.
I also had an interesting talk with the Service Owner of MESH who told me that practices were not all ready to receive all formats, so the Transfer Of Care deadlines which NHS England have set are not achievable.
I too am starting the journey to FHIR so I appreciate kev’s links too.

Mesh api is on my to do list. I believe it fits in with our HIE demo - so if we get the ok will update.