An NHS-facing video or telemedicine platform has to satisfy at least four distinct obligations that a generic consumer video app never touches. DCB0129 governs clinical risk management for the manufacturer who builds the system. DCB0160 governs clinical risk management for the deploying NHS organisation putting it into live clinical use. The DSPT (Data Security and Protection Toolkit) is the NHS’s annual data-security self-assessment. And FHIR / GP Connect is the interoperability layer that lets the platform exchange data with GP records, appointments, and the wider NHS estate rather than a proprietary format. This piece explains what each standard actually requires and what a video-platform engineering team has to build to meet it — written from the builder’s side, not a compliance consultancy’s overview.
What Does “NHS-Compliant Video” Actually Require?
“NHS-compliant video” is not a single certificate you obtain — it’s four separate obligations addressed together. First, DCB0129: clinical risk management if you are the manufacturer building the platform. Second, DCB0160: clinical risk management if you (or your client) are the deploying NHS organisation putting it into live clinical use. Third, the DSPT: the NHS’s annual data-security self-assessment, aligned to the National Data Guardian’s 10 data security standards. [Confirmed — NHS England Digital / dsptoolkit.nhs.uk, verified 2026-07-15] Fourth, FHIR / GP Connect: the interoperability layer, if the platform needs to read patient or appointment context, or write a consultation record back into NHS systems.
Most real NHS video-platform builds need all four addressed together, not any one in isolation. The most common and costly mistake we see is treating them as interchangeable with a US framework — “we’re HIPAA-compliant, so we’re fine.” HIPAA is a United States regulation and satisfies none of the four UK-specific obligations above. If you’re coming from the US side, the architecture disciplines transfer, but the compliance regime does not; the US/HIPAA equivalent of this architecture is a genuinely different set of controls and paperwork. The rest of this piece takes each of the four in turn, then pulls them into a delivery checklist a bid response can cite.
The single most common confusion in NHS-adjacent video projects is who owns which clinical-safety obligation. The standards draw a clean line between building the system and deploying it.
DCB0129 — “Clinical Risk Management: its Application in the Manufacture of Health IT Systems” — applies to whoever builds or manufactures the video platform. That may be Trembit as the engineering partner, or a client building in-house. Its obligations are concrete: appoint a named Clinical Safety Officer on the manufacturer side, establish a Clinical Risk Management System (CRMS), maintain a hazard log throughout development, and produce a Clinical Safety Case Report before release. [Confirmed — NHS England Digital, verified 2026-07-15; current edition v4.2 (2018), mandatory under s.250 HSCA 2012] For a video platform specifically, the hazards on that log are video hazards: a session dropping mid-consultation, a misidentified patient on a multi-party call, recording or PHI leakage into unintended storage, or audio/video desync that could mislead a clinical assessment.
DCB0160 — “Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems” — applies to the deploying NHS organisation putting the platform into live clinical use. [Confirmed — NHS England Digital, verified 2026-07-15; current edition v3.2 (2018)] That organisation appoints its own Clinical Safety Officer and produces its own safety case covering how the platform is configured and used in their environment: which clinical pathways route through video, what the escalation procedure is if video fails mid-consultation, how staff are trained on it. A manufacturer’s DCB0129 sign-off does not substitute for the deployer’s DCB0160 obligations — the two are separate safety cases owned by separate accountable people, and conflating them is the mistake we see most often.
For a typical Trembit engagement, our role is DCB0129-adjacent: we support the manufacturer-side hazard log and safety-case evidence as the engineering team building the system. DCB0160 sign-off always stays with the deploying NHS organisation’s own Clinical Safety Officer. That is not Trembit’s call to make, and we don’t represent it as one.
What Clinical-Safety Artefacts Does a Video Platform Build Actually Need to Produce?
This is where “clinical risk management” stops being an abstract compliance phrase and becomes a backlog of engineering work. Under DCB0129/0160, three artefacts carry the weight.
The hazard log is a living document maintained through development, not a one-time report filed at the end. For a video platform, the entries are specific and technical: session drop mid-consultation; wrong-patient-on-call; recording or PHI leakage via unintended cloud storage; audio/video desync misleading a clinical assessment; and interpreter or third-party-on-call identity-verification gaps. Each hazard names a cause, a clinical consequence, and a mitigation — and each mitigation is a piece of engineering work.
The Clinical Risk Management System (CRMS) is the process wrapper around that log: who reviews it, how often, and how mitigations are tracked to closure. It’s the difference between a spreadsheet of good intentions and a governed process a Clinical Safety Officer can stand behind.
The Clinical Safety Case Report is the document the CSO signs before go-live. It references the hazard log and the mitigations built into the architecture — automatic reconnect plus a clinician alert on drop, patient identity re-verification before rejoining a dropped call, audit logging of who joined and left a session and when.
The point a bid response can lift verbatim: each artefact maps onto specific architecture decisions. The hazard log drives session-drop mitigation logic, redundant TURN/STUN paths so a single network failure doesn’t end a consultation, and audit logging of session participation. Those aren’t compliance overhead bolted on at the end — they’re features you design in from day one, or pay to retrofit under deadline pressure later.
What Is the DSPT, and What Does a Video Platform Need to Assert?
The Data Security and Protection Toolkit (DSPT) is NHS England’s annual online self-assessment measuring an organisation’s data-security practice. The current version is DSPT 2025-26 (version 8), and it is aligned to the National Data Guardian’s 10 data security standards. It is a distinct obligation from DCB0129/0160 clinical safety, though the two are usually required together for an NHS-facing platform.
Who needs one? NHS bodies do. Whether a supplier or vendor handling NHS patient data needs its own DSPT submission — versus demonstrating equivalent assurance to the commissioning NHS organisation — depends on the specific contractual and data-processing relationship. Either way, the platform’s engineering has to support the DSPT’s evidence requirements: encryption in transit and at rest; access control and audit logging (who accessed which session or recording, and when); incident detection and response processes; and documented supply-chain security for every third-party service the platform depends on — TURN/STUN providers, cloud hosting, any AI or transcription vendor. The evidence must be current and specific to your system, not a generic policy PDF.
One 2025-26 change materially raises the bar, and it’s worth separating two things that are easy to conflate. First, Category 1 organisations (NHS trusts, ICBs, commissioning support units, arm’s-length bodies) now assess against the National Cyber Security Centre’s Cyber Assessment Framework (CAF), moving away from checklist-style compliance toward evidence-based, outcome-driven assurance. Second — and this is the part most relevant to a vendor — the independent CAF-aligned audit requirement is not limited to the largest bodies: both Category 1 and Category 2 organisations must undergo an independent audit to validate their submission, and Category 2 is defined as commercial IT suppliers to the NHS (broadly, larger suppliers of digital goods/services), which is exactly the bucket a video-platform vendor or its engineering partner sits in.
If your team assumed a self-attestation was sufficient on its own, that assumption no longer holds — for the NHS bodies you’d deploy into, and potentially for you as their supplier. DSPT also overlaps significantly with UK GDPR and the Data Protection Act 2018 accountability requirements, but it is NHS-specific and broader — the wider telehealth security-and-compliance picture sits alongside it, not inside it.
Does an NHS Video Platform Need FHIR? What Does GP Connect Integration Actually Involve?
Yes — if the platform needs to show patient context (appointment details, relevant GP-record data) before or during a video consultation, or write back a consultation outcome, it has to integrate with FHIR-based NHS APIs, not a proprietary format. NHS national infrastructure — GP Connect, the NHS App, e-Referral Service, Personal Demographics Service — is built on FHIR, so a custom integration approach simply cannot consume from or supply to these systems.
The most common target is GP Connect, which is a family of FHIR-based APIs rather than a single monolithic standard. [Confirmed — NHS England Digital API Catalogue, verified 2026-07-15] The ones that matter for a video build are Access Record: Structured (pulling structured GP-record context like medications, allergies, and problems), Appointment Management (reading and booking appointment context), and Send Document (writing a consultation record back). One integration detail worth knowing before you scope: Access Record: Structured is not a plain RESTful resource fetch — it uses a FHIR Operation where you POST a Parameters resource naming exactly which clinical information you want, a design chosen deliberately for clinical safety.
Concretely, a video-platform build at the integration layer authenticates against NHS APIs (typically via NHS-issued credentials and certificates), queries GP Connect for appointment or patient context before a session starts, and — if in scope — writes a consultation record back. This is genuinely nontrivial integration work, not a plug-and-play SDK, and it carries its own onboarding and conformance testing before an NHS API consumer is approved for production access. For the broader mechanics of FHIR and EHR/EMR integration underneath all this, our CTO’s guide to EHR/EMR and FHIR integration covers architecture patterns and where these projects run long.
What Does an NHS-Compliant Video Delivery Checklist Look Like? (A Methodology a Bid Response Can Cite)
This is the core artefact of the piece: a genuine delivery methodology, not marketing copy, scoped to a video/WebRTC build. It runs in six phases, each with checkable items. It is written so a tender response can lift a phase and cite it.
Phase 1 — Establish governance and standards scope before writing code. Get the obligations pinned down before architecture, because they determine what evidence you have to produce.
- Identify whether DCB0129 (you’re the manufacturer), DCB0160 (you or your client is the deployer), the DSPT, and FHIR/GP Connect each apply to this specific engagement and NHS relationship.
- Confirm who holds the Clinical Safety Officer role(s). Trembit does not fill this role — that appointment is the accountable organisation’s to make — but we support whoever does with evidence.
- Establish the CRMS (review cadence, ownership, closure tracking) so the hazard log has a governed process around it from the first sprint.
Phase 2 — Architect the platform’s hazard-relevant behaviours from day one. The hazard log’s mitigations are engineering features; design them in rather than retrofitting them before a safety-case deadline.
- Session-drop handling and reconnect logic, with a clinician alert on drop.
- Patient and participant identity verification, including re-verification before rejoining a dropped call.
- Recording consent and explicit control over storage location (no PHI leaking to unintended cloud buckets).
- Audit logging of session participants and timing — who joined, who left, when.
- Note: choosing the media-server topology (SFU vs. MCU vs. P2P) is a separate decision with real trade-offs — our SFU comparison for telemedicine platforms covers it; a hazard-relevant point is that server-side recording and observability usually push you toward an SFU.
Phase 3 — Design the FHIR/GP Connect integration layer to the correct profiles, not a generic HL7 implementation.
- Map exactly which GP Connect APIs are in scope (Access Record: Structured for context, Appointment Management for scheduling, Send Document for write-back).
- Confirm the FHIR version and profile per capability — several current GP Connect capabilities (including Access Record: Structured) are on STU3 today, with UK Core (R4) the stated direction of travel — rather than assuming one profile covers everything.
- Plan for NHS API onboarding and conformance testing as a scheduled work item, not an afterthought; production access is gated on it.
- Don’t assume a generic FHIR server “just works” against NHS-specific profiles and code systems (SNOMED CT and friends).
Phase 4 — Build the DSPT-relevant technical controls as standard practice, not a pre-audit scramble.
- Encryption in transit and at rest.
- Access control and audit logging mapped to the DSPT’s specific evidence items.
- Incident detection and response processes that produce evidence, not just documentation.
- Documented supply-chain security for every third-party service the platform depends on (TURN/STUN, hosting, any AI/transcription vendor).
- This is the same engineering discipline as a HIPAA build, mapped to the DSPT’s evidence model — and where both Category 1 (NHS bodies) and Category 2 (commercial IT suppliers) now face an independent CAF-aligned audit, the controls need to survive external scrutiny, not just a self-tick.
Phase 5 — Produce the safety-case artefacts and route sign-off correctly.
- The manufacturer’s Clinical Safety Officer reviews and signs the DCB0129 safety case for the product.
- The deploying organisation’s Clinical Safety Officer reviews and signs the DCB0160 safety case for their specific deployment context.
- Trembit’s role is producing the evidence both CSOs need — architecture documentation, test results, audit logs — never signing either safety case.
Phase 6 — Monitor and keep every artefact current post-go-live.
- Clinical risk management doesn’t end at go-live: new use cases, configuration changes, and platform updates require hazard-log updates and, where material, a fresh safety-case review.
- DSPT is an annual re-assertion, not a one-time submission.
- FHIR/GP Connect API versions and UK Core profile versions evolve; conformance needs periodic re-checking.
Who Does What — Manufacturer, Deploying NHS Organisation, and the Engineering Partner?
Three roles, cleanly separated. Getting this wrong is both a compliance risk and a positioning risk, so we state it plainly.
The manufacturer carries the DCB0129 obligations: a named Clinical Safety Officer, a CRMS and hazard log, and ownership of the Clinical Safety Case Report for the product itself.
The deploying NHS organisation carries the DCB0160 obligations: its own Clinical Safety Officer, its own safety case for its operating context, and — as the accountable body handling NHS patient data — the DSPT submission for that context.
The engineering partner (Trembit’s role) builds the compliant platform architecture, the hazard-relevant engineering controls, the DSPT-supporting technical evidence, and the FHIR/GP Connect integration layer — giving both Clinical Safety Officers and the information-governance team what they need, without holding either CSO role or submitting a client’s DSPT as the accountable organisation.
To be unambiguous: Trembit does not sign a Clinical Safety Case Report, does not submit a client’s DSPT assertion as the accountable body, and does not hold a specific NHS clinical-safety accreditation. Trembit is the team that makes the system those accountable parties are reviewing actually meet the standard. The accurate description of our practice is clinical risk management aligned to DCB0129/DCB0160 practice and DSPT-aligned governance design — engineering-practice alignment that produces the evidence, not a vendor certificate that replaces the accountable roles.
How Does Trembit Approach NHS-Compliant Video Delivery?
We build regulated-healthcare video to the same audit-grade discipline these NHS standards demand — and our proof is in specific delivery, not in a certificate we don’t hold.
Taking a healthcare video product through a national regulator (KBV, Germany). Trembit built and supported certification of a psychotherapy video platform (webPRAX) through Germany’s KBV — the Kassenärztliche Bundesvereinigung — one of the most restrictive healthcare-video standards in Europe, with Germany-only data residency, peer-to-peer WebRTC, and on-premise STUN/TURN so no third-party service ever routes the media.
is a distinct standard in a different jurisdiction from the NHS’s, but it demanded the same category of rigour — clinical-grade risk management with no precedent to follow — that DCB0129/0160 and the DSPT demand. To be explicit: holding KBV certification does not itself satisfy any DCB0129, DCB0160, or DSPT obligation — it’s evidence of the discipline we bring, not a substitute for the UK-specific safety cases and assessments those standards require. See the KBV psychotherapy platform case study.
Audit-grade engineering discipline at scale (HIPAA + SOC 2). Trembit delivered a WebRTC video-interpretation platform (Martti / Equiti Health) used across 4,000+ healthcare facilities, integrated with Epic, Oracle Cerner, and eClinicalWorks EHR systems, built to HIPAA and SOC 2 with 99.99% uptime.
FHIR/GP Connect integration capability. Trembit’s healthcare-interoperability practice covers FHIR (including UK Core), HL7 v2/v3, and NHS integration patterns — GP Connect, the NHS App, e-Referral Service, and PDS. [Confirmed — internal capability, per Trembit system-integration practice; note: capability/methodology evidence, NOT a named completed NHS integration project] We’re direct about the boundary rather than dressing it up: we haven’t yet taken this specific GP Connect stack through NHS conformance for a named trust. What we bring to one when we do is the same FHIR/UK Core methodology behind our EHR-integration delivery at scale (the Epic/Oracle Cerner/eClinicalWorks work on Martti), applied with the clinical-safety discipline KBV demanded — which is a stronger starting point than a first-timer’s, and we’d rather say exactly where the line is than imply an NHS delivery we don’t have.
If you’re architecting an NHS-facing video platform and need a partner who understands both the media path and the clinical-safety and interoperability paperwork around it, that’s the work behind our NHS-facing telemedicine platform development practice.
