A healthcare records provider

The problem

The client had grown by acquisition and inherited six patient record systems, two of which no longer had a supported vendor. Clinicians were re-keying data between them, and no single system could answer 'what happened to this patient' — which is both a care problem and, under their regulator, a reportable one.

What we did

1. 01

   Strangle, never big-bang

   A migration cutover for clinical records is an unacceptable risk profile: the failure mode is a clinician without a patient history. A façade API went in front of all six systems first, reads were moved to it, and the underlying systems were retired one at a time behind an interface that never changed.

2. 02

   Make the audit trail the primary record

   Every read and write through the façade is logged immutably with actor, purpose and patient. This was a regulatory requirement, but it also turned out to be the migration's safety net — a discrepancy between old and new could always be traced to the exact call that caused it.

3. 03

   Shadow-read for eight weeks

   Before each system was retired, the new path served every request in parallel with the old one and diffed the results without showing them to anyone. Three data-mapping errors surfaced this way, all before a clinician could ever have seen them.

What changed

The last legacy system was switched off in the thirty-first week with no downtime window and no clinical incident. The client's regulator closed the outstanding audit finding at the following review.

Systems consolidated

6→1

Downtime during migration

0 minutes

Clinical incidents attributed to migration

0

Mapping discrepancies caught pre-cutover

3

Record retrieval time

~4 min (manual)→1.2s

Built with

• Node.js
• PostgreSQL
• Python
• AWS
• OpenTelemetry
• Next.js