GP Connect Integration, HMRC RTI and DBS Checks in a UK Care Platform

Three statutory systems decide how much re-keying a UK care office does each week: the GP record, the payroll return and the criminal record check. Each has a different gatekeeper, approval route and rule about what a care platform may keep. The proof behind this guide is Allfor Care, a Harrow home care and accessible transport provider whose care-operations platform Sigi Technologies designed and built, integrating GP Connect, HMRC and DBS inside one React and Node.js system.

What is GP Connect integration and what does it involve?

GP Connect is an NHS England service that lets an approved system read a patient’s registered GP practice record. A GP Connect integration is therefore two projects at once. One is engineering, against FHIR application programming interfaces brokered by the NHS Spine. The other is approval: an organization data service (ODS) code, a data sharing agreement, an accepted use case, and named users. NHS England’s guidance for social care providers sets two headline conditions: an assured digital social care record solution, and a Data Security and Protection Toolkit status of standards met.

• GP Connect Access Record: HTML returns a read-only view of the GP record, and NHS England’s implementation guide says it must be used in real time.
• GP Connect Access Record: Structured returns coded data. The published API catalogue lists medications and allergies as live, with other clinical areas in development.
• Requests are brokered by the Spine Secure Proxy, which authenticates the consumer, checks data sharing agreements and logs the transaction.
• The Data Security and Protection Toolkit is an annual self-assessment due by 30 June. Standards met is the level GP Connect access requires.
• HMRC and DBS work nothing like GP Connect. Real Time Information is an XML submission, and DBS offers no employer check API beyond a free status check.

What is the difference between GP Connect Access Record HTML and Structured?

The two capabilities answer different product questions. The Access Record: HTML implementation guide describes an unstructured, pre-rendered format that returns the record by section or heading. It lists ten sections in scope, among them problems and issues, allergies and adverse reactions, medications, observations and immunizations. It is built on FHIR STU3, and the guide states the capability must be used in real time for read only.

The Access Record: Structured API returns coded data from the same record. Its catalogue entry names medications and allergies as available, with consultations, problems, investigations and outbound referrals among the areas still in development. The rule follows from that: HTML if a coordinator needs to read the record, Structured if the platform needs to act on it.

• Choose HTML for a viewer. The HTML API entry describes read-only access to the registered GP practice record, filtered by date range, embedded in an electronic patient record system.
• Choose Structured when data drives logic, and design for a partial record: medications and allergies, not the whole clinical history.
• Plan for both. Most platforms start with HTML, then add Structured when a workflow needs coded data.

What does a care provider need before GP Connect will connect it?

The technical work is not the gate. The approvals are. NHS England’s GP Connect guidance for care providers says the provider must have an assured digital social care record solution and must reach standards met on the Data Security and Protection Toolkit. It also splits access by role. Clinical staff such as nurses and doctors get the full record. Non-clinical staff such as managers, carers and social workers see allergies, medications, immunizations and the last three interactions with the GP practice. Those two views are a product requirement, not a policy footnote.

1. Reach standards met on the Data Security and Protection Toolkit. NHS England says all CQC-registered care providers should complete it at least once a year, by 30 June.
2. Confirm the version in force. The DSPT 2025-26 release note sets version 8, a completion date of 30 June 2026, and alignment to Cyber Assessment Framework version 3.4.
3. Register an ODS code for the organization, because Spine routing is keyed on it and the endpoint lookup starts there.
4. Get the use case approved, then move. Both GP Connect API catalogue entries, including the Structured API, warn that development must start within 6 months of use case approval, or the use case is reviewed or resubmitted.
5. Name the users. Access goes to identified clinical and nominated non-clinical staff, so the permission model must mirror that list, not a generic staff role.
6. Record consent and opt-outs. NHS England’s national data sharing portal states that GP Connect will not share a patient’s data if they have asked their GP not to.

Can a custom-built care platform use GP Connect?

Vendor pages rarely answer this, because the answer is not in their interest. NHS England’s assured solutions list is the set of digital social care record products assured against the DSCR Capability Assessment and Standards Assurance Process. Its guidance for suppliers outside that list states that there is currently no requirement for in-house digital social care records to be assured, that in-house systems must meet the same standards to join the list, and that without assurance, care providers using a solution may be excluded from delivering local authority funded services.

Read that as a sequencing decision rather than a veto. A provider building its own platform can hold its own records without assurance today. But assurance is the route to GP Connect and increasingly to commissioning, so it belongs in the plan from the start. NHS England says this is likely to become increasingly important, so treat published requirements as a moving target.

How does a GP Connect request actually reach a GP system?

A GP Connect call is not one request to a documented base URL. NHS Digital’s Spine Core integration example walks the chain. The consumer performs a Personal Demographics Service trace to verify the NHS number and get the practice ODS code. It calls the Spine Directory Service for the accredited system identifier (ASID) and the FHIR endpoint URL. It then sends the request to the Spine Secure Proxy, which performs security checks and forwards it.

1. Resolve the person. The Personal Demographics Service FHIR API searches for patients and verifies an NHS number, the identifier every later call needs.
2. Look up the practice. The Spine Directory Service turns the practice ODS code into the provider ASID and the service root URL of its FHIR endpoint.
3. Send through the proxy. The Spine Secure Proxy specification describes a forward HTTP proxy that is the single security point for authentication and authorization, and that also audits requests and checks data sharing agreements.
4. Populate the Spine headers. The specification requires Ssp-TraceID, Ssp-From, Ssp-To and Ssp-InteractionID on every call. Ssp-From must carry the ASID of the originating organization, not the hosting one.
5. Secure both legs. All communications use mutual Transport Layer Security, consumer to proxy and proxy to provider.

