Early days. Honest ask.

A side project that grew — and a genuine request for feedback rather than a fanfare.

Back in May I messed around with Claude and built “open community” — the start of a community-based system serving GPs and pharmacy. I’ve taken it a fair bit further in my evenings and weekends since.

It’s now called commvita™: one system covering a stable clinical community record — primary care, dentistry, ophthalmology, physio, mental health, social care — plus system flow, governance and assurance.

Why it’s built the way it is. I’ve spent my career on both sides of this — executive and non-executive roles in digital health, buying and running these systems, and selling them. But it’s the operator’s seat that teaches you the most, and what it teaches you is how hard it’s to stitch hundreds of systems together in a health system and keep them stitched. Unless you’ve sat in that chair, you don’t really know what the issues are. So I started from constraints rather than features. Eight of them, and the rest follows:

1. Change the economics, or don’t bother. Real-time insight and high-quality data, at around 80% off the total cost of owning today’s systems — siloed, hard to integrate, and never built for real-time working. That’s the whole point of it. If it doesn’t do that, none of the rest matter.
2. It has to be open. No data lock-in. The data is yours and it must be easy to get out — openEHR as the clinical data repository and OMOP for research are the two vital constituents.
3. One product, so there’s nothing to integrate. That’s how you get the first one. The expense was never the software. It was the joins.
4. Configuration over customisation. One system, one codebase — sixteen jurisdictions configured from it so far, with no forks and no bespoke branches.
5. Automation and scale, designed in. You shouldn’t be waiting weeks or months for a bug fix or a deployment.
6. No partner tax. We integrate with third parties because the combination genuinely adds value — not because there’s a toll to collect on the way through.
7. Tools to migrate on — and off. Both directions, deliberately. A way in with no way out is a trap, however good the product is.
8. No long-term contracts, unless you want one. We want you to stay because you want to, and not because you can’t get out.

One system also means the whole wrap-around lives in the same place: a patient portal with research opt-in and opt-out choices that are actually enforced — not stored and ignored — a research platform with OMOP exports for study cohorts, financial recovery plans, quality impact assessments, and the golden thread from an incident on the ward to the board’s assurance framework. Pretty much whatever is needed to govern and assure a health system. This is the shape of it:

And it stopped being a solo project some time ago. I’m building this with two co-founders.

Professor Marc Farr — co-founder and Chief Data & Analytics Officer. Marc keeps pulling it towards population health and inequality; his test for every screen is whether it produces actionable insight, not another dashboard.

Hassan Chaudhury — co-founder and Chief Commercial Officer. Hassan keeps pulling it towards the commercial question: not “is it clever” but “what does it take out of the cost base”.

And behind the scenes we have a couple of shy engineering geniuses who have built it all out in Azure — ready to demo, and ready to deploy. A lot of what follows is shaped by all of them.

What you’d actually buy first

Nobody replaces their EPR just because a better one exists. I’ve sat through that decision, and the software is never what stops it. It’s everything else: moving the data across, retraining staff, the clinical risk, all the integrations, the assurance work, the procurement, and a contract you can’t get out of. That’s too much to ask, and I’m not asking it.

So you’d start by buying one edition. If you’re a board, Governance & Assurance covers incidents, risk, board assurance, policy, audit and training. If you run operations, Commvita Flow covers flow, waiting lists and discharge — the same jobs the NHS Federated Data Platform products do, but on open standards and hosted by you. Both take their data from whatever you already run.

The whole platform is there if you want it later. The way in is small, cheap and easy to undo. And if it stays a governance product for you forever, that’s a perfectly good outcome.

Why one system — the two bikes

So why build one system at all? Because where it ends up matters, even if you get there in stages. What follows is the engineering argument for the direction. It isn’t what I’m asking you to buy on day one.

Same road, same effort. On the first bike every system is another gear, and every join between gears loses energy. On the second there’s one platform and one join — the hospital EPR. If you’re an engineer, which do you design: interoperability and friction, or a single frictionless system that delivers real-time information? (It moves — give it a moment.)

