Synthetic Patient Demographic Form (New Patient Registration) Data
Synthetic training data — no real PII, fully coherent identities
Generate synthetic new-patient registration and demographic forms — one dense page carrying three Social Security numbers, two insurance blocks and 38 checkboxes in mutually exclusive groups. Training data for healthcare intake automation and RCM front-end capture.
104
Fields per document
1
Page
Healthcare
Category
What this document is
The new-patient registration form, sometimes called the patient demographic sheet, is what every practice hands a patient on their first visit: identity and contact details, guarantor, emergency contact, referral source, primary care and referring physician, primary and secondary insurance with subscriber details, and signatures. Everything downstream in the revenue cycle — eligibility check, claim, statement, collections — is built on what gets keyed off this page.
Why generate synthetically
This is the most sensitive single page in an ambulatory practice. One sheet carries the patient's Social Security number, date of birth, home address, employer, religion, ethnicity, insurance member identifiers and, frequently, a second person's Social Security number as subscriber. There is no HIPAA-compliant path to a shareable corpus of these, which is why intake-capture accuracy is usually measured on a few dozen internal scans. Synthetic registrations lift that ceiling without touching protected health information at any point.
What makes synthetic data useful
Each generated form is one coherent simulated household: the guarantor is the patient on 63% of forms and a related party on the rest, with the relationship, address and date of birth all consistent with that choice; the insurance subscriber is self on 70%, spouse on 16% and child on 9%, with subscriber identity matching. Secondary coverage appears on 31.5% of registrations, which is the coordination-of-benefits case most intake software handles worst. Marital status, ethnicity, referral source and payer are drawn from realistic distributions rather than uniformly.
Training challenges
38 checkbox targets on a single page, organised into roughly ten mutually exclusive groups — gender, marital status, phone preference for three different parties, referral source, insurance relationship for two policies, subscriber sex — means the page is dominated by an exactly-one-of-N constraint that value-level extraction metrics do not measure. A model that returns both Married and Single scores as two-thirds correct on the fields and is unusable in production. Layered on top: whole blocks appear conditionally, so the secondary insurance block is absent on 68.5% of forms and a separate guarantor block on 63%, and an extractor that has learned the block's position will populate it from whatever text is nearby.
Generate synthetic Patient Demographic Form (New Patient Registration) data
Start with 500 free credits. No credit card required.
Generate NowWho uses this data
Healthcare revenue-cycle vendors automating front-end registration capture, patient-intake and digital check-in platforms, EHR and practice-management integrators building document import, and eligibility-verification services that parse a scanned intake sheet before running a payer check. Also the reference document for teams testing PHI redaction, since one page contains nearly every category of identifier at once.
Document complexity profile
104 fields packed onto a single page: 60 text, 38 checkbox targets, 3 Social Security number fields, 1 date and 2 signature regions, joined by 92 annotation relations. The checkbox targets resolve into roughly ten mutually exclusive groups, and several whole blocks — separate guarantor, secondary insurance — appear conditionally, so the page's effective structure differs from document to document.
Key stats from our synthetic corpus
Quantitative characteristics of the Patient Demographic Form (New Patient Registration) documents our generator produces.
| Metric | Value | Detail |
|---|---|---|
| Social Security numbers per page | 3 | Patient, primary subscriber and secondary subscriber each have an SSN field. Three identifiers of the same type on one page is a genuine test for redaction and for entity linking — an extractor must attach each number to the right person, not just find nine digits. |
| Forms with secondary coverage | 31.5% | 31.5% of registrations carry a second insurance policy, triggering the coordination-of-benefits path. The other 68.5% leave the whole block empty, which is where extractors most often invent a policy that does not exist. |
| Patient is the guarantor | 63% | On 63.1% of forms the patient is their own guarantor and the relationship reads Self; the remaining 36.9% name a parent, guardian, spouse, child, sibling or friend, and only those forms carry a second signature. Conditional signature presence is a common false-positive source for signature detection. |
| Checkbox targets | 38 | 38 checkbox targets across roughly ten mutually exclusive groups. Group-level scoring is the metric that matters: returning two marks in one group is a hard failure that per-field accuracy reports as a near miss. |
| Referral source spread | 6 options | Referral source is friend 38%, website 25.4%, physician 19.3%, other 7.4%, radio or TV 5.3% and newspaper 4.6%, with a free-text box that only fills on the 7.4% marked Other. Low-prevalence conditional text alongside a checkbox is exactly the pattern that trips rule-based extraction. |
How this document co-occurs with others
Rates at which identities in our corpus that produce a Patient Demographic Form (New Patient Registration) also produce other documents.
| Correlation | Rate | Detail |
|---|---|---|
| Claim generated from this intake | 100% | Every registered patient's encounter produces a CMS-1500 professional claim carrying the same demographic and insurance details. Registration plus claim is the pairing that tests whether intake data survives into billing intact. |
| Patient statement for the same encounter | 100% | The itemized superbill restates the patient, payer and account identifiers captured here. Three documents from one encounter — intake, claim, statement — is the realistic unit of work for revenue-cycle automation. |
| Employer coverage behind the policy | 64% | 64% of patients are employed and elected the coverage listed here through an employer benefits enrollment. Tying a member ID on an intake form to the election that created it is the eligibility question payers actually get asked. |
| Benefits-side income verification | 100% | The same households appear in public-benefits income verification. Practices that serve Medicaid populations process both documents for the same patient, in the same week, with the same identifiers. |
Prevalence rates and category distributions above are corpus-derived: they were computed over all 1,000 identities in a local synthetic corpus generated by SymageDocs' World Simulation Engine at seed 20260421 — every identity is eligible for this form, so no sub-sampling applies. Field, type and relation counts, the checkbox grouping and the never-marked boxes come from the shipped patient registration definition in the SymageDocs form library. No real patient or protected health information was used at any stage.
Frequently asked questions
- What data format do synthetic patient registration documents include?
- Each generated identity produces a rendered PDF plus a structured JSON annotation file with bounding boxes, field types, and ground-truth values for all 104 fields, plus 92 label-to-value relations. Fields are typed — text, checkbox, Social Security number, date and signature — so type errors can be scored separately from value errors. COCO, YOLO, FUNSD, and BIO/NER exports come from the same job.
- Is this real patient data?
- No, and it cannot be. Every patient, guarantor, subscriber, physician, employer, payer identifier and Social Security number on these forms is generated by a simulation of people who do not exist. There is no protected health information in the corpus, which is what makes it distributable at all.
- How are the checkbox groups structured?
- As mutually exclusive sets, the way the paper form intends. Exactly one gender box, one marital status, one insurance relationship per policy. Ground truth records which box in each group is marked, so you can score group-level correctness rather than per-box accuracy — the metric that actually predicts whether intake data lands clean.
- Are any of the checkboxes never used?
- Yes, and it is worth knowing before you train. The 'not applicable — child' marital status box and all three guarantor phone-preference boxes are annotated but never marked in the current corpus. Four of the 38 targets therefore supply only negatives, so do not expect the corpus to teach a detector what those particular boxes look like when filled.
- Can I use this data commercially?
- Yes. Every identity, identifier and insurance detail is synthetic, contains no real patient data, and is licensed for commercial use including model training, benchmarking, and redistribution inside your own products.