Written by Technical Team | Last updated 05.09.2025 | 12 minute read
The Booking and Referral Standard (BaRS) is NHS England’s framework for moving patients and their information between services using open standards, with minimal friction and maximum safety. Rather than a single monolithic product, BaRS is a layered architecture and a body of guidance that lets vendors implement booking and referral flows consistently across care settings. At its heart sits a FHIR R4 model and a small number of well-defined API behaviours that make it possible to pass a patient from one service to another—urgently or routinely—without bespoke point-to-point builds each time.
BaRS is intentionally opinionated about transport and interoperability while leaving room for clinical variation. The “Core” layer defines how systems talk to each other (transport and security), the “Workflow” layer describes the sequence of operations needed for a particular patient journey, and the “Payload” layer defines the FHIR resources the receiver needs to do the job. Standardising these where it makes sense—and allowing carefully bounded flexibility where it doesn’t—means suppliers can build once and reuse across multiple use cases, from NHS 111 to Emergency Departments, to ambulance services and community pathways.
To simplify connectivity at scale, NHS England provides optional central infrastructure. A routing proxy (the BaRS API) brokers requests from senders to receivers based on a service identifier, so senders don’t need to know the receiver’s physical endpoint. An endpoint catalogue underpins this, and a registry/events capability is being developed to support discovery and notifications about active bookings/referrals. You integrate with the proxy; the proxy handles routing and passes through the identity and audit headers you supply.
From a developer’s perspective, BaRS gives you one front-door pattern to implement: authenticate with the NHS platform, include the required headers, and either call RESTful read endpoints (for things like slots or capability) or POST a FHIR Bundle to $process-message when you’re creating or updating bookings/referrals. The target service receives your request via the proxy, processes it, and returns a FHIR-conformant response synchronously. Where the use case requires a later status update (for example, a “did not attend” response), the roles simply reverse and the receiver becomes a sender for that outbound message.
At the FHIR layer, BaRS uses familiar UK Core profiles and a small set of resources to model bookings and referrals. Bookings are typically represented using Appointment, with availability exposed via Slot and Schedule, while referrals are represented using ServiceRequest. When you need to convey a complete interaction—say, sending a new referral together with enough clinical context for safe triage—you package the relevant resources into a Bundle and POST it to the receiver’s $process-message operation via the BaRS API. A MessageHeader at the front of the Bundle signals what you’re asking the receiver to do (the event), why (the reason), and which resource is the focus.
The BaRS API also exposes RESTful reads that help you discover capability and availability without bespoke integrations. You can GET the server’s CapabilityStatement at /metadata, retrieve MessageDefinition resources to see payload expectations for a workflow, and query for slots to support appointment workflows. These reads are synchronous and follow standard FHIR semantics; if the receiver cannot fulfil a request, it returns a FHIR OperationOutcome with an appropriate HTTP status.
When building messages for $process-message, the receiver determines the payload it needs. That’s a deliberate design choice: instead of the sender dumping everything it knows, the receiver’s MessageDefinition and CapabilityStatement make it clear which profiles, elements and cardinalities are required for the workflow. Practically, that means your sender logic should read the relevant MessageDefinition, assemble a Bundle that meets those constraints, and only then call $process-message. The benefit is a coherent, receiver-shaped payload every time, reducing ambiguity and rework.
Service discovery is a separate step. BaRS expects you to determine a service to send to—via national or local directories or preconfigured partners—and then supply a service identifier in your request so the proxy can route it to the right receiver. If you’re testing in the Integration (INT) environment, the Toolkit Workbench (TKW) uses “sentinel” values for service IDs and NHS numbers to elicit deterministic behaviours (for example, returning specific Appointment or ServiceRequest identifiers, or exercising error paths such as 404/409/422). This makes end-to-end testing realistic without having to wire up multiple live systems.
To keep your build tidy, anchor your integration around a few recurring FHIR artefacts and API touches:
Security in BaRS is provided by the NHS API platform. As a sender, you authenticate using OAuth 2.0 with the private key JWT pattern: you sign a JWT with your 4096-bit RSA private key, exchange it for an access token at the NHS OAuth endpoint for your environment, and include that access token in the Authorization header on every request to the BaRS API. Receivers that expose endpoints for responses will also integrate with the platform so they can send follow-up messages back via the same route. In production, mutual TLS (“TLS MA”) is enforced between the platform and receiver endpoints using NHS Root CA-issued certificates.
Beyond bearer tokens and mutual TLS, BaRS relies on a small set of HTTP headers for routing, authorisation and transactional integrity. The routing header is NHSD-Target-Identifier—a Base64-encoded JSON object that identifies the service the proxy must route to. For authorisation context, senders are expected to include structured identity headers describing the organisation (NHSD-End-User-Organisation, based on a FHIR Organization), the requesting clinician (NHSD-Requesting-Practitioner, based on a PractitionerRole), and the requesting software (NHSD-Requesting-Software, based on a Device). These are passed through to receivers so they can make access control decisions without inspecting payload bodies.
For transactional integrity, every request must include X-Request-ID (a unique UUID for that network request) and X-Correlation-Id (a UUID that ties all related requests for the same business transaction together). Receivers store both values and must detect duplicate deliveries; if the same request is retried with unchanged headers and body, the correct response is HTTP 409 with an OperationOutcome issue code of duplicate. Your client should therefore implement idempotent retry behaviour that preserves both IDs across attempts until a definitive success or error is received.
Token management follows standard OAuth hygiene. Generate and sign JWTs only when needed, request tokens from the appropriate environment endpoints (dev, int, or api.service.nhs.uk), and cache tokens until expiry to avoid unnecessary round-trips. For production endpoints, ensure your trust store contains the current NHS Root CA and SubCA certificates and automate renewal to keep the mTLS channel healthy.
Finally, remember that receivers must be able to accept or reject requests solely based on headers and context. That obliges senders to populate the organisation, user and software headers accurately and consistently. It also means your audit trail should log access token claims alongside all BaRS headers so that incidents can be traced end-to-end across the proxy boundary.
From a workflow perspective, BaRS supports both synchronous reads and message-based write/update interactions. Reads are straightforward: fetch the capability statement at /metadata, obtain MessageDefinition resources to understand payload structures, and query for Slot availability to drive patient scheduling. Writes and state changes are performed using $process-message: compose a Bundle whose MessageHeader signals the event (for example, booking-request or servicerequest-request), the reason (such as new or update), and the focus (often the Appointment or ServiceRequest). The receiver inspects the headers and the Bundle, performs the action, and replies with a synchronous FHIR response. BaRS does not use the asynchronous $process-message flag; where later updates are required (for example, safeguarding “did not attend”), they are modelled as separate request–response loops with the roles reversed.
Real-world variants are expressed as BaRS “Applications”—packaged guidance for specific journeys (such as NHS 111 to Emergency Department, or 999 Ambulance to Clinical Assessment Service). Each application constrains the payload and steps just enough to ensure safe, interoperable hand-offs between particular service types. That lets you reuse most of your code and only swap in the payload constraints and minor flow differences. During development, the INT environment’s TKW portal simulates these behaviours with scenario-driven responses, including deterministic IDs and specific error codes, so you can test happy paths and edge cases without a full partner stack.
Errors are handled using FHIR OperationOutcome with clear HTTP status codes, aligning with NHS API patterns used elsewhere. Your sender should parse both the HTTP status and the OperationOutcome to determine next actions—correct a missing or invalid element (400), back off and retry later (429/503), or treat a 409 duplicate as success for idempotent operations depending on business rules. For reads, follow FHIR semantics (for example, 404 not-found when a resource does not exist); for writes, ensure your retrier respects the “definition of a retry” in BaRS, which requires no change to headers or body between attempts.
Onboarding and assurance are formalised. You’ll register your application on the NHS platform, upload or point to a JWKS for your public key, add the BaRS API to your app, and then develop against Sandbox and INT. Assurance evidence is gathered through the Digital Onboarding Portal using the Supplier Conformance Assessment List (SCAL). You’re expected to demonstrate end-to-end functionality in INT and show compliance with clinical safety (DCB0129), and to integrate hazards from the BaRS clinical safety case into your own hazard log. When approved, you can deploy to production with the appropriate certificates installed.
A pragmatic path to production looks like this:
BaRS sets you up for scalable interoperability, but you still need to engineer for production reality. Build idempotent client behaviour around X-Request-ID and X-Correlation-Id, with structured logging that emits both on every call, and propagate the correlation ID through your internal services so incidents can be traced across systems and the proxy boundary. Monitor request rates, latency to and from the BaRS API, and response mix (2xx/4xx/5xx), and use back-off strategies for throttling or transient outages surfaced as 429/503. Remember that receivers make access decisions from headers, so treat those Base64-encoded FHIR identity objects as first-class inputs: validate them before send, and alert when they’re missing or malformed.
From a governance perspective, ensure your DPIA and information governance artefacts reflect the data categories in your BaRS payloads and the facts that identity and audit data traverse the proxy. Align with the DSP Toolkit and clinical safety standards, and adopt secure-by-default HTTP practices (appropriate TLS configuration and security headers on your own endpoints) even though BaRS doesn’t require additional response headers beyond HTTP and transactional integrity. In short: implement the BaRS patterns faithfully; instrument your integration thoroughly; and treat identity, audit and error handling as core product features rather than afterthoughts.
Unlike legacy point-to-point integrations, the NHS BaRS API is built on modern FHIR standards, which makes it interoperable across a wide range of healthcare applications. Legacy systems often required bespoke connections for each partner, while BaRS provides a unified and reusable framework that reduces development overheads and simplifies scaling.
For vendors, BaRS integration provides a consistent pathway into NHS digital services without needing multiple custom builds. It also creates opportunities to offer products nationally, since the same BaRS specifications are recognised across NHS England. This improves market access and ensures solutions remain compliant with NHS interoperability roadmaps.
Yes. Cloud-native applications can consume the BaRS API just as on-premise systems do. The key is ensuring that the cloud platform is configured with the appropriate NHS security standards, including OAuth2.0 for authentication and the correct handling of audit data. This makes BaRS particularly attractive for vendors delivering SaaS healthcare platforms.
Developers should be comfortable with RESTful APIs, FHIR resource modelling, and secure API authentication. Knowledge of healthcare data standards and NHS interoperability guidelines is an advantage. Teams also benefit from experience with OAuth2.0, PKI certificates, and automated testing against sandbox environments.
The API enables smoother referrals and bookings across services, reducing delays caused by manual processes or incompatible IT systems. By enforcing a standardised digital approach, BaRS plays a key role in the NHS’s move toward integrated care systems, supporting faster access to the right service and better patient experiences.
In addition to the official NHS integration environments, developers can use API simulators and automated testing frameworks to validate payloads and workflows. These tools help verify that requests meet BaRS specifications before moving into formal assurance stages, reducing risk during onboarding.
While not every service is yet required to use BaRS, it is part of the NHS’s long-term interoperability strategy. Over time, more referral and booking journeys will migrate to the BaRS standard, making adoption a strategic priority for organisations planning future integrations.
Through reducing administrative friction and enabling more accurate, timely referrals, BaRS helps ensure patients reach the right service more quickly. This reduces waiting times, minimises the chance of missed information, and supports safer, more efficient care transitions.
Is your team looking for help with NHS BaRS API integration? Click the button below.
Get in touch