I’ve always thought health systems are a bit like factories. Nobody building a factory would put a different system, by design, at the start of every production line — you’d make sure there was one. Health has ended up with the opposite: a different system at the start of every pathway, and people paid to carry information between them.

Because it’s one system, the information is real time. Left shift, outcomes, flow, incident through to board assurance, quality impact assessments, financial recovery plans, training, waiting lists, safer staffing, rostering — all reading the same live record, not month-end extracts stitched together by hand.

Measured in real time, not assembled in arrears

Because it’s one system, things that normally take a programme office weeks to pull together are just… there: system flow, left shift, outcomes and digital maturity, measured as the work happens. This is the part Marc has shaped most — his standard is that population health has to end in something you can act on: a named cohort, a gap closing, an inequality measured instead of described. These are real screenshots from the running system:

Captured from the running system on a seeded demonstration estate — the DEMO DATA and seeded banners in the screenshots are the platform saying so itself.

It goes into the specialist areas too. Genomics is a good test, because it’s the hardest thing to fake: commvita holds the pedigree as data, not a drawing — sex, affection, deceased, tested and result are stored fields per family member.

The money

This is where Hassan has pushed hardest — he saw the commercial opportunity before I’d finished describing the product, and he has kept the question honest ever since: where does the money actually go today, and how much of it does one system remove? We’ve done the modelling, and we’re confident an approach like this takes out around 80% of total cost of ownership. Not just the licences — one system is considerably cheaper than many — but the real money: the cost of feeding and watering a dozen systems, and of using people as the glue between them. The integration teams holding the seams together, the analysts re-keying between systems, the governance staff assembling packs by hand — that’s the spend a single system removes.

Modelled against planning scenarios for a two-million-population system; the model and its assumptions are written down, evidence-graded, and shareable on request.

How it’s built

What that buys you is dull and important: releases that are safe, controlled and traceable. Every change is proven against the whole test suite before it ships, the environment pulls its own updates instead of an engineer pushing them, and there’s a trail from a reported problem to the deployed fix. Nobody logs into a server to release. I’d expect that of any serious software company, so it isn’t a selling point — but on a clinical system it’s the bit you’d want to audit, so it’s here.

Under the hood it’s deliberately boring: containers on Kubernetes, running today on Azure and Docker, with high availability on by default — replicated services, disruption budgets, spread across nodes. The pipeline runs the whole test suite plus nineteen build gates, images are built, security-scanned and published, and the cluster pulls its own updates via GitOps.

It’s designed for cloud portability — standard containers, nothing tied to one cloud. I say “designed for” on purpose. We haven’t stood it up on AWS or Google yet, and the three clouds behave differently on networking, identity, databases and monitoring. I’m not going to claim portability I haven’t tested.

The same pipeline runs support. Every screen has a feedback icon; you file a bug and it lands in a triage queue inside the platform. Everything after that — diagnose it, write the fix, test, integrate, deploy — already runs without anyone touching a server. We’ve deliberately left the last step open: on a clinical system a human looking at the change is a control, not a bottleneck. But it’s governance that would close it now. The engineering is already there.

And the sixteen jurisdictions are configuration, not customisation. There are no forks and no bespoke branches: one codebase, and a versioned, source-cited jurisdiction profile that carries each country’s identifiers, terminology, regulators and statutory clocks as data. A hardcoded jurisdiction assumption fails the build. That’s the difference between a product and a services business wearing a product badge: adding a country means configuring it and getting the sign-offs. Nobody has to stand up a project.

What this would cost to build the traditional way

