Healthcare
Healthcare software built for the year after launch
A clinical model can get worse without anyone touching its code. We build the monitoring, the audit trail and the review step that catch it.
What a healthcare buyer should ask any vendor
4 things that decide this
- 01Ask how the software behaves when the patient mix changes. The University of Michigan switched off its Epic sepsis model in April 2020 because the pandemic changed who its patients were. Nobody edited the model.
- 02Ask where the audit trail lives. Rebuilding who-saw-what after a breach question is not possible unless somebody designed for it before the first commit.
- 03Ask how the vendor handles an integration queue. EHR interface work is a shared hospital resource, so the schedule is set by the interface team's backlog rather than by your sprint.
- 04Ask who reviews the output. Our clinical AI ranks and retrieves. A named clinician finalises every result, which is the design the published evidence supports.
Clinical software fails quietly, which is why it fails late
Ordinary software tells you when it breaks. A page errors, a queue backs up, somebody gets paged. Clinical software has a worse failure shape. A drifted model returns a well-formed answer at the usual speed, and a human notices months later.
That is not a rare event. A routine electronic health record update can break a model without changing a line of its code. So can a new lab assay, or a move from ICD-9 to ICD-10 coding. The model keeps answering.
Most agencies sell you the build and leave. We price the year after launch into the work, because that is when the interesting problems arrive.
Published evidence, not our numbers
What the research says about deployed clinical AI
0.63
Measured AUC of a widely deployed sepsis model, against a vendor claim of 0.76 to 0.83 (Wong et al., JAMA Internal Medicine, 2021)
67%
Sepsis cases that model missed across 38,455 hospitalisations, same study
41s
Time saved per note by the better of two ambient AI scribes in a 238-physician randomised trial (Lukac et al., NEJM AI, 2025)
40.2%
Published MIMIC prediction studies that used post-discharge diagnosis codes as inputs, a known methodological flaw (Ramadan et al., JAMA Network Open, 2025)
The healthcare work we take
A shorter list than most agencies publish, because it matches what we have shipped.
Human-in-the-loop clinical AI
A model that ranks, retrieves or drafts, and a named clinician who finalises the result. This design keeps a tool on the safer side of the device boundary and it is what the evidence supports.
Eligibility and matching engines
Parsing messy criteria and scoring candidates against them. TrialTriage matches oncology patients to trials for nurses and insurers, and a nurse signs off every match.
Compliance-gated workflow
Rules checked at the moment of assignment rather than once at signup. Document validity, expiry tracking, and logic deciding what a person may do today.
Audit trails that answer questions
Logging designed so you can say which records a named person opened on a given day. Plain request logs cannot answer that, and the breach clock does not wait.
De-identified data models
Age bands, ZIP prefixes and stand-in patient identifiers, chosen at design time with field-level encryption underneath. Never collecting a field beats stripping it later.
Monitoring and evals
A test suite you can rerun plus watching on live inputs, because inputs drift before accuracy does. A model that has quietly got worse still sounds confident.
Prior authorisation and appeals tooling
Assembling the evidence packet from unstructured notes and tracking status per payer. The rules change without notice, so the software has to make that visible rather than hide it.
- ValidatedScores well on the test set.
- DeployedClinicians start trusting it.
- Inputs moveNew assay, new coding, new case mix.
- Still answeringNo error. No alert. Same speed.
- Trust erodesStaff quietly start overriding it.
- Switched offMonths later, by a human who noticed.
Nothing in this sequence throws an exception. The only defence is watching the inputs and keeping a reviewer at the point where being wrong is expensive.
A model that scores almost perfectly is usually cheating
In 2025 researchers reported a mortality model scoring 0.976 on diagnosis codes alone. That looks like a breakthrough. It is worthless, because those codes are assigned after the patient leaves. The model had learned that somebody had already coded brain death.
The same review found 37 of 92 published studies made this mistake. These are peer-reviewed papers, not weekend projects. If it slips past reviewers it will slip past your pilot.
So we ask an unwelcome question early. When was each input actually recorded? If a field only exists after the thing you are predicting, the score is fiction and the pilot will look wonderful.
- Check the timestamp of every input against the moment of prediction.
- Treat a suspiciously high score as a bug report.
- Hold out a period of data the model has not seen, rather than a random split.
Regulated-data systems with a human decision point
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
Pilot-shaped delivery against production-shaped delivery
| Criterion | The usual healthcare pilot | How we build |
|---|---|---|
| Accuracy | Measured once, on a random split, before launch. | Measured on a held-out time period, then watched on live inputs. |
| Audit logging | Request logs, added when the security questionnaire arrives. | A designed trail keyed to records and people, from the first commit. |
| The human | A disclaimer telling the clinician to use judgement. | A review step in the data model, so you can prove review happened. |
| De-identification | Stripped from a full dataset on the way out. | Fields never collected, chosen when the schema is drawn. |
| After launch | A support inbox and a change request form. | Input monitoring, an eval suite you can rerun, and an agreed service level. |
What these builds run on
Application
Data
AI
Delivery
What buyers ask before they commit
01How much does healthcare software development cost?
Three things drive the cost. How many systems you must integrate with, whether a regulated record is involved, and who signs off before release. A tool a clinician reviews costs less than one acting alone, because the safety burden differs. Scoping calls are free. Where the answer depends on code we cannot see, a paid two-week diagnostic settles it, and you get a fixed number rather than a guess.
02What is the difference between a clinical decision support tool and a medical device?
The line turns on what the software does with the data and whether a clinician can check its reasoning. Analysing a medical image or a signal from a diagnostic device puts you on the regulated side regardless of wording. Showing information a professional can independently review keeps you off it. Point the same tool at a patient rather than a clinician and the answer changes again. Get counsel involved while the design is still moving.
03Can you work with the engineering team we already have?
Yes, and it is often the better arrangement in this sector. Your team knows the clinical context and the politics of the interface queue, which takes an outsider months to learn. We take the parts nobody has time for: the audit model, the eval suite, the monitoring. We write down why each choice was made, because in eighteen months nobody remembers.
04How do you keep patient data out of a model provider's hands?
Start by not sending it. Most clinical features work on de-identified or tokenised inputs, and the fields you never collect cannot leak. Where identifiable data must reach a vendor, that vendor needs its own agreement covering it, and so does every subcontractor beneath it. A signed agreement is a promise about handling, not proof of a control, and your privacy officer owns that judgement rather than us.
05Our pilot worked. Why do you say the hard part is next?
A pilot runs on curated data with attentive users and someone watching. Production has none of those. The published record is unkind here. One widely deployed sepsis model scored 0.63 where its vendor claimed up to 0.83. The best randomised evidence on ambient scribes found a third of physicians barely used the tool. Adoption and drift kill more clinical software than model quality does.
Go deeper
- Healthcare compliance and PHI in practice →The regulation detail, the BAA limits, and what the proposed Security Rule would change.
- How do you build HIPAA-compliant AI? →Where PHI enters the pipeline and what must be true at each point.
- Dataset shift →Why a clinical model gets worse without anyone changing it.
- Clinical research software →Trial matching, Part 11 records, and where the regulated core begins.
