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. We built it 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.
Search for a person and everything is in one place: demographics, allergies, alerts, vulnerability status, care contacts, 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.
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.
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.
A patient does not choose the systems their hospital runs. They do not agree the integrations. In most cases they never see 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.
Requested, approved, scoped, time limited, and recorded on both sides.
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 edition. A deployment target decided at install time.
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.
Access is a grant from the patient
A patient is seen at a clinic that does not hold their history. This happens constantly, and there are two usual answers. The first: the record is unavailable, which is safe and a continuity of care problem. The second: the record is shared on trust between organisations, which is clinically convenient and a privacy problem. Most systems pick one.
Neither. Access became a grant that the patient issues.
A named clinician requests access in the application, rather than through a call to another organisation's records team.
A prompt on their own device. Approve or decline. Nobody decides on their behalf, and a decline is a valid outcome.
The grant covers only the history asked for. It expires on its own and can be withdrawn before it lapses.
Who requested, who approved, what was seen and when are matters of record rather than recollection.
Continuity of care without uncontrolled sharing. The clinician gets what they need to treat somebody safely, and the record does not become a permanent copy in a second organisation.
The patient keeps the answer to who has seen their history: not as a policy commitment or a subject access request, but as something they can see and act on.
Consent is specific to a request, a scope and a period. Access review is a query rather than an investigation.
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.
The control set was designed against the SOC 2 Trust Services Criteria rather than assembled and mapped afterwards. Logical access, change management, monitoring and evidence of enforcement were treated as design inputs. An organisation preparing for attestation is documenting controls that already exist rather than retrofitting them. That is a statement about how the platform was built, not a claim to hold an attestation.
One build, two deployment shapes
For some healthcare organisations, patient data leaving their own infrastructure is not a preference to be negotiated. It is the end of the conversation, and a cloud-only platform is disqualified before the first meeting. 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.
The strictest organisations run current software No second edition means no second release cadence, so a security fix reaches an on-premises deployment on the same terms as a hosted one.
Procurement stops being a disqualification A residency requirement discovered halfway through an evaluation is answered rather than conceded.
One codebase to maintain Which is the reason the first two 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.
Making 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.
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.
A patient record accumulates documents from every direction in whatever format the sending system produced.
Documents are viewed inside the application whatever type they are, managed through a dedicated document layer rather than the application database, and searchable by date, author, filename and content.
The record is readable where the clinician is already looking. And search over content rather than filenames is the difference between a document store and a filing cabinet with a search box on it.
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.
The deployment model 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.
Patient-controlled consent answers the question every information governance lead asks, in a way that does not require them to trust a policy document.
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.
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 both deployment shapes, so the on-premises option 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. 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.