Written by Technical Team | Last updated 17.10.2025 | 14 minute read
GP Connect: Update Record is the standards-based route for sending structured clinical updates from community pharmacy systems into a patient’s registered GP practice system. Rather than relying on scanned letters or ad-hoc emails, it transports a machine-readable payload that can be triaged, reviewed and filed within the GP system’s workflow. In practical terms, it shortens the time from a pharmacy encounter to a trustworthy entry in the GP record and reduces the risk of transcription errors along the way. At its core, the integration is a set of rules, payload profiles and transport conventions that any assured supplier can adopt to deliver safe, consistent, auditable updates.
The capability is laser-focused on the pharmacy-to-GP use case. Registered community pharmacy professionals can send consultation summaries to practices after specific services such as Pharmacy First consultations, Blood Pressure Checks and Pharmacy Contraception services. This narrow scope is a strength: it keeps the clinical content and governance tight, allows clear onboarding paths for suppliers, and ensures that GP systems receive well-formed messages that map cleanly to their internal models. For practice staff, the net effect is a clear “to-review” item in the clinical workflow rather than unstructured attachments that require manual re-keying.
Unlike synchronous read APIs, Update Record is deliberately asynchronous. Messages are built as HL7® FHIR® STU3 bundles and distributed over MESH (the NHS Message Exchange for Social Care and Health) using the ITK3 messaging specification. That combination—FHIR for structure, ITK3 for the messaging envelope and acknowledgements, and MESH for reliable delivery—was chosen because it is already widely deployed across NHS primary care and community systems. Where read-only access benefits from “live” API calls, the act of updating is best modelled as a store-and-forward, assured message with formal acknowledgements and auditable hand-off between organisations.
From an information governance and clinical safety perspective, the design pushes identity checking, role-based authorisation and clinical risk management to the sending system and the supplier organisation. That’s a pragmatic partitioning of duties: the transport is application-restricted and the receiving GP systems expect that the sender has already verified the user, the patient and the lawful basis for direct care. The end result is a predictable operating model in which messages can be routed, validated and matched to a patient before they ever reach a clinician’s in-basket.
The architecture falls into three layers: payload, envelope and transport. At the payload layer, the clinical content is modelled as FHIR STU3 resources constrained by the GP Connect data model. That means you are not inventing your own observation structure or medication dispensing format; you are populating well-defined profiles that match what GP systems already expose via GP Connect Access Record: Structured. This design decision aims to minimise bespoke mapping at the receiving end and future-proof the payloads if the transport changes in the future (for example, if a RESTful write API were introduced later).
The envelope layer is ITK3 Messaging Distribution. It provides the FHIR MessageHeader, the concept of infrastructure and business acknowledgements, and standardises how the receiving system indicates technical acceptance (valid message format) and business acceptance (for example, “patient matched”). In Update Record, infrastructure acknowledgements confirm that your message was structurally valid and reached the GP system’s message processor, while business acknowledgements confirm GP workflow-level checks—particularly that the patient can be matched to the practice’s registered list. This two-phase acknowledgement is vital for reliable automation and robust retry logic.
Transport is via MESH. As a store-and-forward backbone designed for health and social care, MESH lets the sending pharmacy system post the message to an inbox associated with the registered GP practice, and the practice’s MESH client then collects it for onward processing. MESH metadata—such as NHS number, date of birth and surname—supports routing and helps the receiving side with patient matching, while the defined workflow ID identifies Update Record traffic unambiguously. For this capability, the MESH workflow identifier is GPCONNECT_UPDATE_RECORD.
A “happy path” message journey is straightforward. After the pharmacy consultation is completed, the sending system constructs a FHIR message bundle containing a Composition (the clinical narrative for the encounter) and the relevant entries (for example, MedicationDispense for supplied medicines, Observation for blood pressure readings, and Condition for the presenting problem). The message is wrapped in the ITK3 envelope, posted to MESH, and collected by the GP’s MESH client. The receiving system validates the message (infrastructure acknowledgement), attempts to match the patient to the practice list and generates a business acknowledgement. The final step is ingestion: creating a review item or task in the GP workflow so that a clinician can review and file the entry. That separation of transport, acceptance and clinical filing is what makes the system reliable and auditable at scale.
In practice, not every message follows the happy path on the first attempt. Validation may fail if a required field—such as NHS number—is absent or malformed. Patient matching can fail if identifiers are inconsistent or if the patient is no longer registered at that practice. Robust implementations therefore keep track of acknowledgements, respond to OperationOutcome content in ITK3 responses, and implement back-off and correction routines. The implementation guide provides examples of how a sending system should construct, tag and version payloads, and how a receiver should surface rejections and errors to its operators. Getting this right is the difference between a pilot integration and a production-grade service.
Before any code is written, suppliers need to be confident they can meet prerequisites across networking, transport, data standards, and governance. These requirements are not bureaucracy—they are the control points that keep patient data safe and ensure messages can be processed by GP systems without surprises.
Key technical and organisational prerequisites:
Onboarding is use-case driven. Suppliers submit a use case that explains the business problem, how GP Connect will be used to benefit patients and staff, which GP Connect products will be used, and who the end-user organisations are. It also names the supplier’s Clinical Safety Officer and references available clinical risk documentation. NHS England reviews the submission and responds with next steps, which typically include access to integration and deployment environments and guidance for message sender testing. This front-loaded clarity reduces churn during assurance and helps NHS England understand where new suppliers fit within the ecosystem.
It is also worth understanding the service boundaries. Update Record is “in production,” but support and rollout can vary by GP system and pharmacy supplier. The catalogue page points to supplier progress information so that implementers can align expectations with the actual state of deployment in the field. Where a practice has enabled Update Record, pharmacy consultation summaries—complete with observations, clinical notes and details of any medicines supplied—arrive in the GP system’s workflow for review and filing. Where it is not enabled, practices can still receive communications through more traditional channels, but the benefits of structured messaging (speed, auditability, reduced re-keying) are, of course, lost.
The first build decision is payload modelling. Update Record uses GP Connect’s STU3 profiles, which means your FHIR objects should look and behave like the records exposed through Access Record: Structured. Using the same profiles for read and write has a major advantage: the GP system’s “ingestion” layer can map the incoming data straight into its known internal schema with minimal transformation. For a Blood Pressure Check, for instance, you would create Observation entries for systolic and diastolic readings, link them to the Encounter, and include a Composition that provides the human-readable clinical summary under PRSB-aligned headings. For Pharmacy First minor illness, you might include a Condition to represent the assessed problem, the key observations and safety-netting advice as narrative, and a MedicationDispense if an antibiotic or other medication was supplied. The implementation guide’s examples give you concrete templates for each of these flows.
Next comes the ITK3 wrapper and MESH transport. Your build pipeline should create a FHIR message bundle with a MessageHeader that references the Composition and related entries, tag the meta appropriately (including any agreed-upon meta.tag conventions for service type or versioning), and then wrap the bundle within the ITK3 message construct. When sending, use the designated MESH workflow ID for Update Record and populate the MESH metadata fields—especially NHS number, date of birth and surname—to assist routing and matching on the practice side. Test runs should exercise both expected-success and expected-failure paths so your application can handle infrastructure and business acknowledgements correctly. It is not uncommon, for instance, to pass infrastructure validation but fail business acknowledgement due to an unmatched patient, so your user interface and support processes must account for that.
Filing is a deliberate, human step. Update Record is not designed to automatically write to the GP record without a clinician’s review. Instead, the receiving system surfaces the incoming summary within its internal workflow (for example, a task or inbox item) where a clinician can review, reconcile medicines, and decide how to file. That design mirrors the clinical reality: community pharmacy professionals can assess and treat within their scope, but the registered GP record remains the longitudinal home of truth. When the GP clinician files the update, it becomes part of the patient’s primary care record and can then appear in downstream views, such as Access Record HTML/Structured or shared care records.
You should also plan for idempotency and re-submission. Because MESH is store-and-forward, network or endpoint issues can tempt implementers to “just send again.” Without a robust message identity strategy (for example, a deterministic Bundle.identifier and tracking at your application layer), you risk creating duplicate workflow items at the practice. The ITK3 message ID and your own business identifiers should line up so the receiver can detect duplicates. If your product supports user-driven resubmission, consider UI patterns that make the outcome of each send attempt transparent and that nudge users to correct data rather than repeatedly sending a broken payload.
Finally, invest early in test data and environments. The catalogue references integration and deployment environments on the Path-to-Live journey and provides “message sender testing” resources. Use these to validate not only schema conformance but also your real-world behaviours: error logging, acknowledgement handling, and support runbooks. Incorporate automated validation against the Update Record FHIR profiles as part of your CI, and keep your local examples in sync with the latest implementation guide version so release notes don’t catch you off guard.
Designing high-quality clinical messages is about more than passing schema validation. The receiving GP system needs enough structured data to support safe clinical decisions, and the reviewing clinician needs a clear, human-readable narrative that tells the story of the encounter. Think of the payload as a pair: a PRSB-aligned Composition for people, and linked, coded entries for machines. Populate both with care. For a Blood Pressure Check, the Observation resources should use appropriate LOINC/SNOMED codes and units; the narrative should note the context, cuff size if relevant, any repeated measures, and advice given. For Pharmacy First episodes, flag red-flags assessed and safety-netting advice explicitly. Many filing decisions hinge on the clarity of that narrative.
Medication handling deserves special attention. Where a pharmacy supplies medicines (for example, under Pharmacy First), MedicationDispense indicates what was actually supplied to the patient, while MedicationRequest would represent a prescriber’s instruction (not always present in the pharmacy-led models). Be explicit in your modelling and only include MedicationRequest where it correctly reflects the clinical scenario. Keep ingredients and dose instructions precise; avoid free-text that duplicates structured fields but adds ambiguity. And when you include over-the-counter advice or self-care recommendations, decide whether they belong as narrative within the Composition or as structured DetectedIssue or GuidanceResponse—follow the implementation guide’s intent to avoid inventing profiles that receivers will not recognise.
For observations, use single-purpose entries rather than packing multiple results into one blob. Blood pressure is a classic example: systolic and diastolic are separate Observation.component values within one Observation instance, but temperature and pulse are separate observations. Link observations to the Encounter and ensure timestamps reflect when the measurement was taken, not when the message was built. These details improve clinical provenance and help GP systems display data chronologically in a way that makes sense to clinicians reviewing a timeline.
Error handling and rejection flows must be “first-class citizens” in your design. When a receiver returns an infrastructure rejection, it is telling you the message was technically invalid—fix the construction process. When you receive a business rejection, it normally signals an issue like an unmatched patient. Build your UI and monitoring to surface these differences clearly to support teams and, where appropriate, to end-users. Additionally, consider how to present the “retry or correct” choice: automatic retries make sense for transient transport issues, but human intervention is usually required for business rejections. The implementation guide’s sections on rejections and OperationOutcome structures are invaluable checklists for this work.
Quality and safety checklist to embed in your build:
Set your testing strategy across four layers: (1) payload conformance, (2) envelope correctness, (3) transport behaviour, and (4) workflow outcomes. For payload conformance, adopt automated validators for the Update Record profiles and keep a library of JSON exemplars for each supported service (Pharmacy First, Blood Pressure Check, Contraception). For the envelope, build unit tests that generate valid ITK3 MessageHeader content and verify the presence of required response request flags. For transport, simulate MESH send/collect with controlled delays and failures to check your retry and back-off logic. Finally, for workflow outcomes, confirm that a complete run—happy path and expected rejections—results in clear, actionable items in your own UI and, when available, in a test GP system’s inbox. This layered approach catches most of the defects that only surface in integrated environments.
Operationally, treat MESH like any other critical dependency. Monitor queue depths, send/collect timings and error rates, and alert on prolonged absence of acknowledgements. Build dashboards that correlate your application-level message states (for example, “awaiting business ACK”) with MESH transaction IDs so that support teams can triage issues without diving into raw logs. A well-designed “message detail” view showing payload identifiers, patient identifiers, timestamps, and the most recent OperationOutcome snippet will pay for itself many times over when you are investigating production incidents.
Release management is another place where disciplined practices bear fruit. The implementation guide evolves, and so do the GP systems that consume Update Record messages. Adopt semantic versioning for your payload builders, keep a compatibility matrix that maps your software releases to the guide version(s) you target, and use feature flags if you need to support multiple payload shapes during a transition. Where the guide introduces, say, a refined mapping to PRSB headings or updated value sets, plan for a “dual-write” period in which you can generate both the old and new forms for specific test practices before rolling a change out widely.
Finally, never lose sight of the clinical workflow. The goal is not merely to “deliver a message” but to enable safe, timely filing by the receiving practice. Small UX touches in your product—like showing whether a pharmacy consultation has been acknowledged by the practice, or warning a user when a patient may have changed registered practice—build trust. Similarly, documenting clear escalation paths when acknowledgements are delayed (for example, when MESH is operating but the practice client has stopped collecting) can turn a potential outage into a routine support ticket rather than a flurry of emails. The catalogue and the implementation guide give you the technical scaffolding; the day-to-day reliability comes from your monitoring, your runbooks and your empathy for the clinicians who rely on your software.
Is your team looking for help with GP Connect integration? Click the button below.
Get in touch