Why Assurance Load Increases Non-Linearly
Clinical safety assurance was designed for a world where health IT systems were fewer, more stable, and more clearly bounded. That world is changing.
Digital health programmes now deploy more systems, integrate more frequently, and change more continuously than the assurance model anticipated. Each new system requires assessment. Each integration creates new hazard surfaces. Each change potentially invalidates prior assurance.
Clinical Safety Officers absorb this load. They assess, document, review, and re-assess. The work is essential. But the model scales linearly with system count while complexity scales combinatorially with integration density. The gap between these curves is where pressure accumulates.
This is not a critique of the standards or the people applying them. It is a structural observation about what happens when an assurance model designed for bounded systems meets an environment of continuous integration.
Signal: When assurance becomes a constraint on safe deployment, the model needs to evolve, not the commitment to safety.
Document-Centric Assurance and Its Limits
The prevailing model of clinical safety assurance is document-centric. Safety cases, hazard logs, clinical risk management plans. These artifacts establish that a system is safe at a point in time.
This model has clear strengths. It creates auditable records. It forces systematic hazard identification. It provides a basis for accountability. For stable, bounded systems, it works well.
The limits emerge under three conditions:
Continuous Change
When systems change frequently, the gap between documented state and operational state grows. Assurance artifacts describe what was assessed, not necessarily what is running. Keeping documentation current with deployment velocity is labour-intensive and often lags behind reality.
System Integration
When systems integrate, new hazard surfaces emerge at the boundaries. The safety case for System A and the safety case for System B do not automatically produce a safety case for A+B. Integration requires fresh assessment, even when both components are individually assured.
Cross-Organisational Boundaries
When data and responsibility cross organisations, assurance visibility degrades. The receiving organisation cannot easily verify what assurance the sending organisation has established. Trust is assumed rather than evidenced.
Signal: Document-centric assurance captures safety at a point in time. Continuous operation requires safety as an ongoing property.
Continuous Assurance as a System Property
The alternative to periodic, document-centric assurance is continuous assurance: treating clinical safety as a property of the system that can be verified at any moment, not just at assessment milestones.
Continuous assurance does not replace documentation. It changes what documentation represents. Instead of capturing a point-in-time assessment, documentation becomes a specification that the system continuously validates against.
What Continuous Means
In a continuous assurance model, safety evidence is generated as the system operates. Hazard controls are monitored, not just documented. Deviations are detected, not discovered in retrospective review. The question shifts from "was this system safe when we assessed it?" to "is this system safe now?"
What This Requires
Continuous assurance requires safety specifications to be machine-readable, not just human-readable. It requires operational telemetry that maps to hazard controls. It requires infrastructure that can evaluate safety posture in real time.
This is a higher bar than document-centric assurance. But once established, it scales differently. Adding a new system to an environment with continuous assurance infrastructure is less burdensome than adding it to an environment that relies solely on periodic assessment.
Periodic Assessment
Safety established at review points
Documentation describes assessed state
Changes require re-assessment
Assurance load scales with system count
Continuous Assurance
Safety verified during operation
Specifications validated continuously
Changes validated against specifications
Assurance infrastructure absorbs scale
Composable Assurance
For assurance to scale, it must be composable. Safety evidence established for one component must be inheritable by systems that incorporate that component.
Consider identity verification. A system that verifies patient identity establishes certain safety properties. Every downstream system that receives data from this source inherits those properties, provided the chain is intact. The downstream system should not need to re-establish identity assurance from scratch.
This is composability: the ability to build safety cases from pre-assured components rather than from first principles each time.
What Makes Assurance Composable
Structured Evidence
Safety evidence in machine-readable formats that can be consumed by other systems and assurance tools.
Clear Boundaries
Explicit definition of what safety properties a component guarantees and what it requires from its environment.
Maintained Provenance
Traceable chain from original assurance through all transformations and integrations.
Version Alignment
Assurance evidence that remains valid as components evolve, with clear invalidation when assumptions break.
What This Enables
When assurance is composable, integration becomes safer and faster. A new system built on pre-assured components starts with established safety properties rather than a blank hazard log. The CSO role shifts from repeated first-principles assessment to validation that composition is sound.
This does not eliminate the need for clinical safety expertise. It amplifies that expertise by allowing it to compound rather than reset with each new system.
Signal: Composable assurance allows safety evidence to accumulate as an organisational asset rather than dissipate with each programme.
What This Means for Clinical Safety Practice
Moving toward continuous, composable assurance does not require abandoning current practice. It requires evolving how that practice operates.
For Clinical Safety Officers
The CSO role remains essential. What changes is leverage. Instead of repeatedly assessing similar hazards across similar systems, CSOs can establish assurance patterns that propagate. The expertise becomes embedded in infrastructure rather than consumed by repetition.
This requires new skills: understanding how to specify safety properties for machine consumption, how to evaluate composed assurance, how to maintain oversight of continuous verification systems. The role becomes more architectural without becoming less clinical.
For System Suppliers
Suppliers who structure their safety evidence for composability gain market advantage. Their systems integrate with less friction. Their assurance artifacts have value beyond the immediate deployment. The investment in structured safety evidence pays forward.
For Deploying Organisations
Organisations that build assurance infrastructure gain cumulative benefit. Each well-assured system makes the next integration easier. The alternative, rebuilding assurance from scratch for each deployment, becomes increasingly expensive relative to organisations that compound.
For Regulators
Continuous assurance provides richer evidence than periodic assessment. Real-time safety posture is more informative than point-in-time documentation. The regulatory question becomes not just "was this assessed?" but "is this operating within assured parameters?"
Relationship to DCB 0129 and DCB 0160
DCB 0129 (manufacturer) and DCB 0160 (deployer) define clinical risk management requirements that remain foundational. Nothing in this analysis suggests departing from these standards.
The question is operational: how do organisations apply these standards efficiently at scale?
The standards require hazard identification, risk assessment, risk control, and residual risk acceptance. They do not prescribe how evidence is structured, how it persists, or how it composes across system boundaries. These operational choices determine whether compliance scales.
Continuous, composable assurance is a way of meeting DCB requirements that anticipates scale. It front-loads investment in assurance infrastructure to reduce ongoing burden. It treats safety evidence as a durable asset rather than a point-in-time deliverable.
Organisations that adopt this approach remain fully compliant with DCB 0129 and DCB 0160. They simply operationalise that compliance in a way that compounds.
How This Connects
Assurance at scale is one dimension of governance infrastructure. It connects to broader questions about how governance operates across boundaries and over time.
These pages describe governance as infrastructure: capabilities that compound when shared, and reset when rebuilt.
Frequently Asked Questions
What is continuous clinical safety assurance?
Continuous assurance treats clinical safety as an ongoing system property rather than a point-in-time assessment. Instead of establishing safety through periodic review and documentation, continuous assurance embeds safety evidence into the operational fabric of the system, allowing it to be verified at any moment and to evolve as the system changes.
Why does document-centric assurance struggle at scale?
Document-centric assurance works well for stable, bounded systems. As systems multiply, integrate, and change continuously, the documentation burden grows non-linearly. Clinical Safety Officers must assess increasingly complex system interactions, and assurance artifacts created for one configuration may not reflect the current state. The model does not scale with the complexity it is asked to govern.
What does composable assurance mean?
Composable assurance means that safety evidence established for one component can be inherited by systems that incorporate that component, without requiring complete reassessment. When a clinical safety case is built on composable foundations, new integrations can reference existing assurance rather than rebuilding it. This requires safety evidence to be structured, machine-readable, and maintained as the component evolves.
How does assurance at scale relate to DCB 0129 and DCB 0160?
DCB 0129 and DCB 0160 define clinical risk management requirements for manufacturers and deployers of health IT systems. These standards remain essential. The question at scale is not whether to apply them, but how to apply them efficiently when systems are numerous, interconnected, and continuously changing. Assurance at scale is about operational models that make DCB compliance sustainable, not alternatives to it.
Exploring Assurance at Scale?
We work with CSOs, digital teams, and governance leads on practical approaches to clinical safety assurance that compound rather than reset.
Book a discovery call