HIPAA-Compliant Synthetic Test Data

The problem

Healthcare engineering teams need realistic claims to build against and cannot lawfully use the claims they have. The usual workarounds each fail in their own way. De-identified extracts still derive from real patients, so they stay inside the compliance perimeter, still require agreements, and carry documented re-identification risk when combined with outside data. Hand-built fixtures cover the three cases someone thought of and none of the ones that break production. Randomly generated data fails validation immediately: a diagnosis code that does not exist, a date of service before the date of birth, or a provider NPI that fails a checksum will be rejected by the first real system it meets, so the test proves nothing.

The SymageDocs approach

SymageDocs generates coherent synthetic patients and renders their claims onto the real CMS-1500 layout. The medical context is correlated with the rest of the simulated life — insurance status tracks employment, and diagnoses are drawn against the patient's age — so a claim reads as plausible rather than as random codes in valid-looking boxes. Because nothing derives from a real record, the output contains no protected health information. That is the predicate your privacy counsel would evaluate when deciding which agreements, handling controls, and breach-notification duties attach to a dataset; we can state the property of the data, and they decide what follows from it for you.

What you actually get

• Filled CMS-1500 claim forms rendered as typed or handwritten PDF and PNG from the real 212-field layout.
• Patient demographic intake forms, for pipelines whose first step is registration rather than adjudication.
• Coherent patient identities whose insurance status, conditions, and demographics hold together instead of being sampled independently.
• Per-instance annotated JSON and a tabular CSV in every bundle, so expected values are available to assert against.
• Output that carries no PHI by construction: there is no source record to de-identify and no re-identification risk to assess.

How it works

1. 1

   Simulate the patient

   The generator builds a whole fictional person before it builds a claim: demographics, geography anchored to a real ZIP code and its city, employment, household, and a medical context in which insurance status is correlated with employment and diagnosis codes are drawn against the patient's age.

2. 2

   Derive the encounter

   Clinical and billing details are derived from that person rather than drawn at random, which is what keeps a claim internally consistent — the patient on the claim is the same patient the demographics describe.

3. 3

   Render the claim

   The encounter is placed onto the CMS-1500 definition, a single page with 212 distinct fields, and rendered as typed or handwritten PDF or PNG. Handwritten output matters here because real intake and claim forms are frequently completed by hand.

4. 4

   Test against known values

   Every bundle carries per-instance JSON and a tabular CSV describing exactly what was placed on each document, so your extraction or adjudication tests assert against known expected values instead of eyeballing output.

By the numbers

Field and page counts are read from the shipped form definitions in the SymageDocs form library. Library-size figures count every definition the API can generate; the public form reference pages under /forms document a curated subset of them, so that page shows a smaller number. Output-format availability reflects the current API contract; the ML export formats (BIO, YOLO, COCO, Donut) sit behind a feature flag that is not enabled in production, so treat them as a preview rather than a generally available option.

Who this is for

Healthcare AI and revenue-cycle teams building claims intake, extraction, and adjudication pipelines; medical billing platforms that need realistic claims in staging; and compliance-constrained engineering organizations where the obstacle to shipping is not the code but the data-access review in front of it. It is a particularly good fit when developers and their test data sit in different trust zones, since synthetic output can cross that boundary without a review cycle.

Where SymageDocs is not the right tool

Being outside HIPAA's scope is a property of the generated documents, not of your whole system: your application still handles real PHI in production, and that architecture, your access controls, and your audits remain entirely your responsibility. SymageDocs is not a compliance program, does not issue a HIPAA certification (no such certification exists), and this page is not legal advice — if your obligations turn on a specific interpretation, confirm it with your privacy counsel. The library also covers claim and intake forms rather than the full clinical record, so it will not stand in for clinical notes, HL7 or FHIR message streams, or imaging studies.

Relevant forms

Frequently asked questions

Is synthetic data actually exempt from HIPAA?

HIPAA regulates protected health information, which is health information that identifies an individual or could reasonably be used to identify one. SymageDocs output describes simulated people who do not exist and is not derived from any real patient record, so there is no individual to identify and nothing meeting the definition of PHI. What that means for a specific obligation of yours — a business associate agreement, a data-use agreement, an internal review before the data crosses an environment boundary — is a determination for your privacy counsel, not for us; the property of the data is what we can state, and it is the predicate they would be evaluating. Your production systems, which do handle real PHI, remain fully in scope. This is not legal advice.

How is this different from de-identified real data?

De-identification transforms real records, so the source patients still exist and the residual re-identification risk is real and well documented — particularly when a de-identified set is joined against other data. That is why de-identified data typically stays inside the compliance perimeter and still travels with agreements. Generated data has no source record at all, so the risk is not reduced, it is absent. The trade-off is that generated data reflects the modeled distribution rather than your actual patient population.

Will the synthetic claims pass validation in my pipeline?

They are built to be structurally sound rather than random, which is the usual failure mode for fake test data: identifiers follow real structural rules, and clinical and demographic details are derived from a coherent simulated person instead of sampled independently. That said, adjudication rules vary considerably between payers and clearinghouses, so treat a small pilot batch as the way to confirm behavior against your specific validators before you build a suite on it.

Can I generate incomplete or partially filled claims?

Yes. A partial-fill facility lets you specify, per group of fields, whether they arrive already completed, are left blank, or are filled in at a later stage. That is how you produce a realistic intake-stage claim — payer boxes populated, patient sections still empty — rather than only pristine completed forms. Handling incomplete documents gracefully is usually where claims pipelines break, so testing it deliberately is worth the setup.

Do you hold a SOC 2 report or a HIPAA certification?

We do not claim either, and we would rather say so plainly than imply otherwise. There is no such thing as HIPAA certification for a vendor. The argument for synthetic test data does not rest on our certifications: it rests on the output containing no protected health information, which is a property you can verify by inspecting the data rather than a property you have to take on trust from an audit report.

Is the medical detail clinically realistic?

It is correlated rather than random — diagnosis codes are drawn against the patient's age, and insurance status tracks employment — which is what makes the documents useful for exercising extraction and adjudication logic. It is not a clinical simulation, and it should not be used to study disease prevalence, model treatment outcomes, or draw any epidemiological conclusion. The realism target is the document and its structure, not the medicine.

Related use cases