MCHD ManagerPerformance governance for a hospital group
MCHD Manager holds a hospital group's indicators, risks, improvement plans and committees in one place, and the projects that move them. We designed the product and built it as a multi-tenant platform in English and Arabic.
- Client
- Private client
- Sector
- Healthcare
- Year
- 2025 to 2026
- Platforms
- Web platform, Tablet, Mobile web
- Services
- Product and UX design, Web development
A hospital measures itself constantly and still struggles to answer simple questions. MCHD Manager gives the group one structure for that work: strategic domains, the departments underneath them, the indicators each department owns, and the risks, plans, committees and projects attached to those indicators.
Built for
- The quality and performance office, who own the measurement.
- Executives, who need the roll-up and the exceptions.
- Heads of department, who report the numbers and answer for them.
- Committee chairs and secretaries, who turn the numbers into decisions.
The problem
Hospital performance reporting usually runs on spreadsheets and a quarterly pack assembled by hand. By the time it is signed off it describes a quarter that has ended, and nobody in the room can say which figures are late, which are disputed and which were simply never collected.
The deeper problem is that an indicator means different things to different people. Average length of stay is one number in surgery and another in obstetrics because the two departments count it differently, and the difference is invisible once both are in the same table.
Risks, improvement plans and committee decisions all exist, and all live somewhere else. A risk about theatre staffing sits in one register, the indicator it threatens sits in another, and the project meant to fix it sits in a third. Nothing connects them, so nothing follows through.
The group also runs more than one facility, and the platform has to keep them apart without making staff feel walled in.
Goals
- 01Define an indicator once, precisely enough that two departments cannot mean different things by it.
- 02Show where every indicator stands and which way it is moving, not just its latest value.
- 03Connect risks, improvement plans, committees and projects to the indicators they belong to.
- 04Keep each facility's data separate without leaking that another facility's records exist.
- 05Work in English and Arabic, in both directions, for the same staff on the same day.
Our role
We designed the product and built both halves of it, and we run and maintain the platform.
What we delivered
- Product definition from a two-year requirements register
- Interface design and a platform token system
- Express and PostgreSQL back end on the Bun runtime, no ORM
- Nuxt front end, server rendered, English and Arabic with full right-to-left
- Multi-tenant hospital scoping and the permission model
- KPI definition, data entry, scorecards and period snapshots
- Risk register, improvement plans, committees and governance reporting
- Workspaces, projects, tasks and RACI for the delivery work
- Deployment, background jobs, notifications and monitoring
How we worked
- 01
Start from the requirements register
Two years of client conversations were turned into a numbered register of requirements, and the scope was held to it. Every screen can be traced back to the line that asked for it.
- 02
Define the indicator properly
Before any dashboard, we modelled what an indicator is: its unit, its direction, how often it reports, what goes above and below the line, its baseline, its RAG bands, its benchmark and the authority behind it, and whether it is risk adjusted.
- 03
Make the numbers add up
The dashboard figures are returned as one contract with sum invariants the front end checks. Totals that disagree with their own breakdown are treated as a bug, not a rounding difference.
- 04
Give linking a single door
Risks, plans, committees, indicators and projects link through one service with an allowlist and authorisation on both ends, so a link can never be made that either side was not entitled to make.
- 05
Run it and keep fixing the real bugs
The platform is deployed and in use. The recurring root causes were written down as engineering rules, so the same class of bug does not come back.
Screens and features
An indicator is a definition, not a number
Unit, direction, frequency, numerator and denominator, measure type, baseline, RAG bands, benchmark value and the authority it came from, and whether the figure is risk adjusted.
Not reported is a first-class state
Scorecards separate on target, needs attention and not reported yet, because a missing figure is a different problem from a bad one and needs a different person to fix it.
Direction of travel, not just position
Each indicator shows its trend against target and says plainly when it is moving the wrong way, with the distance from target expressed in the indicator's own unit.
A risk matrix that filters
Likelihood against impact in a five by five grid, with severity and status breakdowns, and the register below it narrowing to whatever cell you pick.
Everything links through one spine
Indicators, risks, improvement plans, committees, projects and tasks are linked through a single service that checks both ends and stamps the facility server side.
Separation between facilities that does not leak
Fetching a record from another facility returns a not found, never a forbidden, so the platform never confirms that a record you cannot see exists.
English and Arabic, both directions
Indicator names, domains and departments carry both languages, and the interface mirrors rather than being flipped by a stylesheet.
Technical choices
What the product is built with, and why.
- Express on the Bun runtime
- Bun runs the existing Express application with a faster startup and a built-in SQL client. The trade is that its driver differs from node-postgres in ways that bite quietly, so those differences are written down as project rules rather than rediscovered.
- PostgreSQL with no ORM
- The queries here are roll-ups across a hierarchy with per-facility scoping. Written as SQL they can be read and tuned; through an ORM they become something nobody can explain when a report is slow.
- Canonical status names, constrained in the database
- Status has a fixed internal name and a separate label users can edit. Reports group on the fixed name, so renaming a column heading cannot silently change a chart.
- A dashboard contract with sum invariants
- Every breakdown must add up to its own total, and the front end checks it. This came out of a period when two screens disagreed about the same figure, which costs more trust than a missing feature.
- One notification dispatcher
- Every notification goes through a single path, so a new feature cannot invent its own way of reaching people and bypass preferences.
- Errors that say nothing useful to an attacker
- Server errors return an identifier the user can quote and nothing else. The detail stays in the logs, where it belongs.
Numbers that have to be trusted?
Measurement, permissions and reporting that survives scrutiny is the work we like most. Tell us what you are measuring.