Synthetic patient data for healthcare testing
Most synthetic data is a file. You download a few thousand generated patients, load them, and discover that the hard part was never having rows: it was knowing what your systems should have done with them. MediFlow generates the cohort and then runs it through your environment, carrying the answer key for what should happen at each step.
Data that sits still tests very little
A static export can prove your database accepts records. It cannot tell you whether an ADT arriving out of order left a patient in two beds, whether a critical potassium reached the right pager, whether your interface engine recovered the message it dropped during a restart, or whether a duplicate MRN quietly created a second chart. Those are the failures that hurt at go-live, and every one of them is about behaviour over time, not about having enough rows.
So MediFlow builds each patient as a journey. A patient is admitted, ordered, resulted, documented, escalated, discharged and billed, in the order those things really happen, and each message is delivered into your environment the way a real sending system would deliver it.
Clinically coherent, not randomly filled
Random values are easy to spot and useless to test with. A patient with a diagnosis of heart failure and a perfectly normal BNP tests nothing, and a clinician reviewing your test output stops trusting it immediately. MediFlow ties the values to the story:
- The diagnosis drives which panels are ordered and which results come back abnormal.
- Deterioration is progressive: a septic patient's lactate, white count and vitals move across successive draws instead of jumping to a single dramatic value.
- Recovery is modelled too, so you can test the improving patient, not only the crashing one.
- Notes are written to match the case, across the note types a real chart accumulates.
Every code is a real code
Test data quietly rots. A diagnosis code that was billable three years ago becomes a category header when the code is subdivided; a drug identifier is retired and replaced. When your synthetic feed carries those, a clean run proves nothing and a failed run sends you hunting a defect that lives in the test data.
MediFlow checks every code it emits against the published release, and the build fails on a code that is not billable, not current, or not a code at all. That covers LOINC, ICD-10-CM by fiscal year, RxNorm and CVX. Where a standard genuinely has no code for a concept, the message carries a local code marked as local rather than a plausible-looking wrong one.
The formats your systems actually speak
| Standard | What MediFlow produces |
|---|---|
| HL7 v2 | ADT, ORU, MDM, ORM, RDE, DFT, VXU, SIU and more, delivered over MLLP or HTTPS, with acknowledgements checked |
| FHIR R4 | Resources and Bundles in JSON and XML |
| C-CDA | Continuity of Care Documents, for transition-of-care testing |
| X12 005010 | 837P claims, 835 remittance, 270/271 eligibility, 276/277 status, 278 authorisation, with TA1 and 999 |
| Legacy middleware | A SOAP 1.1 endpoint with generated WSDL, for systems that cannot call REST |
The claim and the clinical message come from the same encounter, so they reconcile because they were built together rather than because someone lined them up by hand.
Nothing real, and nothing that pretends to be
MediFlow never copies a production record. Patients are generated, identifiers are synthetic, and the traffic is marked so it can be told apart from real traffic downstream. Delivery stays switched off until a test destination is configured deliberately, because the most expensive mistake with good synthetic data is sending it somewhere real.
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.