Rehearse the cutover before a real patient is in it
Every migration plan has a cutover weekend and a rollback plan. What most of them do not have is a way to find out, in advance and on an ordinary afternoon, which interfaces will misbehave when the real traffic starts. That is what a rehearsal is for, and synthetic patients are what make it possible.
The defects that wait for go-live
Integration defects are rarely exotic. They are the same handful, and they only appear under real sequence and real volume:
- A transfer that arrives before its admission and leaves the encounter wrong.
- A result sent twice that becomes two results instead of one.
- A critical value that maps to a field nobody routes to a pager.
- A code the new system does not hold, which silently becomes an orphan instead of an error.
- A queue that keeps up at ten messages a minute and collapses at two hundred.
- A restart mid-run, where the sender retries and the retry duplicates.
None of these show up in a smoke test with three sample messages. All of them show up in a rehearsal.
Every run carries an answer key
This is the part that separates a rehearsal from a load test. Each synthetic patient is built with the outcomes it should produce: this admission should create one encounter, this potassium should raise a critical alert, this duplicate should be discarded, this discharge should close the account. MediFlow sends the journey, watches what the environment does, and scores the actual behaviour against the expected behaviour. The output is not "it ran", it is a list of what passed, what failed, and which defect class each failure belongs to.
Facility by facility, not as one anonymous feed
If you are cutting over several sites, or standing up a regional platform, the interesting differences are between facilities: their code sets, their volumes, their local habits. MediFlow keeps a registry of facilities, each with its own identifier and NPI on every message, so a rehearsal produces per-facility results: what this hospital's traffic did, what mapped, what did not, and how long its onboarding took. Sites can be switched on one at a time, in the order your plan brings them on.
Rehearse, then cut over
| Stage | What happens | What you get |
|---|---|---|
| Profile | Capture the sending system, message types, code sets and volumes | An interface profile you can hand to the vendor |
| Simulate | The facility exists in MediFlow with its own codes and volume | A feed that looks like that site, not a generic one |
| Rehearse | Full-volume synthetic traffic into the new environment | A scored run with the defect list |
| Fix and re-run | Repeat until the score holds | Trend across runs, not a single snapshot |
| Cut over | The real feed replaces the simulated one | Reconciliation against the rehearsal baseline |
No PHI in the rehearsal
Rehearsing with copied production data means putting real patient records into a system that is, by definition, not yet trusted. Synthetic patients remove that entirely: nothing is copied from a real chart, the traffic is marked as synthetic, and delivery is switched off until a test destination is configured on purpose.
Tell us what you need to trust
Describe the workflow, interface or release you are validating. We define the synthetic patients, the interface profile, the expected outcomes and the evidence you get back. Reply within one business day.