A national-scale healthcare platform, built to run where the data has to stay
One platform running the clinical and operational workflow for hospitals across acute care, mental health, community services, care plans and pandemic response. Patient records, bed and ward management, referrals, appointments, care notes, document handling and a live view of how patients move through a hospital. Built as the engineering partner to a UK agency, deployed at two NHS trusts in England.
- 9 module groups
- 5 service areas
- 2 independent security layers
- 1 clinical source of truth
- 0 patient data leaving org infrastructure
What the platform does
Hospitals do not lack software. They have too much of it, and none of it talks to the rest. Records in one system, laboratory results in another, imaging elsewhere, billing elsewhere again. So no clinician sees the whole picture, and staff spend hours typing the same details into systems that could have asked each other.
This platform connects the journey end to end, then adds the operational layer a hospital runs on.
A member of staff searches for a person and everything about them is in one place: demographics and summary, allergies, alerts, vulnerability status, key care contacts, usual place of residence, recorded death where it applies, appointment timeline, care notes, clinical notes, documents, referrals and location.
Create and edit wards and beds, assign a bed, move a patient between beds, discharge, and manage virtual beds for periods when capacity has to exist somewhere other than a physical ward.
Waiting lists, frailty lists and any other grouping a service needs, with patients added, removed and moved between them.
Referrals raised between organisations and practitioners, and appointments managed in a calendar with daily, monthly and timeline views, with the organiser recording that the patient has agreed to the appointment.
Video calling runs from the patient's record rather than from a link pasted into a note. Covered in full below, because the decision behind it is not a small one.
Everything that arrives about a patient, from every direction, in whatever format the sending system produced, readable and searchable in the place the clinician is already looking.
Every step above writes to one patient history, and nowhere else.
- Delivered for
- POSM, a UK agency, as their engineering partner
- Deployed at
- Two NHS trusts in England, within our delivery scope
- Sector
- Healthcare, hospital management
- Product
- Multi-organisation clinical and operational platform
- Our scope
- Platform architecture, middleware over the clinical data source, clinical and operational modules, security architecture, deployment model
One continuous workflow, entered once
The same details used to be typed into four systems by three people. The journey is the product; the modules are how it is delivered.
The one fact that shaped everything
In healthcare, the person the data is about is not the person using the software.
This platform has no patient-facing application. Its users are clinicians, ward staff, administrators and operations leads. A patient does not choose the systems their hospital runs, does not agree the integrations, and in most cases never sees the platform at all. They are simply the reason it exists, and the person who carries the consequence when it goes wrong.
A doctor treating somebody without their history is making decisions with information withheld by the shape of the software estate. That is avoidable clinical risk.
Making records flow freely between organisations solves the first requirement by abandoning the second, which is how well-meaning healthcare data projects end up in the news.
It is a regulatory failure and a human one at the same time. Everything below follows from those facts.
The four decisions that mattered
If you read nothing else on this page, read this.
The platform reads from the health service's own clinical API rather than holding a second copy of it.
A live map of how frail patients move through it, including the movements nobody counts and the one route nobody wants to.
What a person is allowed to see, and what can be reached at all, are separate controls. Neither assumes the other held.
Not a reduced on-premises edition maintained alongside a real one. The same build, deployed where the data has to stay.
Do not own the record
The clinical data already had a home: a standards-based healthcare API, owned and operated by the health service, holding patients, encounters, observations and medications. The obvious build is to pull all of that into the platform's own database. It is faster to develop against, easier to query, and it is the wrong answer for two reasons that both matter.
Duplicating the clinical record into the platform's own store doubles the attack surface, adds a synchronisation problem, and creates two versions of the truth about a person.
A clinical summary is many separate resources. Fetching them one at a time from the browser is slow enough to change how the software gets used, which in a hospital means it changes care.
What we built instead: a middleware layer in Node, sitting between the application and the clinical API. It shapes clinical data into what a particular screen actually needs, in one call rather than eleven, and carries the platform's own working data: users, roles, teams, trusts, service groups, patient lists, ward and bed assignments, appointments and configuration. Every module is written once, against the internal shape the middleware produces. None of them talks to the clinical API directly.
One version of the truth There is no synchronisation gap in which a clinician reads a stale allergy. There is only one record.
The interface is fast enough to be used Software that makes a busy clinician wait is software that gets worked around. That is a clinical outcome, not a performance note.
A change to the clinical API is contained It reaches one layer rather than every module that happens to read patient data.
Data minimisation for free The platform holds as little clinical data as the job allows. It fell out of declining to own something already owned properly somewhere else.
Make the hospital visible to itself
Most of this platform is about one patient at a time. One module is about all of them at once. Frail patients move through a hospital along routes everybody working there could describe and nobody could measure. Where those routes slow down is the difference between a hospital that is coping and one that is not, and it is normally discovered from returns compiled weeks afterwards.
A live map of the pathway, built on real-time data: not just where patients are, but how many moved along each route between each part of the hospital. One route counted separately from the rest: patients who died while waiting for care, attributed to delay.
A count is a question. Once a number sits on a route, somebody has to explain the route, and bottlenecks stop being anecdotes from a ward round.
A dashboard shows what happened. A flow map shows where people are stuck now. The difference is whether an operations lead is reading history or something they can still act on.
The last route is the reason the module exists A hospital that can count delay-attributable deaths can argue for the resource to reduce them. One that cannot is describing a feeling.
Two independent security layers
Patient data is the most consequential category of personal data most software will ever hold: diagnoses, medications, mental health history, vulnerability status, and the fact of an attendance, which is sometimes as sensitive as anything recorded during it. A single well-implemented control is still a single point of failure.
And access between organisations is governed rather than assumed.
Each organisation's data is isolated, what a role may see is enforced per interface component, and every access is recorded with an actor and a time in a log the application cannot rewrite. The platform does not decide who ought to be allowed to look. It makes what was looked at a matter of record rather than recollection.
Two of the five trust services criteria carry the weight here.
The control set was designed against the criteria rather than mapped to them afterwards, so an organisation preparing for an attestation is documenting controls that already exist rather than retrofitting them under time pressure. That is a statement about how the platform was built. It is not a claim to hold an attestation, and where an organisation needs one, the work is theirs to complete with an auditor.
Built to run inside the organisation's own walls
For a great many healthcare organisations, patient data leaving their own infrastructure is not a preference to be negotiated. It is the end of the conversation. The usual response is a cut-down on-premises edition maintained alongside the real one. That is two products with one name, and the second is always behind: a security fix reaches the hosted platform in a week and the on-premises deployment in a quarter, so the organisations with the strictest requirements end up running the oldest software.
One containerised build, deployed inside the organisation's own infrastructure, from the same artefact and the same release as anything else. Not a stripped-down edition and not a separate codebase. The environment is a deployment target decided at install rather than a fork decided at design, and schema changes are versioned and applied as part of the release. And nothing calls out: a platform whose video, documents or search reach a hosted service is not running inside the organisation's walls, whatever its deployment diagram says. Every component described on this page runs inside the same boundary.
Patient data does not leave the organisation Not as a configuration option, but as a property of how the platform is built.
The strictest organisations run current software No second edition means no second release cadence, so a security fix reaches every deployment on the same terms.
Residency stops being a disqualification A requirement discovered halfway through a procurement is answered rather than conceded.
One codebase to maintain Which is the reason the first three are true rather than aspirational. Schema changes are versioned and applied as part of the release, so the on-premises path is repeatable rather than bespoke per site.
Documents, and finding what is in them
A patient record accumulates documents from every direction, in whatever format the sending system produced. Referral letters, discharge summaries, assessments, scanned correspondence, reports running to ten or fifteen pages.
A clinician who has to download a file, find an application that opens it, and then remember where they were has been given a task rather than a tool. And a document store searchable by filename is a filing cabinet with a search box on it, because nobody names a file after the sentence inside it that mattered.
Running inside the same boundary as everything else, with a folder structure built to the shape of the programme rather than to whatever the default was.
Enabled deliberately, so a search reaches the text inside a fifteen page report rather than its title. A clinician looking for a phrase they half remember from an assessment finds the assessment.
Documents open inside the application whatever type they are, in the place the clinician is already looking.
The record is readable without leaving it. Search over content rather than filenames is the difference between a document store and something clinicians actually use. And because the document layer is self-hosted alongside the rest, the promise the deployment model makes holds for documents too.
The constraints we designed around
Platforms operating across organisations that did not choose each other's software meet constraints. The work is knowing which to design for up front, which to address when they become real, and which are somebody else's decision to be routed around cleanly.
Any mainstream meeting product would have worked on the day. It also would have meant a clinical conversation about a named patient travelling through a third party's infrastructure, retained under their terms, outside every control described on the rest of this page. For a hospital, a consultation is part of the clinical record. It would also have quietly broken the promise made by the deployment model: an on-premises platform whose video feature calls out to a hosted service is not an on-premises platform.
We self-hosted the video stack instead. Jitsi provides the conferencing and Jibri handles session recording, both running inside the same deployment as everything else. A clinician starts a call from the patient's record. Where a session is recorded, the recording sits inside the same boundary, under the same role-based access and the same audit trail as the rest of the record. Not a file in somebody else's account with a sharing link attached to it.
Patient conversations stay inside the organisation's infrastructure, so the guarantee the deployment model makes about data at rest holds for data in motion too. An on-premises deployment is genuinely on-premises rather than on-premises with an exception nobody mentions. And there is no per-seat licence sitting on a clinical feature.
Every organisation wants different fields, forms, permissions, templates and terminology. Meeting that with code produces a branch per customer.
We made the differences configuration: dropdown values, email templates, notification settings, theme, and access per interface component per role.
A new organisation is configured rather than built for, so onboarding is a task rather than a project. A change requested on a Tuesday does not wait for a release train, and the codebase does not become a museum of past customers.
Clinical software is used by people who are tired, interrupted, and holding something more important in their head than your navigation.
We designed the common path short and the rare path reachable, letting the frequency of a task determine how many steps it gets.
Capability that goes unused because nobody can find it is capability that was not delivered.
A hospital does not adopt software because it is better. It adopts software when the people using it are supported through the change, and clinical staff have been promised improvement before.
We treated training, documentation and support as part of delivery rather than a phase after it.
The platform is used rather than installed, which is the only version of delivery that counts.
The impact, depending on your job
If you run the business
Declining to own the record is a commercial position, not just a security one. A platform that does not hold a duplicate national clinical record is a materially easier thing to get through information governance, and information governance is where healthcare deals go to stall.
Running inside the organisation's walls decides how much of the market you can sell to. Organisations with strict residency requirements are not a niche in healthcare. Being able to say yes to them is a position rather than an infrastructure detail.
The access model answers the question every information governance lead asks, because who saw what is a record rather than an assurance.
If you run engineering
The data position is the part worth your attention. A middleware over the clinical source rather than a copy of it, which resolves the usual trade between a fast product on duplicated data and a safe product too slow to be adopted.
Then the security model: two independent layers rather than one strong one, and access control at the level of the individual interface component rather than the page.
And the on-premise constraint, which is stricter than it sounds. Nothing calls out, including video, documents and search, which is why each of those is self-hosted rather than integrated.
If you run a delivery team
Organisational differences are configuration rather than branches. Modules are written against one internal shape. Deployment is an install-time decision rather than a second codebase, and schema changes are versioned rather than applied by hand at each site.
That is what keeps a team shipping across a growing estate rather than maintaining a variant per customer.
If you own the numbers
The cost of onboarding the next organisation is largely configuration, so it does not rise with the number already connected.
One codebase serves the estate, so running inside an organisation's own infrastructure does not carry a permanent second maintenance cost.
Preparing for attestation is documentation rather than remediation, which for an organisation that needs a report is measured in quarters and in consultant fees.
Administrative time returned to clinical staff is the largest recurring saving available in a hospital, because it is staff cost rather than software cost.
Talk to the client, not just to us
Everything on this page is our account of our own work. If you are seriously evaluating us, we will arrange a reference call with a client who has been through a build like this one, and you can ask them the questions you would rather not ask us.
Technologies we built with
We name the layers rather than the suppliers on the patient data path, because a supplier map is our client's exposure rather than our credential. Where a component is named, it is because it runs inside the deployment rather than receiving patient data elsewhere. Full detail available under NDA.
More case studies
View all case studiesBuilding healthcare software that has to be right, and provable?
Tell us what you're building, and we'll tell you honestly how we'd approach it.