case study · qyire · clinical software
complex care,
clearly
connected
Qyire is a specialist electronic patient record for eating disorder services — one structured record for the whole multidisciplinary team, across inpatient, residential, outpatient, community and virtual care. We designed and built it end to end, and took it from an empty repository to live production with real patient data in 52 days.
fig 01 · the clinical record, abstracted — the overview a care team works from: a triaged caseload, score trends, physical assessment, weight monitoring, meed trajectory, stability signals and tasks. layout real; every name and number here is a placeholder shape.
the brief
more time for care, less on administration
One record for the whole team.
Eating disorder care is genuinely multidisciplinary — psychiatry, therapy, dietetics and physical health monitoring, often split across settings and systems. Teams were switching between disconnected tools to see risk, progress and care in one view, and paying for it in admin time.
The brief was a single structured record built for that reality: diagnostics, physical health monitoring, risk assessments, care plans, virtual consultations and governance in one place — clear enough that any member of the team can see the state of a patient's care at a glance.
And because it holds real patient records, it had to be built as what it legally is: a UKCA medical device, with the engineering discipline that classification demands.
the platform
a lean core, capability as modules
From referral to recovery, one system.
The core is deliberately small — patients, tasks, dashboard, audit log. Everything clinical ships as one of 21 modules that activate per organisation, so a service turns on exactly what it needs: outcome measures, blood tests, investigations, video consultations, AI scribing, safeguarding.
validated outcome measures ship with clinician sign-off gating built in:
what we built
design to deployment
A regulated product, built like one.
We took Qyire from product design through full-stack development, AI integration and deployment as one team — engineered and documented to UKCA medical-device standards from the first commit, not retrofitted at the end.
A lean clinical core — patients, tasks, audit logging on every table — with clinical capability delivered as per-service modules that activate per organisation. Strict multi-tenancy throughout, and every AI-assisted output surfaced behind a clinician-must-verify control.
It is in production with clinical teams today, holding real patient records on credential-isolated infrastructure.
how a request travels
the same path, every time
Zero trust between the browser and the record.
Every clinical read and write follows one path: the edge verifies the session and resolves the organisation, the handler checks role and PHI rights and validates every input, and every query is scoped to the organisation before row-level security gets its say as the second line — not the first.
fig 02 · the request path, and the longer one AI output takes — nothing an AI writes reaches the record without a named clinician verifying it first.
safety and governance
engineered in, not bolted on
Compliance as architecture.
Six regulatory frameworks shaped the codebase from day one. That order matters commercially as much as clinically: a service procuring Qyire starts the governance conversation with the paperwork already alive in the repository.
how it was delivered
first commit 8 may · cutover 29 june
Fifty-two days to live.
From an empty repository on 8 May 2026 to production cutover with real patient data on 29 June — and the pace held after launch, because a modular core makes every next feature cheaper than the last.
fig 03 · the delivery timeline. cutover was not the finish line — july was the busiest month of the project.
fig 04 · commits per month, from the repository history. dashed = month in progress.
measured from the qyire repository and engineering docs, aug 2026.
the stack
chosen to be replaceable
Boring where it matters.
Clinical software earns trust by being unexciting under the hood. Every vendor sits behind an interface the codebase owns — the database, the AI provider and the host can each be swapped without touching clinical logic.
project · specification
Building something regulated?
hello@envlpr.com. We'll tell you honestly whether we're the right team for it.