Healthcare Test Data: A Field Set and Sample Schema for EHR and Claims Systems
A healthcare test dataset that exercises an EHR or claims integration needs FHIR-structured records, codes that belong to ICD-10-CM, CPT, and LOINC, and providers with valid NPI numbers. This page names the 15 required fields, maps fixture fields that carry Safe Harbor letters (B, C, H, R) in the field table and enumerates A to R in a separate table, shows a 3-table patient/encounter/observation schema, and lists 5 test scenarios.
Field set (15) for EHR and claims systems
Include patient demographics, NPI test identifiers, ICD-10 diagnosis codes, and FHIR-oriented resource shapes as synthetic fixtures. Use only synthetic identifiers; do not copy real clinical records.
| # | Field | Cardinality | Binding / membership | Safe Harbor |
|---|---|---|---|---|
| 1 | patient_id | 1..1 | FHIR Patient.id | R |
| 2 | patient_identifier | 0..* | Identifier | - |
| 3 | mrn | 0..1 | facility-local unique | H |
| 4 | birth_date | 0..1 | YYYY-MM-DD | C |
| 5 | postal_code | 0..1 | 5-digit or 3-digit prefix | B |
| 6 | npi | 0..1 | 10 digits; CMS Luhn+24 | R |
| 7 | encounter_id | 1..1 | FHIR Encounter.id | - |
| 8 | encounter_status | 1..1 | required binding | - |
| 9 | encounter_class | 0..* | preferred binding | - |
| 10 | encounter_subject | 0..1 | Reference(Patient|Group) | - |
| 11 | actual_period | 0..1 | Encounter.actualPeriod | - |
| 12 | diagnosis_code_icd10cm | 0..* | ICD-10-CM membership | - |
| 13 | procedure_code_cpt | 0..* | CPT 5-char membership | - |
| 14 | observation_code_loinc | 0..* | LOINC + mod-10 check | - |
| 15 | observation_value / effective / range | 0..1 | Quantity / dateTime / range | - |
HIPAA Safe Harbor identifier enumeration (A to R)
Definitional / testing context only; not legal advice. HHS Safe Harbor enumerates identifiers (A) through (R) that must be removed for de-identification of real records (hhs.gov de-identification guidance, retrieved 2026-08-01). Synthetic rows are generated, not derived from PHI. Generate-Data makes no HIPAA compliance guarantee.
| Letter | Identifier | Fixture mapping |
|---|---|---|
| A | Names | family_name / given_name (synthetic) |
| B | Geographic subdivisions smaller than a state | postal_code_3 (3-digit ZIP prefix) |
| C | Elements of dates except year; ages over 89 | birth_date (illustrative) |
| D | Telephone numbers | not in this fixture |
| E | Fax numbers | not in this fixture |
| F | Email addresses | not in this fixture |
| G | Social security numbers | not in this fixture |
| H | Medical record numbers | mrn |
| I | Health plan beneficiary numbers | not in this fixture |
| J | Account numbers | not in this fixture |
| K | Certificate / license numbers | not in this fixture |
| L | Vehicle identifiers | not in this fixture |
| M | Device identifiers | not in this fixture |
| N | URLs | not in this fixture |
| O | IP addresses | not in this fixture |
| P | Biometric identifiers | not in this fixture |
| Q | Full-face photographs | not in this fixture |
| R | Any other unique identifying number / code | patient_id, npi (synthetic shapes) |
Compliance framing
Sample schema: patient, encounter, observation
Model patient as parent, encounter as child, and observation referencing encounter. Include an NPI column that is obviously synthetic. Keep referential integrity so claims cannot point at missing encounters.
patient
| patient_id | mrn | family_name | given_name | birth_date | postal_code_3 |
|---|---|---|---|---|---|
| pat-0001 | MRN-SYN-000001 | Synthfield | Avery | 1979-03-14 | 021 |
| pat-0002 | MRN-SYN-000002 | Testworthy | Brin | 1962-11-02 | 606 |
| pat-0003 | MRN-SYN-000003 | Nullington | Cass | 1994-07-25 | 941 |
encounter
NPI 1234567893 is CMS's own worked Luhn+24 example (illustrative). ICD-10-CM and CPT values are structural examples from cited CMS/CPT pages, not clinical guidance.
| encounter_id | subject_patient_id | status | class_code | attending_npi | diagnosis_icd10cm | procedure_cpt |
|---|---|---|---|---|---|---|
| enc-1001 | pat-0001 | completed | outpatient | 1234567893 | R10.13 | 99213 |
| enc-1002 | pat-0002 | in-progress | inpatient | 9876543213 | S32.010A | 0042T |
| enc-1003 | pat-0003 | discharged | inpatient | 1111111112 | M1A.0111 | 1018F |
| enc-1004 | pat-0001 | cancelled | outpatient | 2000000002 | O9A.211 | 0123T |
observation
| observation_id | encounter_id | code_loinc | value_quantity | unit | ref_low | ref_high |
|---|---|---|---|---|---|---|
| obs-5001 | enc-1001 | 2951-2 | 139 | mmol/L | 135 | 145 |
| obs-5002 | enc-1002 | 17863-2 | 1.18 | mmol/L | 1.1 | 1.35 |
| obs-5003 | enc-1003 | 806-0 | 3 | /uL | 0 | 5 |
Code-system membership and NPI shape checks
Test scenarios
- Claim adjudication: ICD-10-CM coded below required specificity must reject.
- Placeholder-character validation: T36 to T50 poisoning code missing X placeholder must fail.
- NPI check-digit rejection at enrollment (feed a failing Luhn+24 shape).
- Encounter state machine: illegal status transitions refused; cancelled/entered-in-error excluded from billing extracts.
- Reference-range boundaries: observations at low/high and low-only range without null dereference.
Generate a larger version
Frequently asked questions
Can synthetic data completely eliminate HIPAA compliance requirements?
No. Invene's guide states that synthetic data "reduces HIPAA exposure significantly but doesn't eliminate all compliance considerations" ([invene.com/blog/synthetic-data-healthcare](https://www.invene.com/blog/synthetic-data-healthcare), retrieval date 2026-08-01). The HHS de-identification guidance addresses real records that contain protected health information; a generated record that was never derived from real patient data is not de-identified in that sense, because there was no real PHI to remove. That said, the workflow, environment, access controls, and audit trails around synthetic data still carry their own obligations, especially when a synthetic dataset is generated from real records as a seed. Generate-Data makes no HIPAA compliance guarantee. This is a general industry framing based on cited sources.
How do leading healthcare organizations validate synthetic data quality?
Invene's guide covers validation approaches that include checking code-system membership (ICD-10-CM specificity level, CPT category), referential integrity (encounter rows that reference valid patient identifiers), and clinical plausibility (LOINC observation values within reference range) ([invene.com/blog/synthetic-data-healthcare](https://www.invene.com/blog/synthetic-data-healthcare), retrieval date 2026-08-01). Synthea, which generates "high-quality, synthetic, realistic but not real, patient data," uses a population simulator that constrains outputs to plausible clinical trajectories ([synthetichealth.github.io/synthea](https://synthetichealth.github.io/synthea/), retrieval date 2026-08-01). For schema-level validation, the field set on this page names the specific membership rules and cardinalities a test harness should assert.
When should we avoid using synthetic data entirely?
Invene's guide names cases where synthetic data is insufficient: where the real statistical distribution is required for a clinical trial, where a vendor explicitly requires real production records for support, or where the system under test validates data against a live patient index ([invene.com/blog/synthetic-data-healthcare](https://www.invene.com/blog/synthetic-data-healthcare), retrieval date 2026-08-01). Synthetic data is also a poor fit when the test specifically needs to exercise de-identification tooling on real PHI, because there is no real PHI present. These limits are stated as general industry framing from the cited source, not as legal advice.