01 / BUILD
Patient Cohort Builder
Generate condition-aware populations with configurable demographics, acuity, diagnoses, labs, medications, edge cases, expected outcomes, and replayable scenario identities.
MediFlow sends the HL7 v2 and FHIR R4 traffic a real hospital sends — admissions, orders, results, notes, claims — from a network of simulated hospitals into your systems, then scores what your systems did against a sealed answer key. Built for interface, lab-informatics and EHR go-live teams. No real patient data anywhere in the run.
v14 is about proving a receiver understands the code, not just accepts the message: a sealed, scored semantic test bench, and a release process gated on its own tests.
v12 is about trusting the test data itself: every code checked against the official release, and every hospital a real one you control.
Released September 7, 2026. v11 adds the administrative half of interoperability to the clinical half v10 already had.
Each row is counted from the receiving system's own message log. Through v10 the release was read from MSH-4; since September 2 it is read from MSH-3, where the version now travels. Nothing here is authored by hand.
| Release | In service | HL7 messages delivered |
|---|---|---|
| V4 | Mar 25, 2026 – Apr 14, 2026 | 20,759 |
| V5 | Apr 14, 2026 – Jun 7, 2026 | 337,386 |
| V6 | Jun 7, 2026 – Jul 12, 2026 | 9,461 |
| V7 | Jul 13, 2026 – Jul 24, 2026 | 855 |
| V8 | Aug 17, 2026 – Aug 21, 2026 | 814 |
| V10 | Aug 21, 2026 – Sep 7, 2026 | 2,603 |
| V11 | Sep 7, 2026 – Sep 10, 2026 | 960 |
| V12 | Sep 20, 2026 – Sep 23, 2026 | 7,280 |
| V14 | Sep 24, 2026 – Sep 28, 2026 | 941 |
| V14 | Sep 29, 2026 – current | in service now |
Releases under 500 messages are omitted. Counts are delivered messages, not generated ones — a message only appears here once a receiving system acknowledged it.
Not another static dataset: a controlled patient story, executed against your environment, with an answer key. The same cohort can be replayed for an EHR migration, an interface-engine cutover, a FHIR API release or a go-live rehearsal.
Generate condition-aware populations with configurable demographics, acuity, diagnoses, labs, medications, edge cases, expected outcomes, and replayable scenario identities.
Turn each patient into a longitudinal story: registration, admission, orders, results, deterioration, intervention, recovery, discharge, and claim.
Transmit through HL7 v2, FHIR R4 REST and Bundles, C-CDA, CSV, JSON, MLLP, HTTP, SFTP, and customer-specific interface profiles.
Check acceptance, patient identity, encounter linkage, critical alerts, idempotency, downstream state, timing, retries, and duplicate handling.
Deliver expected-versus-actual results, request and response hashes, ACK history, throughput, assertion results, and a signed reproducible run manifest.
Each pack combines synthetic patients, executable clinical events, interface traffic, and expected outcomes. Run one scenario, a complete pack, or a hospital-specific validation program.
Prove that registrations, encounters, transfers, discharges, updates, and identity corrections reach the correct chart.
Exercise alerts and clinical escalation across a controlled worsening and recovery trajectory.
Validate orders, specimens, serial results, critical-value handling, amendments, and result-to-patient linkage.
Follow one medication identity from order through dispense, administration, bedside give, change, and discontinuation.
Test the financial journey from coverage and eligibility through charge capture, claim, denial, correction, and remittance.
Deliberately break transport and message sequencing to prove how the environment fails, recovers, and reconciles.
We can configure units, patient mix, facility codes, assigning authorities, MRN format, code systems, custom segments, message timing, target endpoints, expected alerts, and evidence requirements around one real implementation objective.
A single-hospital test tells you an interface works. A network tells you whether it still works when many sites send at once and every message has to land against the right facility. MediFlow runs the whole network as one exercise — and both sides sign off on what will be sent before it is sent.
Each row is emitted and parsed by the engine, and the round trip is asserted in the test suite.
| Standard | What it carries | Direction |
|---|---|---|
| HL7 v2.x | ADT, ORM, ORU, MDM, DFT, SIU, OML, RDE, RDS, VXU, BAR, MFN — 36 message builders, v2.5.1 | send and receive |
| HL7 v2.xml | The same messages in XML encoding, lossless back to pipe-delimited | send and receive |
| FHIR R4 | Patient, Observation, Encounter and related resources | JSON and XML |
| C-CDA | Continuity of Care Document — problems, medications, results, vitals, allergies | produce |
| X12 837P | Professional claim, built from the encounter that produced the charge message | send |
| X12 835 | Remittance advice, including denials with real adjustment reason codes | receive |
| X12 270/271 | Eligibility inquiry and benefit response | both |
| X12 276/277 | Claim status inquiry and response | both |
| X12 278 | Services review — prior authorization request and determination | both |
| TA1 / 999 | Interchange and implementation acknowledgements | both |
| MLLP | The transport a lab analyser actually uses | listen and send |
| SOAP 1.1 | document/literal, generated WSDL, four operations | serve |
What this is not. None of it is a clearinghouse connection — nothing here transmits a claim to a payer. Interchanges are marked as test data in the envelope (ISA15 = T) because MediFlow's patients are synthetic, and a production marker would assert real claims about real people. The institutional claim format (837I) is not implemented: the engine generates professional-fee data, and producing an 837I from it would require revenue codes it does not have. EDI validation is structural — envelopes, counts, control numbers — not full implementation-guide conformance. The C-CDA is well-formed and carries correct template identifiers, but it has not been through a certified C-CDA R2.1 validator and is not claimed to be conformant to the complete guide.
MediFlow scenarios are not just demo data. Each scripted patient declares what your downstream system should conclude — the alerts, the flags, the critical values. Run the scenario, diff your system's actual output against the declared expectations, and a demo becomes a regression test.
A cancellation retried after a dropped acknowledgement. A merge that lands after the update it invalidates. A discharge before the admit. One transposed digit in an MRN.
Both diagonals are failures, in opposite directions. An interface that refuses everything scores perfectly on the top row and catastrophically on the bottom — so the engine reports defence and compatibility as two separate numbers and never averages them into one.
What a correct receiver ought to do is modelled once, as a state machine. Every expected outcome is derived, never hand-asserted, so scenarios do not go stale when a workflow changes.
Ordered sequences that each hunt one bug: cancel and replay, phantom admit, stale merge, out-of-order events, unmerge.
AA/AE/AR and CA/CE/CR scored separately. A commit ACK is not success, a reply with the wrong control ID is quarantined, and no reply is recorded as silent loss.
Twenty-two replayable mutations across structure, identity, encoding and plausibility, plus unusual-but-legal traffic, so rejecting everything never scores well.
STEMI, sepsis cascade, code blue, DKA, stroke and more, on demand, with batch and unattended modes to find queue depth and throughput ceilings.
Stop a listener mid-batch and prove dead-letter capture, replay without duplicates and downstream reconciliation. Idempotency is judged from final state, not from the ACK.
MediFlow delivers to any HL7 v2 or FHIR R4 receiver. It has been run against CareCompile, a VistA FHIR bridge, a WorldVistA EHR and OpenEMR.
Three domain models write the clinical notes, lab interpretations and pathology reports. They run on CareCompile's own hardware; nothing is sent to an outside AI service.
Admission, 15 LOINC-coded lab panels, 11 clinical reports, telemetry and charges for every patient, with an ACK tracked per message per target.
Ten hospital units with live bed state, streaming vital signs, and one-click clinical events such as code blue, sepsis cascade and panic labs.
Eight shift-aware nursing note types sent as MDM^T02, from admission assessment to patient education.
An agent with 24 tools admits patients, fires events and queries the census in plain language.
Continuous admit, lab, event and discharge cycles for pipelines that need a live HL7 source around the clock, with an audit trail.
MediFlow is not sold as a stand-alone product and there is no public sign-in. It is delivered by CareCompile as part of an engagement, scoped to the workflow you need to trust.
A synthetic population and reusable scenarios for one workflow, interface or release.
CareCompile configures MediFlow against one environment, runs controlled scenarios and delivers the evidence.
Scheduled scenario suites and regression runs as your systems change, through CareCompile Cloud.
Access to MediFlow and CareCompile Cloud is by contract only. Tell us what you are validating and we will scope it with you.
What hospital, integration, and clinical AI teams usually ask before a first validation engagement.
Synthetic patient data represents fictional people and clinical events created for development, testing, training, and validation. MediFlow builds complete, coherent patient journeys with known expected outcomes rather than copying a real patient chart.
MediFlow-generated cohorts are constructed without copying production patient records. Synthetic identifiers and provenance markers distinguish test traffic. A customer engagement can be designed to keep generation local and delivery disabled until an approved test destination is configured.
Yes. MediFlow creates HL7 v2 workflows and FHIR R4 resources and Bundles, with additional JSON and CSV exports. Customer profiles control identifiers, facility codes, assigning authorities, code systems, message conventions, and transport.
Common uses include EHR migrations, interface-engine cutovers, lab and pharmacy validation, FHIR API testing, clinical decision-support evaluation, downtime and recovery drills, staff training, regression testing, and go-live rehearsals.
Each scenario is executable and carries an answer key. MediFlow sends the patient journey into the target environment, observes acknowledgements and downstream state, then compares actual behavior with expected clinical and technical outcomes.
MediFlow checks every ICD-10-CM, LOINC, RxNorm and CVX code it emits against the published release before it ships, and the build fails on a code that is not billable, not current, or not a code at all. This matters because code books move: a diagnosis code that was billable last year becomes a category header once it is subdivided, and a test feed carrying it exercises your error path instead of your workflow. A historical immunisation keeps the CVX it was given under, which is correct.
Yes. MediFlow keeps a registry of facilities, each with its own identifier and NPI in the message header, and a patient keeps the same facility for its whole history. Facilities can be switched on, switched off or added while the engine runs, so per-facility routing, coverage and onboarding can be rehearsed one site at a time rather than as one anonymous feed.
A run can include the scenario identity, synthetic cohort manifest, expected-versus-actual assertions, raw request and response hashes, ACK history, timing, throughput, failure details, and a signed reproducible manifest.
MediFlow is a service of CareCompile. There is no public sign-in: access is by contract, delivered through CareCompile and CareCompile Cloud. Tell us the workflow you need to validate and we scope the engagement with you.
Pick a scenario and watch MediFlow build a complete encounter: vitals, AI-authored notes and the 27 HL7 messages of a standard run. Demo mode: nothing is sent from this page.
Tell us what you are testing. Access is by contract through CareCompile; we will scope the synthetic patients, interface profile, expected outcomes, delivery path and evidence with you.
We will reply within one business day. For anything urgent, email hello@carecompile.com.