Stripe processes $1 trillion annually across millions of businesses, dozens of payment methods, and hundreds of banking partners. At any given moment, money is in transit between systems that don’t share a database, don’t share a schema, and often don’t share a timezone. Stripe’s engineering team built a system called Ledger to track every penny of that movement with 99.9999% explainability.
The NHS moves something more valuable than money between organisations every day: clinical responsibility for patients. And it does so with approximately 0% explainability.
When a GP refers a patient to a hospital, there is no system that tracks whether responsibility for that patient has actually been accepted by anyone on the other side. The referral goes into a queue. Maybe someone picks it up in a day. Maybe in three weeks. Maybe never. The GP assumes the hospital has it. The hospital may not know it exists. The patient is in a gap between organisations, and nobody can see them there.
This is not a technology problem in the way most health tech companies mean it. It’s not a missing app, a bad user interface, or insufficient interoperability. It’s a missing accounting primitive. The NHS has no equivalent of double-entry bookkeeping for clinical responsibility.
We think it should.
Double-Entry Bookkeeping for NHS Clinical Responsibility
In banking, when money moves from one account to another, two things happen simultaneously: the sending account is debited and the receiving account is credited. These entries must balance. If they don’t, the discrepancy is immediately visible. This is double-entry bookkeeping, invented in the 15th century, and it remains the foundation of every financial system on earth.
The “clearing” period –the window between when money leaves one account and arrives in another –is tracked obsessively. Banks know exactly how much money is in transit, where it is, and how long it’s been there. A payment that has been “in clearing” for longer than expected triggers automatic investigation.
The same principle applies to clinical responsibility. When a GP refers a patient’s cardiac care to a hospital, two things should happen: the GP’s responsibility account should show “released” and the hospital’s should show “accepted.” If only one side of that transaction exists –the GP released but nobody accepted –the imbalance should be visible immediately.
We call that imbalance a “clinical clearing balance.” A nonzero clearing balance means a patient is between responsible clinicians. The longer the clearing balance persists, the greater the risk. A cardiac referral in clearing for two hours is normal. One in clearing for five days is a patient safety incident in progress.
This is a clean analogy, and it gets us most of the way there. But healthcare has structural properties that money doesn’t, and papering over those differences would be dishonest engineering. So let’s address them directly.
Clinical Responsibility Is Not Zero-Sum
Money is fungible and zero-sum. A pound can only be in one account at a time. When it moves, the sender has less and the receiver has more. The total is always conserved.
Clinical responsibility is neither fungible nor zero-sum. A patient routinely has multiple concurrent responsible clinicians: a GP holding overall care coordination, a cardiologist holding cardiac domain responsibility, a respiratory consultant holding respiratory, a district nurse holding wound care. The GP didn’t release anything when the cardiologist accepted –they both hold simultaneously.
This means the unit of account can’t be “responsibility for patient.” It must be “responsibility for patient, in a specific clinical domain, at a specific scope.” Each of those is a separate ledger entry with its own lifecycle. The GP referring cardiac care creates a new entry in the cardiac domain. It doesn’t debit the GP’s overall coordination entry. Those are different accounts.
The dangerous moment isn’t when responsibility is shared –shared is expected and healthy. The dangerous moment is when there’s a domain with no holder. The cardiologist discharges the patient back to GP care, but the discharge letter hasn’t been received. For that window, nobody is provably holding cardiac responsibility. That’s a nonzero clearing balance, but it’s domain-specific, not patient-wide.
This is a more complex model than financial clearing, but it’s also a more honest one. Any system that tracks clinical responsibility as a simple one-to-one handoff is modelling a world that doesn’t exist.
Rejection Is Good Medicine
In banking, a rejected transfer is an anomaly –usually a wrong account number or a fraud flag. In clinical practice, rejection is a legitimate and often correct clinical decision. The cardiologist receives a referral, reviews it, and determines this is actually a respiratory problem. They reject. That’s good medicine.
But what happens to the clearing balance? The GP gets the patient back, the clearing metric shows green. Except the patient still needs help –they’ve just bounced. The metric can’t distinguish between “rejected and re-routed to the correct specialist” and “rejected and sitting back with a GP who doesn’t know what to do next.”
A naive implementation would treat rejection as resolution. A correct implementation starts a new clock: when a transfer is rejected, the sender’s clearing timer restarts. How long until they re-refer, find an alternative, or explicitly confirm they’re retaining the domain? A rejection that resolves the clearing balance without resolving the patient’s clinical need is a false green. Our systems need to be honest about that.
The Receipt-Versus-Acceptance Gap in NHS Referrals
When you transfer money between banks, receipt is acceptance. The receiving bank’s system processes the incoming transfer automatically. There’s no human in the loop.
Clinical referrals have a massive gap between “the referral arrived in the hospital’s system” and “a named clinician has reviewed it and accepted responsibility.” An e-RS referral can sit in a hospital queue for weeks. It’s been “received” by the system. Nobody has accepted responsibility.
This creates a hard design question: does the clearing clock stop when the receiving system acknowledges the message, or when a human accepts responsibility?
If it stops at system receipt, you get fast clearing times that are clinically meaningless. The referral cleared the metric, but the patient is still in a queue. If it stops at human acceptance, you get honest but politically uncomfortable clearing times that expose real delays.
The honest answer is human acceptance. The whole point of tracking responsibility is knowing that a person has taken ownership, not that an envelope arrived in a mailbox. But this means clinical clearing times will be orders of magnitude longer than financial ones, and the system must be designed with that reality, not against it.
Shared Responsibility Hazards in Integrated Care Transitions
The domain-scoped model introduces hazards that don’t exist in banking at all:
Assumption gaps. The cardiologist assumes the respiratory team is managing the medication interaction between their respective treatments. The respiratory team assumes cardiology is managing it. Neither has it in their explicit scope. Both domains show “active” with confirmed holders. No clearing balance is nonzero. And yet there’s a gap –a clinical responsibility that both sides think the other holds.
Detecting this requires more than tracking who holds what. It requires tracking where active domains overlap and whether there’s an explicit agreement about who manages the intersection. The absence of that agreement is itself a signal.
Cascade discharge failures. A hospital discharges a patient. That’s not one transaction –it’s potentially five or six domain-specific responsibility transfers across material boundaries all happening at once. Cardiac, respiratory, wound care, medication management, overall coordination, mental health. Each needs its own acknowledgement. If the GP acknowledges overall coordination but nobody picks up wound care, the wound care domain is in clearing. Today, that’s invisible. With domain-scoped clearing, it’s a query.
Orphaned domains. A consultant retires, a clinic restructures. The diabetes domain for fifty patients quietly disappears. Nobody transfers it. Nobody closes it. It just stops being actively managed. A ledger that tracks responsibility as explicit entries will notice when an entry goes stale without being formally closed or transferred.
The Gaming Problem in Clinical Metrics
Financial clearing metrics are internal risk management tools. The bank benefits from honest data. Clinical clearing metrics expose organisational performance. A Trust with consistently long clearing times is visibly slow at accepting referrals.
This creates predictable gaming behaviours:
Auto-accept without review. The easiest way to improve clearing times is to auto-accept every referral on receipt, then deal with it later. The metric looks good. The patient has no named clinician.
Scope narrowing. Accept only the narrow scope you can deliver quickly, reject the rest. The metric shows fast clearing on what you accepted. The rejected portions bounce back and become someone else’s problem.
Threshold lobbying. Push for longer acceptable clearing durations so that your actual processing time falls within “normal.”
Any system that measures clinical responsibility transfer performance will be gamed the moment it’s used for accountability. This isn’t cynicism –it’s Goodhart’s Law applied to clinical operations. The design must make gaming visible, not just difficult. Track time-to-accept distributions, flag statistical anomalies, separate system receipt from human acceptance, and never present clearing rate alone as a quality indicator.
The Cold Start Problem
Stripe’s clearing metric works because 100% of Stripe’s money movements flow through the Ledger. On day one of a clinical responsibility tracking system in an ICB, maybe 5% of transfers are being tracked –one pathway, one set of organisations.
A clearing rate of 99.5% on 5% of transfers tells you about the pathway you’ve instrumented. It tells you nothing about the other 95%. Worse, it can create false confidence.
This means a clinical clearing system must track its own coverage alongside its clearing rate. “What percentage of known responsibility transfer pathways in this region are flowing through the system?” is as important a question as “What’s the clearing rate?” A clearing rate without a coverage denominator is a vanity metric.
The Metric That Doesn’t Exist Yet
No one in the NHS can currently answer a simple question: “How many patients in my region are currently between responsible clinicians?”
Not approximately. Not by running a retrospective audit. Not by waiting for a complaint. Right now, in real time, how many patients are in clearing?
The individual components to answer this question are not particularly exotic. Event-driven architectures, domain-scoped data models, materialised views, threshold-based alerting –these are standard patterns in any scale engineering organisation. Stripe, Uber, Netflix, and dozens of others use them daily.
What doesn’t exist is the application of these patterns to clinical responsibility. The financial services industry solved this problem for money decades ago. Healthcare hasn’t solved it for patients.
What We’re Building
At Inference Clinical, we’re building infrastructure for inter-organisation responsibility transfer in healthcare. Not an app. Not a dashboard. Not an AI tool. Infrastructure –the kind that embeds governance, safety, and accountability into the runtime rather than bolting it on as paperwork.
We believe that clinical responsibility transfer should be tracked with the same rigour that banks apply to money movement. We believe that the structural differences between healthcare and banking –shared responsibility, healthy rejection, the receipt-versus-acceptance gap, the gaming problem –are engineering challenges to be solved honestly, not analogies to be ignored.
We believe that the question “is anyone falling through the gaps?” should be answerable from a query, not from an inquest.
And we believe that the engineering patterns to build this already exist. They just haven’t been applied here yet.
