There is a problem in clinical research engineering that almost everyone has and almost no one talks about out loud.
Your staging environment has PHI in it.
Not because someone made a reckless decision. Because the realistic alternative, building and maintaining a synthetic clinical database that actually behaves like production across all your linked tables, has historically been harder than just copying the production database and calling it de-identified.
The result is PHI sprawl: protected health information quietly living in development, staging, QA, CI, vendor sandboxes, and sometimes laptop-local databases because the path to realistic synthetic data was too expensive, too slow, or too fragile to maintain.
This article is a practical guide to eliminating that sprawl without sacrificing the data realism your pipelines depend on.
Why PHI Sprawl Happens in Clinical Engineering Teams
Clinical data is inherently relational and inherently complex. A single patient encounter touches at least six tables in a standard EHR schema: patients, encounters, diagnoses, prescriptions, procedures, and lab results. A realistic pipeline test requires all of those tables to be populated with consistent, linked, temporally ordered data.
The standard approaches most teams fall back on all have critical failure modes.
Faker and Random Generation
Faker fills columns with plausible values in isolation. It does not understand that a patient with a Type 2 diabetes diagnosis should have metformin in their prescription table, an HbA1c in their lab results, and an endocrinology encounter in their encounter history. It fills those tables independently. Your pipeline gets data that passes a null check but fails the moment you run a real query across two tables.
De-identified Production Copies
De-identification sounds rigorous until you look at what it actually produces in most engineering workflows. A column-level de-identification pass replaces names and dates with tokens. The underlying patient relationships, the clinical patterns, the temporal ordering, all of it is still there. Re-identification risk is real. And more practically, that de-identified copy still counts as PHI under HIPAA because de-identification under the Safe Harbor method requires removing 18 specific identifier types, a process most engineering teams are not performing rigorously on every refresh cycle.
The average cost of a healthcare data breach reached $7.42 million in 2025, with 279 days to identify and contain. Every additional environment where PHI lives, including staging environments your team did not intend to classify as PHI-bearing, expands your breach surface and your audit scope.
Handcrafted Seed Files
Manually maintained fixture files solve neither the realism problem nor the compliance problem. They require constant maintenance as schemas evolve, they cover only the happy-path scenarios that someone thought to script, and they frequently contain real patient data that was copied once during initial setup and never reviewed again.
The PHI Sprawl Audit Most Teams Have Never Done
Before looking at solutions, it helps to know the actual scope of the problem on your team.
Run through these questions honestly:
How many non-production environments in your infrastructure contain a copy of clinical data that originated from production, even partially?
When was the last time each of those environments was refreshed, and was a de-identification or masking step applied on that refresh?
Do your vendor partners, QA contractors, or external CRO technical teams have access to any of those environments?
Does your CI pipeline seed its test database from a fixture that was originally derived from production data?
Could you produce a complete data flow diagram showing every system where patient data lives outside of production, and could that diagram survive a HIPAA audit?
Most engineering teams that run this exercise discover they have more PHI sprawl than they thought. The discovery is not a failure of intent. It is a failure of tooling. The tools for generating realistic synthetic clinical databases on demand did not exist at the quality and speed needed, so teams used what worked.
SyntheholDB exists to close that gap.
What a PHI-Free Clinical Engineering Stack Actually Requires
Eliminating PHI sprawl from your engineering environments is not a policy change. It is an infrastructure change. You need a way to generate synthetic clinical databases that are realistic enough that your pipelines, your integration tests, and your staging demos all behave like production.
That requires five specific properties that most synthetic data tools do not deliver together.
Schema-Aware Generation
Your synthetic database must match your actual schema, not a generic clinical schema or a research-oriented data model. Foreign keys must be resolved correctly. Composite unique constraints must be respected. Non-nullable fields must always be populated. SyntheholDB accepts your schema as a SQL DDL file, a JSON schema definition, a CSV import, or a plain-English description and enforces every constraint during generation, not after.
Cross-Table Relational Consistency
Every patient in your patients table must have corresponding records in every linked table at the correct cardinalities. An encounter must exist before a diagnosis linked to that encounter. A prescription must reference a valid encounter and a valid diagnosis code. Lab results must link to valid patients and valid encounter IDs. SyntheholDB enforces this consistency during generation across all tables simultaneously.
Temporal Ordering Across the Full Schema
Clinical data is time-dependent. Diagnosis dates must precede related treatment dates. Treatment dates must precede outcome dates. Admission timestamps must precede discharge timestamps. A deceased patient must not have encounters after their recorded date of death. SyntheholDB enforces temporal ordering across all linked tables in a single generation pass, not table by table.
Domain-Aware Field Correlations
Realistic clinical data is not randomly distributed. Age correlates with comorbidity burden. Diagnosis codes correlate with linked prescription codes. Lab values correlate with diagnosis severity. Encounter frequency correlates with chronic condition management patterns. SyntheholDB uses domain-specific statistical models to reproduce these correlations at any population scale.
Reproducibility From a Documented Seed
When a bug appears in staging that you cannot reproduce locally, the problem is almost always that the two environments were generated differently. SyntheholDB generates reproducible databases from a documented schema and seed. The same inputs produce the same database on every run, in every environment.
How to Migrate One Service Off PHI Today
You do not need to migrate your entire stack to eliminate PHI sprawl. Start with one service.
The best candidate is the service with the highest PHI exposure risk: the one whose staging environment was last refreshed from production most recently, or the one that handles the most sensitive clinical tables.
Step 1: Export or define the schema
Export your service schema as a SQL DDL file or describe your core entities in plain English inside SyntheholDB. The generation pipeline builds a complete schema definition from your input and surfaces only genuine ambiguities before generation begins.
Step 2: Generate a synthetic database
Configure the population size you need: a few thousand records for unit tests, tens of thousands for integration tests, hundreds of thousands for performance and staging environments. Generate. Review the fidelity score, the privacy label report, and the referential integrity report that ship with every generation before the export reaches your environment.
Step 3: Wire your service to the synthetic database
Replace your staging database connection string with a connection to the generated synthetic database. Run your full test suite. Run your integration tests. Run your staging demo workflows. Measure how many test failures the realistic data surfaces that your previous fixtures did not.
Step 4: Add generation to your CI pipeline
On Pro and above, the SyntheholDB API supports deterministic generation with a documented seed. Add a generation step to your CI pipeline that rebuilds the synthetic database from a pinned schema and seed on every run. Every pipeline run gets a fresh, consistent, realistic database with no stale fixtures and no fixture drift.
Step 5: Decommission the PHI-bearing environment
Once your service runs correctly against the synthetic database in staging and CI, the PHI-bearing copy of that environment can be decommissioned. Document the decommission for your audit trail. That documentation is now complete and defensible.
OMOP CDM Teams: What This Changes for Your Workflow
If your team works with OMOP CDM schemas, SyntheholDB generates synthetic databases that conform to your OMOP CDM design directly. You define the CDM version, specify your target tables, and the generation engine produces a populated, relationally consistent OMOP dataset without any production data involvement.
This changes three specific parts of the OMOP engineering workflow.
ETL pipeline development no longer requires a copy of source data. You generate a synthetic source dataset in your source schema, run your ETL, and validate the output against a synthetic OMOP target. The full pipeline is developed and tested without production data at any stage.
ATLAS and OHDSI tool integration testing gets a realistic dataset to run against. Cohort definitions, patient-level prediction studies, and incidence rate calculations all behave correctly against a synthetic OMOP database generated at the right population size and distribution.
Federated network study preparation becomes simpler. When you need to test a study package against a local CDM before a network run, you generate a synthetic CDM that matches your institution schema and test against that. No production data leaves your systems during development.
The Compliance Posture This Creates
Every SyntheholDB generation produces three artifacts alongside the database export.
A fidelity score documenting the statistical similarity between the generated database and the input schema distributions.
A privacy label report scanning every field in every table for sensitive-shaped values and flagging them before export.
A referential integrity report confirming that every foreign key, every composite unique key, and every temporal constraint holds across the full generated database.
These three artifacts answer a HIPAA audit, a SOC 2 review, or an enterprise customer security questionnaire when they ask how your non-production environments are governed. SyntheholDB is SOC 2 Type II certified, ISO 27001 certified, HIPAA compliant, and GDPR compliant. Enterprise deployments run fully on-premises with no external network calls in the generation or validation path.
What This Looks Like Six Months From Now
A team that migrates its clinical staging and CI environments to SyntheholDB-generated synthetic databases over the next six months ends up in a measurably different position.
PHI no longer lives outside production. Every environment that used to require a de-identification step or a compliance exception now runs on data that was never real. The audit answer is simple and complete: non-production environments contain no patient data because they were never seeded with patient data.
Test coverage improves. Synthetic databases generated with domain-aware correlations and edge case coverage surface bugs that fixture-based environments never reached.
Environment provisioning time drops to under 60 seconds. A developer who needs a realistic clinical database for a new feature branch gets one immediately, not after a three-day provisioning request.
Vendor and contractor onboarding becomes frictionless. Handing a CRO partner or a QA contractor a synthetic database requires no legal review, no data transfer agreement, and no compliance exception.
Try It Free
SyntheholDB is free to start. No credit card required. Your first synthetic clinical database is ready in under 60 seconds.
Sign up here: https://db.synthehol.ai/#/login
If you try it on a clinical schema, especially an OMOP CDM schema or a FHIR-mapped schema, drop a comment below and share what you found. What did the realistic data surface that your previous fixtures did not? What did you remove from your fixture maintenance backlog?
The answers from this community shape what gets built into the platform next.
Top comments (0)