Replacing a hospital network's scheduling core without stopping the clinics
A twenty-year-old scheduling system migrated site by site behind a compatibility layer, with HIPAA controls designed in and no clinic closed for a cut-over.
- Region
- United States
- Industry
- Healthcare
- Engagement model
- Project Engagement
- Duration
- Phased over a defined programme
- Client
- A hospital network
Context
A hospital network in the United States schedules every appointment, procedure room and clinician through a core system built two decades ago and extended by every team that has touched it since. Dozens of consumers depend on it: the electronic health record, the patient index, the billing system, the patient portal, the call centre, the operating-theatre planners and a set of interfaces nobody has documented. It works, most days, and nobody wants to be the person who turned it off.
The constraints are clinical and legal. Downtime is not an outage; it is a clinic that cannot see patients. Protected health information moves through every interface, so the HIPAA privacy and security rules govern the design of anything that replaces it, and the network's compliance office must sign the controls. A big-bang cut-over over a weekend would put both the clinics and the compliance office at risk at once.
The mandate is to replace the core without a cut-over: a compatibility layer that speaks the old system's contracts to every consumer, a new core built behind it, consumers moved one at a time with dual running and reconciliation, rehearsed rollback at every step, and the network's own engineers operating the pipeline at the end.
Mandate
The engagement is bought as a Project Engagement: a fixed scope against acceptance criteria written before the first day, phased by site and by consumer, with the handover to the network's engineering team as part of the scope.
- 01Map every consumer, interface and batch job of the existing core, including the undocumented ones, and the people who own each.
- 02Build a compatibility layer that preserves the existing contracts so no consumer is asked to change before the new core is ready for it.
- 03Build the new scheduling core with its invariants written down and enforced, integrated with the electronic health record and the patient index.
- 04Move consumers one at a time with dual running and daily reconciliation, in the quietest window, with a named rollback owner present.
- 05Design HIPAA privacy and security controls — access, audit, encryption, minimum necessary — into the platform and have the compliance office sign them before the first site moves.
- 06Leave the network's engineers releasing, rolling back and resolving incidents without Altuon before the legacy core is retired.
Approach
- 01
Discover
Read the legacy core as it runs — code, schema, batch jobs, interfaces — and interview the operators and the clinics; establish the business-continuity constraints per site and the HIPAA obligations with the compliance office; produce the dependency map.
- 02
Define
Design the target core and the compatibility layer; decide the order in which consumers and sites move; write the data model and its invariants, the test and observability standards, and the rollback procedure for every step; agree the definition of done for documentation.
- 03
Build
Build the compatibility layer and the new core behind it, the integration layer and the delivery pipeline, with tests, observability and documentation written alongside the code; rehearse each cut-over step in an environment shaped like production.
- 04
Prove
Move the first consumer at the first site onto the compatibility layer; dual-run and reconcile against the legacy core until the difference is zero and stays there; move the next consumer; the network's operators run the runbook without Altuon before the second site.
- 05
Operate
Move the remaining sites and consumers; retire the legacy core when nothing depends on it; hand over with the network's engineers shipping changes through the pipeline and Altuon on call until they choose not to need it.
What was built
- Dependency map
- Every consumer, interface, batch job and data flow of the legacy core, with owners, kept current as consumers move.
- Compatibility layer
- The contract-preserving front to the legacy core through which consumers move one at a time, retired with the last one.
- New scheduling core
- The system of record for appointments, rooms and clinicians, with its invariants enforced and its source in the network's repositories.
- Integration layer
- Versioned interfaces and events to the electronic health record, the patient index, billing, the portal and the call centre, with contract tests on both sides.
- Data migration and reconciliation
- Record migration with lineage, dual running, and reconciliation comparing old and new on every record and every day.
- HIPAA control set
- Access control, audit logging, encryption, minimum-necessary design and the evidence package the compliance office signs.
- Pipeline, tests and observability
- Reproducible builds, a test suite that blocks failing releases, dashboards and alerts designed with the operators.
- Runbooks and rehearsed rollback
- Release, rollback, restore and incident procedures, each run by the network's team before handover.
Outcome
A blueprint measures what the mandate promised. The figures below are the ones this engagement would report at each site's cut-over gate; they are filled from the record when a client approves publication, and are otherwise shown as the measures rather than as numbers.
- Unplanned downtime during the migration
- Measured against the baseline agreed in the mandate
- Appointment throughput, against the baseline
- Measured against the baseline agreed in the mandate
- Legacy interfaces retired
- Measured against the baseline agreed in the mandate
Timeline
Stack
Bring us a mandate like this one.
A proposal request takes seven short steps and is read by the engagement lead who would run the work. References for real engagements are provided under non-disclosure, matched to your industry and region.