Two details in the GP Connect API guidance change how a care platform is built. First, the audit token is plain text. The guidance says clients provide an OAuth 2.0 bearer token as a JSON Web Token, and that these tokens are not centrally issued and are not signed or encrypted. Trust lives in the proxy and in the certificate configuration, which mandates TLS 1.2 with mutual authentication. Second, providers must send Cache-Control: no-store so no intermediary caches responses. The GP record is something the platform displays, not something it warehouses.

How does a care platform submit payroll to HMRC under Real Time Information?

Real Time Information is the PAYE reporting regime, and the deadline shapes it more than the payload. HMRC’s guidance on reporting payroll says to use payroll software to send a Full Payment Submission telling HMRC about payments to employees and the deductions made, and to send it on or before employees’ payday. An Employer Payment Summary claiming reductions such as statutory pay goes by the 19th of the following tax month, with the balance paid by the 22nd. For a care platform computing hours from completed visits, the rota must be final before the submission, not after.

• There is no friendly REST endpoint. HMRC publishes Real Time Information internet submissions technical specifications as Rules and Interface Management artefacts, versioned per tax year, plus a local test service.
• Submissions carry an integrity digest. HMRC keeps a separate collection for HMRC(IR)mark, covering IRmark for Gateway Protocol services, for SOAP services, and the generic specification.
• Recognition is not certification. HMRC’s payroll software guidance states that HMRC cannot recommend one product over another and is not responsible for problems with software you have bought.
• Budget for the annual change. A new tax year means a new schema version, so an in-house payroll module needs a yearly slot in the release plan.

The build-or-buy line usually falls here. Reading hours from completed shifts and producing a payslip is ordinary application work. Generating conformant Real Time Information XML and maintaining it every April is a specialist commitment, so many care platforms compute pay internally and hand submission to recognized payroll software.

How do DBS checks work inside a care platform?

Disclosure and Barring Service checks are the integration teams most often mis-scope, because there is no general employer API for running a check on demand. GOV.UK lists four levels of check: basic, standard, enhanced, and enhanced with barred lists, the last of which shows whether the applicant is barred from the role. Care providers usually need the enhanced levels for regulated activity. The platform holds the outcome and the dates, not the decision.

• Status checks are the only free, instant, employer-side call. The DBS Update Service costs the applicant £16 per year, is free for volunteers, and shows whether anything has changed on an existing standard or enhanced certificate. GOV.UK says you need not pay or register for a status check, but you must be legally entitled and have the worker’s permission.
• Bulk submission is a registration, not a subscription. The e-Bulk service lets DBS customers submit multiple electronic applications and receive results electronically. Registration requires more than 1,500 applications in any rolling 12-month period in the last 18 months, plus sufficient IT infrastructure. Smaller providers go through an e-broker.
• Nobody tells you when a certificate goes stale. Status checks are pull, not push, so renewal dates, consent records and a scheduled re-check belong in the platform.

Who signs in, and with which NHS identity?

Two national identity services exist and they are not interchangeable. NHS login is for citizens signing in to health services about themselves. NHS Care Identity Service 2 authentication verifies the identity of healthcare workers in England when they access national clinical information systems, and supports smartcards, iPads, Windows tablets and security keys. A care platform reading GP records is in the second category. Plan for professional identity and the named-user model GP Connect imposes, rather than assuming your own username and password will satisfy it.

What does UK GDPR require once GP record data is in the platform?

Everything pulled from a GP record is special category data. The Information Commissioner’s Office defines data concerning health as personal data related to physical or mental health, including the provision of health care services, which reveals information about health status. It says that includes an identifier assigned for health purposes, such as an NHS number, when combined with information revealing something about health. That covers the whole GP Connect payload and most of a care plan.

The ICO’s guidance on the rules for special category data is that Article 9 prohibits processing unless one of ten conditions applies, and that a controller always needs an Article 6 lawful basis as well. Most care providers rely on health or social care under Article 9(2)(h), which also requires condition 2 of Schedule 1 to the Data Protection Act 2018, an appropriate policy document and records of processing. In build terms: least-privilege roles, audit logging of reads and writes, defined retention, and a data protection impact assessment before go-live.

In what order should you build these integrations?

1. Start the approvals before the code. The toolkit submission, the ODS code and the use case run on NHS timescales, and the 6-month development window starts at approval.
2. Build the permission model first, with clinical and non-clinical views separated. GP Connect grants different records to each, and retrofitting that split touches every screen.
3. Ship DBS tracking early. Certificate numbers, levels, consent and renewal dates need no external approval and remove the most frequent manual check in a care office.
4. Do payroll next. Compute hours from completed shifts, then decide explicitly whether the platform generates Real Time Information itself or hands off to recognized payroll software.
5. Add GP Connect last, HTML before Structured, and treat the record as a live view rather than a stored copy, in line with the read-only and no-store rules.

On budget, statutory integrations are a scope multiplier rather than a line item, because most effort goes on assurance and identity, not endpoints. As a planning estimate, a production platform with authentication, records and a light admin sits in the $80k to $180k band. A multi-surface operations platform with role-specific views, finance and statutory integrations sits in the $150k to $350k and above band, consistent with Sigi’s guide to how much it costs to build a mobile app. Those are typical-scope figures, not a quote and not attached to Allfor Care.

Related reading

The system these integrations plug into is covered in how to build a care management system, and the regulatory frame around it in CQC and UK GDPR requirements for care software. The full product write-up is the Allfor Care case study. If the platform will serve several agencies rather than one, multi-tenant SaaS architecture covers the isolation rules that must hold before NHS data enters it. For scoping, see Sigi’s healthcare software practice, its care operations page or custom software development, or talk to Sigi about an integration plan.