The codebase measures about 670,000 lines of application source (124,000 in the API, 548,000 in the web application) plus 2,200 automated test functions. Pick your own figure for what a conventional team actually finishes per developer per day once design, review, testing and rework are counted — the commonly quoted range is 10 to 50 lines. Even at the generous end that’s roughly 13,000 developer-days: a team of twenty for about three years. But nobody who has watched a large health-IT programme believes the generous end — clinical safety, information governance and integration pull real delivery towards the cautious end, several times that. Put a typical blended day rate against it and the build labour alone comes to a likely minimum of £35m. Staggering — and that’s before hosting, programme management, and the integration programme a many-vendor estate forces on you. This was built in evenings and weekends since May, by one person working with AI. That gap is the story.

Illustrative arithmetic, not a quotation: the line counts are measured from the repository; the productivity range (10–50 finished lines per developer-day) and the £500 blended day rate are assumptions — substitute your own and the arithmetic still sits on the page.

Jack of all trades, master of none?

A reasonable worry with something this broad. The answer isn’t a scoreboard — anyone claiming to beat hundreds of competitors deserves the scepticism they get. What we built instead is a check on ourselves: as each feature is built it’s benchmarked against the named incumbents in its space, and the benchmark ships inside the software. Anyone using the platform can open it, and the build pipeline checks every rating against the real modules so the claims can’t quietly drift into marketing. Of 622 modules registered — 565 live, 43 built and waiting on credentials, 14 still stubs — 434 capabilities are benchmarked: 254 ahead of every named competitor, 148 on par and behind nowhere, and 32 behind at least one. You need the split, or you can’t tell whether the rest are ahead or just level. But the 32 is the number I’d look at.

Why 434 and not 622. The two count different things, and the build fails if either drifts from the registry. The registry counts capabilities. The benchmark counts screens you could put a competitor’s next to. Eleven capabilities are cross-cutting and have no screen of their own — brute-force protection, per-record scoping, the export spine — so there’s nothing to compare. A further 198 are older register entries pointing at a route another entry already holds, and those get rated once instead of twice. That leaves 413 routes. Twenty-one of them carry more than one distinct capability and each is rated on its own, which is how 413 routes become 434 ratings. Nothing routed is missing from the benchmark, and nothing in the benchmark is missing from the registry.

Where I’d stake the claim is narrower and more useful: four things where the breadth earns its keep — the flow and OPEL command centre, the incident-to-board golden thread, real-time outcome and inequality measurement, and registration and access checked the same way across every setting. Press us on those.

The 32 get told straight, because a benchmark that only says nice things is marketing. Each one carries its reason in the catalogue. Between them they carry 51 behind ratings, because a module can be behind more than one competitor at once. They fall into seven kinds:

In more detail:

1. Depth an incumbent has earned — 17. Somebody has been doing one thing for thirty years and does it better. An identity integration more battle-tested at hospital scale than ours; a dedicated privacy-engineering product where we have a policy register and not much else; three vendors with a working length-of-stay prediction model where we have none. That last one is worth sitting with: an earlier version of the catalogue had us ahead on prediction, on the strength of shipping no model at all. We corrected it to behind.
2. Not built yet — 16. Plain functional gaps, and I concede them. A finance system can prove a saving landed in the accounts and we can’t — we record the method and the evidence the finance business partner used instead. Theatre lists, national clinical audit submissions and the link into the national record-locator service sit here too.
3. Built, not deployed or certified — 8. Built to the published standards, and rated against products somebody is running today. A seeded screen loses to a deployed one and it should. This is the group that closes fastest, because what moves it’s a deployment and an assessment rather than a build.
4. Our own partners — 4. Not competitors; we partner with them. Rated behind anyway, because pretending a supplier you work alongside is a rival you beat would make the whole catalogue worthless.
5. Built, but not connected — 2. The code is there and nothing live is on the other end. Sharing records between organisations runs over national exchange networks, and joining one means being admitted as a member and issued the credentials that let you send. We haven’t joined any yet, so the software says nothing was sent instead of showing a success it can’t back up.
6. Waiting on somebody else’s licence — 2. Content we won’t ship unverified. There’s no drug-gene library in the product, because none has been read from source, so a deployment licenses its own and the platform carries the governance around it. Typing a dose from memory and printing it next to a patient’s name is the one mistake I am not prepared to make.
7. Deliberately not competing — 2. A national platform commvita feeds instead of replaces, and one more where being behind is the correct answer. Behind by design, and it stays that way.

