Synthetic-only output
Generated HL7 messages include an NTE note and generated FHIR resources include a meta tag to make the synthetic/test nature clear.
Synthetic healthcare integration data
HL7/FHIR Test Data Generator
Generate fictional ADT, ORU, ORM, SIU, FHIR Patient, Encounter, Observation, DiagnosticReport, and Bundle examples for interface testing, demos, QA, and documentation. Processing runs in your browser and no login is required.
Generator
Choose a message type
Pick a scenario, region flavour, and output format. Then generate a fresh synthetic sample.
Click Generate to create a synthetic HL7 or FHIR sample.
Explanation will update when a sample is generated.
Trust and validation
Useful examples, not certified validation
Sample-oriented
The examples are designed for demos, interface testing, QA scripts, and documentation. They are not a clinical record or a medical-device workflow.
No conformance claim
The generator creates realistic examples, but it does not yet validate against local implementation guides, FHIR profiles, or site-specific HL7 specifications.
What this is for
This tool is for interface analysts, integration developers, QA testers, and healthcare software teams who need sample data for testing and documentation.
What this is not for
This is not a clinical system, medical device, patient record system, or compliance validator. It creates synthetic examples only.
Current scope
This version focuses on quick synthetic sample generation, readable output, regional test-data flavours, and direct links to individual generator scenarios. The output remains sample-oriented and should be adapted to each receiving system's specification.
FAQ
Common questions
Does this generate real patient data?
No. The names, identifiers, addresses, results, and visit details are fictional synthetic examples for testing, demos, QA, and documentation.
Can I paste real patient data into the tool?
No. The site is intended for synthetic generation only. Do not enter real patient data, production identifiers, secrets, credentials, or confidential values.
Is this a validator?
No. The output is designed to be realistic and useful, but it is not a certified HL7/FHIR validator and does not claim conformance with local implementation guides or site-specific interface specs.
Can I link directly to a generator scenario?
Yes. Add a supported ?scenario=... value to the generator URL, such as ?scenario=hl7-adt-a01 or ?scenario=fhir-bundle.
Practical guide
Build useful test payloads without copying production records
The generator is designed for early interface development, mapping workshops, demonstrations, regression tests, and documentation. It creates a fresh fictional payload each time, but the generated result still needs to be adapted to the message profile, implementation guide, and business rules of the receiving system.
Recommended workflow
- Select the event or FHIR resource that is closest to the workflow being tested.
- Choose a regional flavour to produce familiar fictional names, addresses, and facility values.
- Generate one sample first and confirm the receiving parser accepts the basic structure.
- Adapt identifiers, codes, optional fields, and local Z-segments or profile elements to match the interface specification.
- Generate several samples only after the route, parser, and acknowledgement behaviour are stable.
Direct scenario links
A scenario can be preselected through the URL. This is useful in test instructions, tickets, and mapping documents because it opens the shared generator with the intended message type already selected.
https://health-data-tools.com/hl7-fhir-test-data/?scenario=hl7-adt-a01
https://health-data-tools.com/hl7-fhir-test-data/?scenario=fhir-bundle
https://health-data-tools.com/hl7-fhir-test-data/?scenario=hl7-oru-r01®ion=au&count=3Supported URL values are deliberately limited to options displayed by the form. Invalid scenario, region, or count values are ignored or constrained rather than executed as arbitrary input.
Reading the output
Understand what the sample represents
HL7 v2 samples
HL7 messages use carriage-return segment boundaries and the encoding characters declared by MSH. The event type determines the main structure: ADT samples focus on patient and visit data, ORM samples on orders, ORU samples on results, and SIU samples on appointments.
- MSH identifies the sending application, receiver, timestamp, message type, control ID, processing mode, and version.
- PID carries fictional identifiers and demographics.
- PV1 supplies visit class, location, doctors, and visit number when the scenario is encounter-related.
- ORC, OBR, and OBX represent order and result context where relevant.
- NTE explicitly marks the message as synthetic test data.
FHIR samples
FHIR output is valid JSON shaped like common R4 resources. A Patient contains demographics, an Encounter provides visit context, an Observation represents a result, and a DiagnosticReport groups report-level information. Bundle output links several fictional resources together for simple end-to-end tests.
- Check each
resourceTypebefore using the sample. - Keep resource IDs and references consistent when editing a Bundle.
- Replace example identifiers and coding systems with those required by the receiving profile.
- Do not assume a structurally plausible resource satisfies a national or vendor-specific profile.
Common pitfalls
What the generator deliberately does not decide for you
Local implementation differences
Hospitals and vendors frequently constrain optional fields, identifier repetitions, code systems, date precision, acknowledgement modes, and custom segments differently. A sample can be syntactically useful and still fail a local conformance rule.
Use the generated payload as a safe starting point, then compare it field-by-field with the receiving specification and a known-good synthetic test message.
Privacy and limitations
- Never replace the fictional values with real patient data in a public browser tool.
- The generator does not contact a terminology server, FHIR validator, or destination interface.
- It does not guarantee referential, vocabulary, profile, or workflow conformance.
- “Messy” mode is intended to exercise parsers, not to model every real-world data-quality problem.
Authorship and review
Practical guidance backed by integration experience
Maintained and technically reviewed by Health Data Tools, drawing on more than 15 years of healthcare integration experience across HL7, FHIR, CDA, APIs, PKI, and clinical integration systems.
Technically reviewed:
Official references
Standards and further reading
These references support the technical context. Local implementation guides, vendor profiles, and receiving-system rules still take precedence for a specific interface.