Written by Technical Team | Last updated 17.10.2025 | 11 minute read
GP Connect Access Record: HTML is the national capability that lets accredited consumer systems display a patient’s registered GP practice record in a human-readable form, returned as HTML. It is strictly read-only and intended for direct care, making the GP record visible in other care settings—urgent care, secondary care portals, community services or another GP practice—without the overhead of importing and reconciling coded entries. In essence, it renders the GP system’s “view” of the patient in a safe, consistent way you can embed in your application.
The API exposes definable “sections” or “headings” (for example, medications, allergies, problems, immunisations, encounters and more) and allows date-range filters for large sections. That means you can retrieve only what’s clinically relevant to the current episode, while keeping response sizes and rendering performance predictable. Because the payload is HTML, it slots neatly into clinician-facing portals and EPRs where speed, clarity and provenance matter more than data import.
Although it sits alongside other GP Connect capabilities, Access Record: HTML has a unique purpose. “Structured” delivers machine-readable coded data (FHIR resources) for downstream processing; “Document” exposes discrete documents; Appointment Management handles booking. Access Record: HTML complements these by giving you a fast, low-friction way to show what the GP system itself would show in clinic—reducing ambiguity from variations in coding or layout. Many programmes use it as a first step to enable visibility quickly, while planning deeper “Structured” integrations as a next phase.
Most importantly, Access Record: HTML is brokered through the NHS Spine and governed by national information governance and clinical safety expectations. You do not connect directly to every GP system one-by-one. Instead, your accredited consumer connects via Spine to the GP system’s provider endpoint, with common patterns for authentication, audit and authorisation. This simplifies your footprint and centralises the assurance model.
From a solution-architecture standpoint, think of the flow like this: your consumer app (for example, an acute trust portal) invokes the Access Record: HTML API exposed via Spine; Spine routes the request to the patient’s registered GP practice’s principal supplier; the supplier system assembles the requested sections and returns an HTML bundle that your app can render. The UX is your responsibility, but the content is the GP system’s authoritative view, delivered in a consistent way.
Under the hood, GP Connect is specified using FHIR, and the Access Record: HTML capability is part of the 0.x lineage historically aligned to FHIR DSTU2/STU3 profiles for the purposes of GP Connect. You’ll encounter profiles and artifacts tailored for GP Connect, but the key point for implementers is that you do not parse FHIR resources for this capability—your integration is concerned with transport, security and safe embedding of the HTML output. If you need coded entries to reconcile, pivot to Access Record: Structured, which deliberately exposes problem lists, medications, allergies, immunisations and observations as FHIR resources.
Discovery and routing are Spine-mediated. You will use the Spine Directory Service (SDS) to identify the provider endpoint for the registered GP practice. Many teams pair this with a PDS (Personal Demographics Service) trace to confirm NHS number and demographics before requesting the record. The pattern is: confirm the patient (PDS), locate the endpoint (SDS), then request the HTML sections from the practice’s GP system via Spine.
Across the programme, the current catalogue entries make clear that Access Record: HTML is strictly for viewing the primary care record, and the consumer system is expected to respect date filters and headings. This keeps the payload lightweight and clinically targeted. Remember that, unlike structured data, the HTML view is not designed for your database; it is designed for clinicians to read. That difference has architectural consequences, especially around caching, accessibility and provenance surfaces in your UI.
Security and governance are not bolt-ons here; they are the heart of the integration. You are surfacing sensitive, legally protected health information that originates in primary care systems, across organisational boundaries. The controls expected of your implementation span technical, clinical and operational domains, and need to be designed from day one.
A successful integration follows a well-trodden path: prove the basics early, involve clinicians continuously, and harden the solution with real-world operational learnings before you scale across sites. While every organisation has nuances, the technical and product steps below map to what national guidance and supplier onboarding patterns expect to see.
Clarify which clinicians in which settings will use the HTML view and why. Triage and emergency departments often benefit from medications, allergies and recent encounters; community teams may rely on immunisation status and care plans; GP out-of-hours clinicians want a succinct problem list and recent labs. Agree the minimal sections and date ranges that deliver clinical value without overwhelming users, and bake those defaults into your request parameters.
Implement your PDS trace step for NHS number confirmation, then wire in SDS lookup for the registered practice endpoint. Use national test facilities or demonstrators to validate your routing logic before you attempt live requests. Logging around these steps is non-negotiable—when a request fails in production, you’ll need to know quickly whether it was identity, endpoint, routing or provider availability at fault.
Embed the HTML in a container that adds a standard “provenance banner” (patient name, DOB, NHS number, GP practice, retrieval timestamp and your organisation’s name) so clinicians know exactly what they’re looking at and where it came from. Offer a collapsible table of contents mapping to the headings returned. Provide quick anchors for “Medications”, “Allergies” and “Problems” and a prominent “Last updated” to manage expectations. Apply accessible typography and ensure assistive technologies can navigate the content reliably.
Provider endpoints will sometimes be slow or unavailable (maintenance windows, connectivity issues, high load). Your viewer should show a clear, non-alarming message that the GP record could not be retrieved right now, log the failure, and offer an alternative action (for example, retry, consult Summary Care Record if available, or proceed with local notes). Make error messages operationally useful (correlatable IDs, timestamps) without leaking sensitive details.
One overlooked strength of Access Record: HTML is its speed to value. You can deliver meaningful clinical visibility in weeks because you are not modelling and reconciling data; you are showing the source system’s truth. That said, there are practical nuances to get right if you want clinicians to trust and rely on the view during busy shifts.
Start with section selection and date scoping. The temptation is to pull “everything” so nobody ever misses anything. In reality, an emergency clinician wants clarity fast: current medication list, adverse reactions, active problems and recent encounters in a short window are usually sufficient. Resist over-fetching. Use the API’s support for sections and date filters to shape responses to the clinical context—then let power users expand for more detail when needed. This approach keeps pages responsive on slower networks and focuses attention on the most safety-critical information.
Rendering the returned HTML safely is a core engineering concern. Treat it as untrusted content coming from a trusted partner: render within a hardened frame, enforce Content Security Policy, and avoid executing any inline scripts. Strip or sandbox elements that could interact with your host environment in unintended ways while preserving clinical fidelity (for example, tables, lists and headings). If your UI theme uses dark mode, verify contrast and readability with the provider’s markup—don’t assume their colours will match yours. Accessibility checks must include screen-reader navigation within the content region.
Provenance and audit deserve particular attention. Clinicians should see at a glance which GP practice produced the view and when the snapshot was generated. Behind the scenes, your logs need to capture the user identity, role, patient context, practice endpoint, request parameters (sections and date range), response status and latency. These data points make service management and incident response tractable—especially when you operate at regional scale across dozens of practices and multiple providers. Many organisations standardise an “Access Record audit” dashboard so clinical safety officers can track usage patterns and surface anomalies.
Finally, plan for the broader ecosystem. As your programme matures, you’ll likely add Access Record: Structured to import particular data elements into your local EPR (for example, a trusted medication reconciliation workflow) and the “patient facing” variants to power citizen services. By starting with HTML today, you build a bridge that enables clinicians now, while creating organisational muscle memory—routing, identity, audit—that you can reuse when you step up to coded data flows.
Design your access pattern so a clinician explicitly selects or confirms the patient context before the record is fetched. This can be as simple as requiring a scanned wristband or a PAS lookup to set context, then presenting an interstitial “Access GP record for [name]?” with a brief purpose statement. That design reduces accidental “drive-bys” and teaches staff what’s happening. On the back end, ensure your JWT or equivalent includes the minimum set of claims needed for authorisation and audit, and that those claims are validated by your API client before a request is even attempted.
Some patients have extensive histories with hundreds of encounters. Where providers expose long lists in the HTML view, consider lazy-loading or virtual scrolling within your container to keep the UI fluid. Your date filters are your best friend: default to a clinically meaningful window (for example, 12 months for encounters) and let users expand as needed. The goal is to prevent the “spinning beachball” experience on the wards, especially on shared PCs or constrained VDI sessions.
Conflicts between what a clinician sees in your EPR and what appears in the GP view are inevitable. Your product should make it obvious that the HTML is the GP system’s current view and provide a single-click way to capture a screenshot or a PDF for clinical discussion, without turning that artefact into part of your structured record. Put differently: enable escalation and reconciliation workflows, but don’t allow ad-hoc copy/paste of HTML into coded fields.
Most teams underestimate the time they’ll spend on assurance artefacts. Start early: compile your hazard log, clinical safety case, DPIA, cybersecurity posture and operational runbooks while you build. Use the national demonstrator and sandbox endpoints to exercise your code paths (including the awkward ones like timeouts, 4xx/5xxs and “no content for section”). When you enter onboarding, you want to show not just that the “happy path” works, but that your system handles stress like a proper clinical service.
Be transparent in your UI about the scope of what’s shown. If the Access Record: HTML view does not include historic scanned documents or third-party attachments from certain time periods, say so. If a section is empty because nothing has been recorded, show an “Empty section” message rather than a blank pane. Small touches like this build clinician confidence and mitigate the risk of incorrect conclusions based on missing content.
Is your team looking for help with GP Connect integration? Click the button below.
Get in touch