Complex Healthcare Data Migration
Hospital migrations move decades of patient, case, and movement data into a new system while the hospital keeps treating patients. The difficulty is not the volume. It is that each system describes a patient’s stay in its own terms, that nothing may be silently lost, and that the switch has to happen without the hospital stopping.
Why Healthcare Migrations Are Difficult
What distinguishes hospital administrative (ADT) migrations from other industries. Each one is a business question before it is a technical one.
The hospital cannot stop
The emergency department keeps receiving patients and the wards keep treating them while the systems change. There is no weekend-long freeze. The cutover has to be planned so the hospital continues to operate, and the window in which neither system is fully available has to be as short as possible.
Patients in the middle of their stay
At go-live there are patients in the emergency department, in the wards, and in the middle of an ambulatory series. Their cases are not history to be archived. They have to be loaded so that the next movement, the discharge, and the billing continue in the new system as if the case had started there.
A stay is modelled differently in every system
What counts as a case, a movement, a visit, and a transfer differs between systems. One legacy system holds an emergency visit, a ward admission, and an ambulatory visit from the ward as separate cases; another already combines them but with different movement types and granularity. Either way the history has to be re-told in the target’s model without losing what happened.
Decades of history under clinical and legal accountability
Patient history is kept for decades and may be needed in a clinical, legal, or billing question years later. Every source record and field that is not migrated needs an explicit decision: another system, the data warehouse, an archive, a static snapshot of the legacy screens, or a documented drop.
Data shaped by operations, not by the schema
Years of staff working around the system: admission times moved for billing, payer codes that mean "cancelled" or "belongs to the admission", discharge types that mean "sent to another emergency site", dates with day 00. The meaning is in the data and in the people who entered it, not in the data model.
Populations with their own rules
Newborns linked to the mother’s case, deceased patients, unidentified and foreign patients, patients insured by institutions, identity numbers corrected and kept as "old ID". Each needs its own rules in the target and its own test.
An organisation that changed over the years
Departments were opened, merged, renamed, and moved. Historic movements point at units that no longer exist, while the target needs a valid unit, physician, and payer for every movement. The mapping of organisational history is a project in itself.
Many professions, one set of decisions
Administrative staff, clinicians, billing, IT, the target vendor, and often the regulator each hold part of the meaning. Decisions have to be taken with all of them, written down, and still be traceable when the data is questioned after go-live.
Cutover While the Hospital Keeps Running
The bulk of the history is loaded before the cutover and kept current with deltas through the rehearsals. The final window carries only the last delta and the open cases: patients in the wards, in the emergency department, and in running ambulatory series, extracted last and loaded so that the new system can continue them, with new movements, discharges, and billing, as if they had started there.
- Full load
- Rehearsals & deltas
- Final delta
- Open cases
- Go-live
In one hospital migration the window was under eight hours, on a weekend night. What made it short was not speed on the night but the design: everything that could be loaded earlier was, and what remained had been rehearsed on real data.
Test, Rehearse & Migrate in the lifecycleWhat This Means for the Project
Clinical and administrative staff sit in the mapping sessions
Rules about cases, movements, and populations are decided with the people who created the data and will work with it, together with the target vendor. Each decision is recorded with who took it and when.
Cutover and open cases are designed at the start
How open cases are extracted, numbered, loaded, and made operative, and how short the window can be, is decided during scoping, not discovered in the last rehearsal.
Months of rehearsals fed by deltas
The hospital keeps producing data throughout the project. Rehearsals run on complete, current data, with deltas computed even when the legacy system has no change log.
One example
From Separate Legacy Cases to One Target Case
In a mainframe system built in-house, a patient who arrives at the central emergency department, is transferred to a second emergency site, is admitted to a ward, is sent from the ward for an ambulatory test, and is discharged, is five separate cases with separate keys. The target holds one case with a chain of movements.
- Emergency
- Transfer
- Admission
- Ambulatory
- Discharge
Merging them meant deciding, for every combination that existed in the data, where the case starts, where it ends, which movement each legacy case becomes, and what to do when the timestamps do not agree. The analysis of the extract showed what the rules had to cover:
- millions of single-site emergency visits, and well over a hundred thousand that spanned two, three, or four emergency sites
- over a thousand pairs of overlapping admissions, which the target cannot hold
- thousands of emergency visits whose discharge was recorded after the discharge from the admission they led to
- dozens of admissions contained entirely within the emergency visit that preceded them
- over a thousand emergency visits longer than five days, resolved by a rule that caps a visit by duration
None of these cases was in a specification. All of them were in the data.
A source that already holds combined cases raises different questions: which movement types exist on each side, how ambulatory visits attach to a case, how two events at the same minute are ordered. The questions change; the way they are answered does not. The rules are derived from the data and agreed with the hospital.
Migration as Early Warning for Target Configuration
The new system is configured while the migration is mapped: organisational units, case and movement types, payer and insurance catalogues, patient types. Mapping decades of real cases against that configuration finds the scenarios it does not yet handle, such as a status the target has no answer for, a population held at a different level, or an event sequence it cannot represent, while the configuration can still change.
Principle: expose gaps earlyComplex Hospital Data Migration
Administrative migration from a mainframe network database into a modern hospital system, with case merging, governed decisions, and source-to-target proof.
Read the case studyPlanning a Healthcare Data Migration?
Let's examine the source environment, target objectives, and migration challenge.