The ratings move as things get measured, and they’ve moved down as well as up — three fewer ahead and seven more behind since the last count. That’s the assurance behind the breadth: software that stands feature-for-feature against the incumbents, and tells you inside the product exactly where it doesn’t yet.

Assurance of commvita itself

There’s a lot on this page about the governance inside the platform and almost nothing about the assurance of it. If I’m asking you to run critical things on my software, that’s the wrong way round. So here’s the list, both halves of it.

I’d rather hand you the work-list than a page of badges. The platform’s own registers are written the same way. That’s the only reason to trust this one.

Supplier risk — and how you leave

Here’s the obvious challenge to all of this: haven’t I just swapped a dozen suppliers for total dependency on one? And underneath it the harder one — what happens if I run out of money, or one of the engineers walks?

What I can show you is that your data comes out easily. Every record comes out over FHIR R4, the NHS standard for moving clinical data, including a bulk export of the lot. Research extracts come out as OMOP, the open model research databases already use, in ordinary spreadsheet or data-file formats. Any successor system can read them. It isn’t a dump that needs me to interpret it for you.

And leaving isn’t an afterthought here. We ship a module to help an organisation leave somebody else’s platform safely, because I think you should always have a way out of anything you depend on. It would be hypocritical to build ourselves as the exception. That comes from having sat on the buying side and watched what happens when there isn’t a way out, not from someone whose only interest is shipping you product.

There’s not much to lose either: £1 an instance to start, running on your own kit, and the partner pieces can be swapped for someone else’s. You keep what you already run instead of replacing it.

You don’t have to take it all at once

To finish where this started: Governance & Assurance or Commvita Flow stand on their own, and the Population Platform adds the clinical record and population health if and when you want it. Each comes with a full set of data connectors, so the systems you already run feed it from day one.

Whichever you start with, the plumbing comes with it. Digital consent and sign-off run through one e-signature service, so a quality impact assessment is approved the same way a genomic consent is granted. And a full communications CRM sits behind the clinical record, which is what makes WhatsApp, Teams, SMS and telephony one thing to operate rather than four to join up.

Third parties and integration

commvita isn’t an AI company — although it was built by AI. So we took a deliberate decision about integrations: we only integrate with parties doing something genuinely specialist — capabilities that either require separate regulation, or deep expertise of their own. And we aren’t going to tax that relationship. These are integrations for mutual benefit, with the health system as the primary beneficiary.

It also means the list is short on purpose. A great deal of what other suppliers sell as an add-on is simply part of the core product here — the communications CRM and its channels, e-signature and digital approvals, the patient portal, OMOP research exports, board and risk assurance. You aren’t buying a base licence and then buying back the things that make it usable.

That’s why we have chosen three launch partners. Spryt, for the amazing work they’re doing in pathway optimisation. Rapid Health, for the groundbreaking way they’re using AI to triage at a system level. And VUIT, which helps unlock the trickiest questions around health inequalities and the interventions that actually move them. We don’t expect that list to be exhaustive — but for now, it’s enough to show intent.

The next milestone isn’t another hundred modules

Being honest about where this is: the hard part left isn’t building more. It’s one live deployment that proves implementation, safety, adoption and the economics. That would be worth more than everything else on this page put together. A platform with no customer is a demonstration, however much of it works.

So if you run a health system and fancy being the first — small, bounded, Governance & Assurance or Flow first, nothing clinical replaced on day one — that’s the conversation I most want to have.

This is the three of us launching it. Marc keeps it honest on outcomes and inequality, Hassan keeps it honest on money, and I keep building in the evenings. Early days — honestly, what do you think?

See the whole thing at commvita.com.