Test a network, not one anonymous feed
A health information exchange, a regional platform or a multi-hospital system does most of its work per facility: routing by site, attribution, coverage by site, onboarding one hospital at a time. Test data that arrives from a single anonymous sender exercises none of that. MediFlow sends as a network.
What a single-sender feed cannot test
- Routing. Whether a message from one site reaches the right queue, tenant or downstream consumer.
- Attribution. Whether a record is credited to the facility that sent it, in the record and in the report.
- Coverage by site. Which hospital's codes map cleanly and which one is generating the orphans.
- Identity across sites. The same person with different medical record numbers at two hospitals.
- Onboarding sequence. What happens to the running platform when a new site starts sending.
- Per-site volume. A critical-access hospital and a regional referral centre do not produce the same load, and a queue that copes with one may not cope with both.
Facilities as a registry you control
MediFlow keeps a list of facilities, each with its own code and NPI, and every message it produces carries that facility in the sending-facility field. The list is not compiled into the product: facilities are switched on, switched off or added while the engine runs, so a rehearsal follows your onboarding plan instead of the other way round.
| What you do | What happens |
|---|---|
| Switch a site on | New patients start being assigned to it, and its messages carry its identifier |
| Switch a site off | No new patients are assigned to it; patients already sent keep their facility and their history |
| Add a site | It joins the rotation immediately, with its own code and NPI |
| Run a rehearsal | Results come back per facility: what mapped, what failed, how long it took |
Onboarding rehearsal, site by site
For a programme bringing rural or community hospitals onto a shared platform, the useful sequence is the same each time, and each step leaves evidence:
- Profile the site: sending system, message types, code sets, volumes.
- Simulate it: the facility exists in MediFlow with its own codes and its own volume.
- Rehearse it: full-volume synthetic traffic, scored against expected outcomes, with no PHI anywhere in the exercise.
- Cut over: the real feed replaces the simulated one, and reconciles against the rehearsal.
The value of step two and three is that a site can be tested end to end before its agreement, interface and data are all in place — which is usually the long pole in any onboarding schedule.
Codes differ by site, and so should the test
Facilities do not send identical data. Local codes, local panel names and local habits are exactly what a mapping layer has to absorb, and they are the thing a generic feed hides. Because every code MediFlow emits is validated against the published release, the differences that remain between sites are the ones you need to see, rather than noise from stale test data.
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.