Key Takeaways
- The audit is not a standalone product — it is stage one of a three-stage engagement that ends with governed boundaries operating in production
- Cross-boundary remediation must be co-designed because the governance gap exists in the space between organisations, owned by neither
- The lighthouse project is not a proof of concept — it is a governed boundary operating in production at a single crossing point for twelve weeks
- The board business case draws on three evidence sources: audit risk quantification, lighthouse operational impact, and the sequenced remediation roadmap
- Cloud programme funding aligns naturally with the audit engagement — the assess phase offsets discovery costs and migration credits reduce infrastructure investment
- Each successive boundary deployment is faster and cheaper than the last because foundational governance controls serve multiple boundaries
Series: Clinical Governance Between Private Healthcare Providers — This is Article 3 of 4. Article 2 described the audit methodology. This article explains what happens next: how audit findings become a remediation plan, a lighthouse project, and a funded business case. View the full series →
The second article in this series described how the Seven Flows Boundary Governance Audit diagnoses risks at the crossings between healthcare organisations. This article explains what happens next: how audit findings become a remediation plan, a working lighthouse project, and a funded business case for the board.
- Map material boundaries
- Constitutional domain analysis
- Seven Flows scoring with cascading failure
- Cross-organisation evidence reconciliation
- Technology readiness assessment
- Both sides of the boundary in the room
- Define governed state for priority boundary
- Specify integration requirements
- Minimum viable change identification
- Lighthouse project specification
- Governance platform deployed at one boundary
- Governed operation in production
- Performance data collection
- Maturity re-assessment
- Board business case evidence
The problem with audit reports
The standard governance audit cycle is well understood: assess, report, recommend, re-audit. It works within organisations because the entity reading the report is the same entity that controls the processes being assessed. The medical director who receives the findings is the same person who can change the discharge protocol.
Cross-boundary governance does not have this property. When a Seven Flows audit identifies that the pathway between a private hospital and an insurer’s triage function has an Identity score of 1 and a Clinical Intent score of 0, neither organisation can fix that alone. The hospital controls its end of the boundary. The insurer controls the other. The remediation must be co-designed, because the governance gap exists in the space between them — owned by neither, experienced by both.
This is why the audit is not a standalone product. It is the first stage of a three-stage engagement designed to move organisations from diagnosis to governed operation.
Stage 1: Diagnose
The audit itself. Duration depends on the scope: a rapid assessment of a single material boundary takes two to four weeks; a standard network assessment covering five to eight boundaries takes four to six weeks; an enterprise assessment of a full portfolio or PE-held group takes ten to sixteen weeks with phased boundary analysis.
The output is a scored assessment of every material boundary, with each of the seven flows rated on a five-level maturity scale and adjusted for cascading dependencies. The report includes statutory traceability — each finding linked to the regulation it engages — a constitutional domain map showing the legal and regulatory frameworks operating on each side of each boundary, a technology readiness assessment, and a prioritised remediation roadmap.
The roadmap is the bridge to Stage 2. It does three things. It sequences boundaries by risk exposure, so the most dangerous crossings are addressed first. It sequences interventions by dependency, so foundational failures in Identity or Clinical Intent are resolved before downstream flows are attempted. And it identifies the single boundary that is the strongest candidate for the lighthouse project.
Stage 2: Co-design
The remediation cannot be designed by consultants and handed to the client as a set of recommendations. Both sides of the boundary must be in the room. The co-design phase brings together clinical, technical, governance, and commercial stakeholders from the organisations on either side of the priority boundary and works through four questions:
What does governed look like here? For this specific boundary, with these constitutional domains, these systems, these clinical pathways — what does a Level 3 maturity state actually require? The audit methodology defines the general criteria. The co-design phase translates those criteria into specific operational requirements for this crossing.
What is the minimum viable change? Not every boundary needs a full infrastructure deployment on day one. Some boundaries can reach Level 2 through process redesign and documented agreements alone. Others — particularly those with Identity failures or absent Clinical Intent — require system integration. The co-design identifies the minimum intervention that achieves a meaningful maturity improvement at the priority boundary.
What does the technology need to do? Where system integration is required, the co-design specifies the integration requirements. This is where the Seven Flows governance platform enters the picture — not as a product being sold, but as the infrastructure layer that makes governed boundary operation technically possible. Identity resolution across provider and insurer systems. Consent propagation that respects constitutional domain boundaries. Provenance verification for clinical data in transit. Clinical intent preservation through routing functions. Bilateral responsibility transfer confirmation. Outcome feedback loops.
What does success look like in twelve weeks? The co-design phase concludes with a lighthouse project specification: a defined scope, a defined boundary, measurable maturity targets, and a twelve-week implementation timeline.
How mature is your boundary governance? The Boundary Risk Score gives you a rapid, scored assessment across all seven flows.
Check Your ScoreStage 3: Lighthouse
The lighthouse project is not a proof of concept. It is a governed boundary operating in production at a single crossing point.
The concept is borrowed from infrastructure programmes where demonstrating capability at one site is the condition for scaling to others. The lighthouse boundary becomes the reference implementation — the evidence that governed cross-boundary operation is technically achievable, operationally sustainable, and commercially justified.
A typical lighthouse project takes a single material boundary — say, the pathway between an insurer’s digital triage platform and a private hospital’s outpatient service — and implements the governance controls required to reach Level 3 maturity on the critical flows. Identity is resolved across both systems. Clinical intent is structured and preserved through the routing function. Responsibility transfer is bilateral and confirmed. Consent is managed across the clinical-commercial constitutional boundary.
The lighthouse runs for twelve weeks. During that period, the boundary operates under the governance framework, data is collected on maturity performance, and the operational impact is measured: time from referral to treatment, clinical intent survival rate, responsibility transfer confirmation rate, consent compliance, and the reduction in administrative friction at the boundary.
At the end of the lighthouse period, two things exist that did not exist before. First, a governed boundary operating in production with measurable performance data. Second, the evidence base for the board business case.
The board business case
Private healthcare boards do not fund governance projects because they are important. They fund projects that demonstrate return. The lighthouse exists to convert a governance argument into a commercial one.
The business case draws on three evidence sources. The audit findings, which quantify the risk exposure at every material boundary. The lighthouse results, which demonstrate the operational impact at one boundary. And the remediation roadmap, which sequences the rollout from lighthouse to network.
For a private hospital group, the commercial case typically rests on four pillars. Regulatory risk reduction — the audit findings, linked to CQC Regulation 12, HSSIB investigation scope, and DCB 0129/0160 obligations, represent unpriced liabilities that the board now has evidence of. Insurer network positioning — governed boundaries are a differentiator in panel membership decisions, Provider Selection Regime compliance, and outcomes-based commissioning. Operational efficiency — the lighthouse data demonstrates reduction in administrative friction, pre-authorisation cycle time, and claims reconciliation effort at the governed boundary. Growth enablement — governed boundaries support new pathway products, IHO participation, and cross-boundary outcome attribution.
For an insurer, the case rests on Consumer Duty compliance (can you demonstrate good outcomes across your network pathways?), claims cost reduction (governed boundaries reduce disputes, rework, and information asymmetry), and network quality differentiation.
How technology deployment works
The governance platform is not sold as a technology product. It is deployed as the infrastructure layer that makes boundary governance technically operational.
The audit diagnoses the governance gaps. The co-design specifies the integration requirements. The lighthouse deploys the platform at a single boundary. The rollout extends it across the network.
Underlying cloud infrastructure — landing zones, networking, identity management, hosting — is delivered through qualified cloud migration partners. This is standard cloud engineering, and established partners with migration competency deliver it routinely. The governance layer sits on top: the clinical safety, consent, provenance, and responsibility transfer infrastructure that no migration partner can replicate, because it requires healthcare domain expertise, clinical safety framework compliance, and statutory traceability that cloud engineers do not carry.
For organisations considering cloud migration, the audit engagement aligns naturally with cloud programme funding. The assess phase offsets discovery costs. Migration credits reduce the infrastructure investment. The governance platform deploys on the cloud infrastructure the migration partner builds. The total programme cost — migration plus governance — is lower than either component purchased independently, because the audit de-risks the migration by mapping what must be governed before clinical workloads move.
What this means for the CSO
The Clinical Safety Officer’s world changes through this process, and the change is welcome. Before the audit, the CSO holds statutory responsibility for clinical safety within their organisation but has no methodology, no evidence framework, and no infrastructure for understanding or governing what happens at the boundaries.
After Stage 1, they have a boundary-specific risk assessment with statutory traceability — findings they can add directly to their hazard log. After Stage 2, they have a co-designed remediation plan with both sides of the boundary committed. After Stage 3, they have a governed boundary operating in production and an evidence base that demonstrates their organisation is actively managing cross-boundary clinical safety.
This is not additional burden. It is the first time the CSO has had the tools to discharge a responsibility they have always held but have never been able to evidence.
What this means for the medical director
The medical director gains visibility they have never had. Cross-boundary pathway performance becomes measurable: where clinical information degrades in transit, where intent is lost through routing functions, where responsibility gaps create unmonitored patients. The lighthouse data gives them evidence for clinical pathway improvement that internal audit has never been able to provide — because internal audit, by definition, stops at the boundary.
Scaling from lighthouse to network
The lighthouse boundary is one crossing point. A typical private hospital group has five to eight material boundaries. An insurer network may have dozens. The remediation roadmap sequences the rollout — and the sequencing is governed by the cascading dependency logic from the audit.
Boundaries sharing an Identity infrastructure failure are addressed together. Boundaries dependent on a consent architecture that spans the clinical-commercial boundary are grouped. The rollout is not boundary-by-boundary but dependency-by-dependency, which means each successive boundary deployment is faster and cheaper than the last, because the foundational governance controls deployed at the lighthouse serve multiple boundaries.
The final article in this series introduces the practitioner framework that underpins every stage of this engagement: the four disciplines that must be present for boundary governance to hold.
