Written by Technical Team | Last updated 17.10.2025 | 12 minute read
GP Connect Send Document is a focused capability that lets a point-of-care application send a consultation summary to the patient’s registered GP practice, reliably and at scale, using a national backbone of standards and infrastructure. In practical terms, that usually means packaging a PDF summary and moving it—securely and auditably—into the receiving GP system, where practice staff can process it as part of clinical workflow. The aim is simple: wherever a patient receives care (out-of-hours, urgent treatment centres, district nursing, extended access hubs, even a different practice), the registered GP gets an accurate record of what happened, quickly and with the right context.
Under the bonnet, the capability is implemented through GP Connect Messaging and delivered via MESH (the Message Exchange for Social Care and Health) with ITK3 (Interoperability Toolkit Message Distribution) providing the FHIR messaging conventions. The payload itself follows HL7 FHIR STU3, using a FHIR Message with a Composition and supporting resources wrapped in a Bundle. That stack—FHIR + ITK3 + MESH—gives you a well-defined, resilient, and policy-aligned way to transmit clinical documents between NHS organisations.
The capability is production-status, and designed for direct care of NHS patients in England. It’s explicitly framed for point-of-care scenarios where the sender is a clinical system supporting a clinician, and the receiver is the patient’s registered GP system. If you’re designing or enhancing a workflow where clinicians generate discharge or consultation notes for a registered practice, this is the most direct, nationally approved route to deliver that documentation.
Because it rides on MESH, the service inherits a well-understood operational model: 24×7×365 operation with standard business-hours support (termed “silver” service). For teams planning out-of-hours and weekend activity, it’s important to distinguish operational availability from support windows; build your on-call and retry strategy accordingly.
At a high level, your sender constructs a FHIR Message representing the consultation summary. The Bundle includes a MessageHeader (carrying routing and acknowledgement intent), a Composition (the clinical summary itself), and supporting resources like Patient, Practitioner, and Organisation. The document content—often a PDF—is included as an attachment (Binary/Attachment), with the message conformance aligned to ITK3’s profiles and extensions. The completed message is then submitted to the national MESH service, which places it in the recipient’s mailbox for retrieval by the GP system.
MESH behaves a little like a secured, centrally hosted post room for the health and care system. Senders drop off messages; receivers collect from their own mailbox. Crucially, automated routing can target a patient’s registered practice without the sender needing to look up the destination mailbox explicitly. To do this, the sender supplies the NHS Number, date of birth, and surname in the routing fields. MESH uses that triad to route the message to the patient’s registered practice inbox. This is not just convenience; it reduces dependency on brittle address books and keeps routing consistent with national registration data.
For the MESH API, the destination is expressed via address lookup into the Mex-To header with the transform:
GPPROVIDER_<NHSNumber>_<DDMMYYYY>_<Surname>
The MESH Client uses a corresponding .ctl metadata file, populating To_DTS with the same pattern. This convention is essential to ensure automated routing works as intended.
ITK3 Message Distribution builds on FHIR Messaging to standardise message envelopes, headers, and acknowledgements. It lets a sender request infrastructure acknowledgements (technical success/failure) and business acknowledgements (did the receiver process this as expected?). Your integration should be explicit about which acknowledgements you request and how you handle them—particularly for error conditions that require resubmission or human intervention.
Each GP Connect messaging use case is bound to a Workflow ID. For consultation summaries, the MESH workflow is:
Before you write a line of code, the national guidance sets out a concrete set of prerequisites—technical, information governance, and clinical safety—plus the route to onboarding. Aligning with these early will save weeks of rework later.
From a networking standpoint, you can access the capability via the HSCN or the internet, but either route must comply with MESH messaging and its security constraints. On the security model, this integration is classed as an application-restricted API: end-user authentication isn’t handled by the API—you’re expected to manage user access and audit within your application. This implies a solid, documented RBAC model on your side and a clear operational model for who can send what, when, and under which legal basis for direct care.
You’ll also need MESH access—either the MESH API (preferred for integration) or the MESH Client—and ITK3 alignment. In addition, you must be PDS-capable (Personal Demographics Service) to confirm the registered practice or to execute patient demographics checks; many teams do this via PDS FHIR or via a compliant third-party provider.
The test environment available for this capability is the Path-to-Live integration environment, along with a sender testing route that exercises the message flow. Use this environment to validate message structure, headers, workflow IDs, acknowledgements, and binary handling before seeking approval for live traffic.
On onboarding, you’ll be asked to submit a use case describing your product, clinical scenario, and value proposition for direct care, after which the team aims to respond within 14 days. Treat the use case as part clinical safety case, part operational description—it should set out your legal basis, governance controls, and the exact data flows proposed.
Your GP Connect Send Document – FHIR integration checklist:
The Send Document capability currently supports a Consultation Summary use case with the document typically represented as a PDF. While other attachment types are possible (for example, images or HTML), the expectation is that application/pdf remains the normal case. Your design should still allow for alternative MIME types—not least because future use-cases might expand the repertoire of accepted documents.
At its core, your message is a FHIR Bundle of type message that includes:
The ITK3 MessageDefinition for GP Connect Send Document points to the set of utilised assets, including CareConnect profiles for Patient, Organization, Practitioner, and key ITK extensions for bundles and headers. Treat these as hard constraints; they’re the profile contracts you’re expected to conform to.
When populating the Composition, ensure the narrative text accurately reflects the clinical content embedded in the attachment. The receiver might index or display Composition metadata separately from the PDF, and discrepancies between narrative and attachment can create safety risks. Use consistent author/time/context fields and, where applicable, encode coded terminology for problem lists, medications, procedures, and observations included in the summary narrative.
Although PDF is the norm, you may encounter other file types, particularly as the capability evolves. Ensure you set the MIME type correctly and that the Binary content is encoded and sized within any practical limits your sender and the MESH pipeline can handle. NHS guidance provides a list of common MIME types relevant to health documents (PDF, DOC/DOCX, RTF, HTML, text, XML, JPEG/PNG). Establish strict validation to reject or quarantine unsupported types to avoid downstream failures in GP systems.
Keep in mind that very large attachments may require special handling. Architect for chunked processing or streamed file IO in your sender service so you don’t blow memory limits during base64 encoding. Consider pre-submission compression where safe and compatible with receiving systems; when using the MESH Client, the .ctl metadata supports a compressed flag, and content should be consistent with that indicator.
Whether you integrate via the MESH API or the MESH Client, you must populate specific metadata correctly. The guidance singles out:
These fields serve both operational routing and human triage at the receiving end. Invest in unit tests for each header to catch formatting errors before they get anywhere near MESH.
Clinical realities change—spelling corrections, later lab results, or a clinician amending a note. The specification allows you to update/re-issue a document and mandates incrementing the Version each time. Your sender should maintain idempotency where possible: if a previous transmission failed after leaving your system but before receipt, a safe retry should not create duplicate artefacts in the receiver’s workflow. Maintain a robust linkage between your local document identifier, the MESH submission, and the version number so that later corrections are traceable and unambiguous.
Designing for negative paths is essential. When you request ITK3 acknowledgements, you’re asking the receiver to tell you whether the message landed (infrastructure) and whether it made sense (business). Your integration must parse the incoming acknowledgement and route it to the correct handler:
Log both types with sufficient detail to support operational analytics and safety monitoring. Provide a clear dashboard for clinical and support teams to see message state, latest ack status, and recommended next actions.
Once live, your focus shifts from passing tests to running a safe, dependable service. That means monitoring, governance, clear support paths, and alignment with practice workflows. It also means respecting the realities of GP system diversity and the pace of supplier roll-out.
Because GP Connect Send Document is application-restricted, your system—not the API—owns end-user authentication and authorisation. Adopt least privilege: only clinicians with a legitimate relationship and role should be able to generate and send a consultation summary. Enforce robust audit logging (who sent what, when, for which patient, from which workstation, under which role), and ensure that smartcards—if you already use them—align with your local RBAC design (smartcards are not required by the capability but may be in your estate). Make sure your privacy notice and records of processing reflect this data flow explicitly.
When traversing networks, ensure TLS everywhere, strict hostname validation, and current cipher suites. On the inbound side, sanitise all metadata before logging to avoid PII leakage into non-secure logs (for example, avoid logging raw Mex-To values containing NHS numbers). For attachments, validate file headers (“magic numbers”) as well as MIME types to prevent spoofing.
MESH operates 24×7×365 with business-hours support. That’s sufficient for most primary care flows, but it places responsibility on you to absorb transient faults out of hours: implement exponential back-off, dead-letter queues for irrecoverable failures, and time-bounded retries so staff don’t get spammed days later with stale documents. Provide operational run-books that explain when and how to trigger a manual resend, how to extract diagnostic bundles, and who to contact if acknowledgements stop arriving.
While the capability is production status, not every GP system will implement it uniformly or at the same time. Monitor supplier roll-out status and, where necessary, maintain feature toggles that adapt how you package or present documents for specific receivers. Partner with practices to agree triage processes: who checks the inbound mailbox, how often, how documents get filed into the patient record, and what happens to documents that fail matching. Be deliberate about subject line content—it’s often the first clue the practice uses to decide priority.
Design your sender service with strong observability from day one:
Expose dashboards to operations and clinical safety teams. For incidents, capture a forensic trail: the FHIR Bundle (minus sensitive content where necessary), headers used, and any validator outputs. Couple this with alarms on ack timeouts (for example, raise if infrastructure ack not received within N minutes under normal load).
Is your team looking for help with GP Connect integration? Click the button below.
Get in touch