Built for the team that has to prove it works before go-live
If your job is to sign off on a go-live, approve an upgrade, or certify a new interface, "it worked in the demo" is not evidence. You need to know what happens when a lab sends a code your system has never seen, when a note carries characters that break a parser, when every hospital stamps its own local time, and when a receiving system has to decide, on its own, what an unfamiliar result means. MediFlow generates that traffic — synthetic patients, real HL7 v2 and FHIR R4 messages, sent the way hospitals actually send them — so you find the defect before a patient does.
Four teams, four different things to prove
| Team | What they have to prove |
|---|---|
| Hospital IT / systems | The new or replacement system handles the full range of message types and patient journeys a live hospital produces, not a curated sample. |
| Interface engineers & analysts | Every channel — ADT, ORU, orders, pharmacy, billing — parses, routes and acknowledges correctly, including the awkward ones: local codes, special characters, unfamiliar identifier formats. |
| Lab informatics | A result coded by someone else's local system still lands as the right test, on the right specimen, in the right units, in your system. |
| EHR go-live / implementation | The whole cutover — registration through results, orders, notes, billing and claims — behaves the same in the new environment as the plan says it will, with evidence to show a steering committee. |
The kind of defect this is built to catch
22 simulated hospitals, each with its own habits
A single anonymous test feed cannot tell you what happens when a dozen different critical-access hospitals each code potassium a little differently, or when a rural hospital's accession numbers do not look like a regional referral center's. MediFlow's registry holds 22 simulated hospitals — 21 Utah rural and critical-access hospitals plus a CareCompile reference hospital — 14 switched on at any time, each with its own MRN, visit and accession formats. Send traffic as a single hospital to test one channel, or run all of them together to rehearse a regional platform.
Everything a real hospital sends, not a curated sample
Codes are checked against the official LOINC, ICD-10-CM, RxNorm and CVX releases before they ship, so a rejection in your test run is your system's behavior, not a symptom of bad test data. See validated test data for how that check is enforced.
| Category | Message types |
|---|---|
| Admissions, transfers, discharges | ADT |
| Results | ORU |
| Notes | MDM |
| Orders & pharmacy | ORM, RDE, RAS |
| Immunizations | VXU |
| Billing | DFT, BAR |
| Scheduling | SIU |
| Referrals & claims | Referral messages, X12 837/835/270/271/276/277/278 |
| Modern interop | FHIR R4 resources and bundles |
Messy on purpose, because production is messy
A clean, well-formed test file is easy to build and tells you very little. MediFlow's traffic keeps the parts of real hospital data that usually get sanded off a demo:
- Local lab codes with no LOINC equivalent — sent as an explicit local code, not a guessed one, because that is what your mapping layer will actually meet.
- Free text carrying HL7 special characters — the escaping bugs that only show up once a note has an ampersand or a pipe in it.
- Each hospital's own local time, with its own offset — stamped with its UTC offset, not bare UTC, so a receiver that ignores the offset is caught rather than silently hours off.
What v14 adds for lab informatics: a scored semantic bench
Beyond whether a code is valid, v14 asks whether your system understood it. The semantic test bench runs 62 cases across five test families — potassium, sodium, glucose, creatinine, hemoglobin — from 13 hospitals each coding the same test its own way, with deliberate traps: a urine result given a blood-sounding name, a hospital reusing another hospital's code for a different test, results reported per twenty-four hours instead of per sample. Given the receiving system’s outcomes for the run, every case is graded resolved, held for a human, wrong, or a false alert, against an answer key sealed before the run goes out. That is a number a lab informatics team can bring to a go-live review, not an impression.
What you get to bring to a go-live decision
- Complete patient journeys, not three sample messages: registration through results, orders, notes and billing, for as many synthetic patients as the test needs.
- Per-facility results, so a regional platform can see which hospital's traffic mapped cleanly and which one did not.
- An answer key for every run, so a clean pass means something and a failure points at a defect class, not a mystery.
- No real patient data anywhere in the exercise, so the rehearsal itself never becomes a privacy question.
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.