Are the Healthcare & Life Sciences records on this page real?

No. Every record on this page is synthetic, generated from a fixed seed by the pack's own generator; masked values come from the real masking engine. The masking example uses a fixed public sample key; your own data is masked with a key from your secret store.

How long does a first certified Healthcare & Life Sciences dataset take?

Estimates, not guarantees — try the synthetic sandbox: minutes; install (or reuse) the agent: under an hour; connect a source: under an hour; review and approve policies: under an hour; first certified dataset: minutes.

Which test scenarios does the Healthcare & Life Sciences pack include?

10 runnable scenarios (routine care, claim denials, coordination of benefits, chronic care and more), plus 2 negative-test scenario kept apart from valid data.

Do Healthcare & Life Sciences rows leave my network?

No. The DataNivra agent runs inside your environment: it reads the source, masks, subsets, generates and certifies there, and sends only metadata, aggregate counts and evidence to the DataNivra control plane (customer-resident processing, zero raw-production-data egress).

Industry packs

Healthcare & Life Sciences industry pack

Realistic member, encounter and claim test data, with PHI kept in your network.

Synthetic payer, provider, pharmacy, clinical and research domains with PHI-aware templates

Fully self-service (journey proven end to end) Version 2.1.0 · Available in paid plans

The full Healthcare & Life Sciences 2.1.0 journey — from the public pack page through the synthetic sandbox, signup, activation, agent and source setup, scenario, masking and subsetting, certification and provisioning to evidence export — was verified end to end on a local real-component stack (the real control plane, agent, engine, sandbox runner, website and console built from source, with synthetic data) on 2026-10-09. Published agents 0.4.4, 0.4.3, 0.4.2, 0.4.1 and 0.4.0 run this pack version.

Try with synthetic data Activate this pack — start free

No call and no credit card needed. Prefer a conversation? Request a demo (optional). Missing something? Request a feature.

Included in Free Trial, Developer, Team, Business, Enterprise and Private Cloud / Self-Hosted. You can activate it for your organization yourself in the console; no call is needed.

Problems this pack solves

Masked data that still joins across 6 systems

11 cross-system relationships link claims, clinical, enrollment, pharmacy, provider_directory and research; the pack's masking keeps one pseudonym per identity on every side. For example, enrollment.members.member_id and claims.claims.member_ref get the same pseudonym.

The cases production samples rarely contain

7 ready-made scenarios generate them on demand, for example: denied claims with synthetic denial reasons and zero paid amounts; members with primary and secondary coverage (coordination of benefits); critical and boundary laboratory values (HH/LL flags, values far outside reference ranges).

Sensitive fields found and masked before anyone sees them

46 columns across 15 entities are classified (direct identifier, PHI, PII, quasi identifier and sensitive) and covered by 3 masking templates you review and approve.

Evidence that each dataset is fit to use

3 certification presets check masking coverage, referential integrity, orphans and row counts before a dataset can be provisioned; a failed dataset is never provisioned.

Entities and relationships

15 entities across 6 source systems, generated from the pack’s own entity model.

Arrows point from the referencing entity to the one it references. Solid: a foreign key inside one system. Dashed: a cross-system relationship — the pack keeps the same pseudonym on both sides, so masked data still joins.

All 20 relationships as a table

Relationships of the Healthcare & Life Sciences pack
Entity	References	Columns	Kind
Demographics	Member	`member_id` → `member_id`	Within a system
Coverage	Member	`member_id` → `member_id`	Within a system
Coverage	Plan	`plan_id` → `plan_id`	Within a system
ClaimLine	Claim	`claim_id` → `claim_id`	Within a system
Diagnosis	Claim	`claim_id` → `claim_id`	Within a system
Procedure	ClaimLine	`claim_line_id` → `claim_line_id`	Within a system
Prescription	Pharmacy	`pharmacy_id` → `pharmacy_id`	Within a system
LabResult	Encounter	`encounter_id` → `encounter_id`	Within a system
ResearchSubject	Trial	`trial_id` → `trial_id`	Within a system
Claim	Member	`member_ref` → `member_id`	Across systems (pack relationship template)
Claim	Coverage	`coverage_ref` → `coverage_id`	Across systems (pack relationship template)
Claim	Provider	`billing_provider_ref` → `provider_id`	Across systems (pack relationship template)
ClaimLine	Member	`member_ref` → `member_id`	Across systems (pack relationship template)
ClaimLine	Provider	`rendering_provider_ref` → `provider_id`	Across systems (pack relationship template)
Prescription	Member	`member_ref` → `member_id`	Across systems (pack relationship template)
Prescription	Provider	`prescriber_ref` → `provider_id`	Across systems (pack relationship template)
Encounter	Member	`member_ref` → `member_id`	Across systems (pack relationship template)
Encounter	Provider	`provider_ref` → `provider_id`	Across systems (pack relationship template)
LabResult	Member	`member_ref` → `member_id`	Across systems (pack relationship template)
ResearchSubject	Member	`member_ref` → `member_id`	Across systems (pack relationship template)

Realistic synthetic records

Synthetic data. Every record on this page is synthetic, generated from a fixed seed by the pack's own generator; masked values come from the real masking engine.

Entity

Member — `enrollment.members` (synthetic)
`member_id` sensitive	`subscriber_id` sensitive	`medical_record_number` sensitive	`first_name` sensitive	`last_name` sensitive	`birth_date` sensitive	`email` sensitive	`phone` sensitive	`relationship_code`	`enrolled_on` sensitive
MBR00000001	MBR00000001	MRN-ZZ-0000001	Xanara	Wrencombe	1954-07-27	xanara.yarrshaw708@example.org	555-008-3507	SELF	2022-07-17
MBR00000002	MBR00000002	MRN-ZZ-0000002	Nerel	Zephridge	1986-08-11	nerel.quarrcombe1479@example.com	555-079-1814	SELF	2020-02-23

Masking: before and after

Template Healthcare linked test data (HC_LINKED_TEST_DATA) applied to a synthetic Member record from enrollment.members.

Synthetic record

Synthetic Member record before and after masking
Column	Classified as	Before (synthetic)	After masking
`member_id`	Direct identifier, PHI	`MBR00000001`	`MBR98977906`
`subscriber_id`	Direct identifier, PHI	`MBR00000001`	`gs5icabssszyzoap4gcg`
`medical_record_number`	Direct identifier, PHI	`MRN-ZZ-0000001`	`trl3bywkdfsaybrxqzpy`
`first_name`	PII, Direct identifier, PHI	`Xanara`	`Eleth`
`last_name`	PII, Direct identifier, PHI	`Wrencombe`	`Rookholt`
`birth_date`	Quasi identifier, PHI	`1954-07-27`	`1954-06-22`
`email`	PII, Direct identifier, PHI	`xanara.yarrshaw708@example.org`	`iris.kestmere3112@example.com`
`phone`	PII, Direct identifier, PHI	`555-008-3507`	`555-060-1376`
`enrolled_on`	Quasi identifier, PHI	`2022-07-17`	`2022-06-12`

Same pseudonym in two systems. The identifier MBR00000001 appears in enrollment.members.member_id and in claims.claims.member_ref. Both become MBR98977906, so the masked systems still join (relationship HC_CLAIM_MEMBER).

Masked with a fixed public sample key so this example is reproducible; your data is masked with your own key, referenced from your secret store.

Synthetic scenarios you can run

10 runnable scenarios. Run any of them in the hosted synthetic sandbox, or preview them in your browser without an account.

Routine care

Normal HC_ROUTINE_CARE

Everyday members with office visits, paid claims, fills and normal labs

Everyday, valid records: the baseline most tests expect. Children per parent record: 0–3.

Run in sandbox: Routine care Preview in the browser demo: Routine care

Claim denials

Rare HC_CLAIM_DENIALS

Denied claims with synthetic denial reasons and zero paid amounts

Valid but uncommon business situations that production samples often miss. Children per parent record: 1–3.

Run in sandbox: Claim denials Preview in the browser demo: Claim denials

Coordination of benefits

Rare HC_COORDINATION_OF_BENEFITS

Members with primary and secondary coverage (coordination of benefits)

Valid but uncommon business situations that production samples often miss. Children per parent record: 2–3.

Run in sandbox: Coordination of benefits Preview in the browser demo: Coordination of benefits

Chronic care

High volume HC_CHRONIC_CARE

Chronic-condition members with many encounters, claims and refills

Many children per entity (load, pagination and performance paths). Children per parent record: 3–6.

Run in sandbox: Chronic care Preview in the browser demo: Chronic care

Pharmacy refills

Normal HC_PHARMACY_REFILLS

Maintenance medication refills (refill numbers 1-5, 30/90-day supplies)

Everyday, valid records: the baseline most tests expect. Children per parent record: 0–3.

Run in sandbox: Pharmacy refills Preview in the browser demo: Pharmacy refills

Abnormal labs

Boundary HC_ABNORMAL_LABS

Critical and boundary laboratory values (HH/LL flags, values far outside reference ranges)

Values at the edges of valid ranges (limits, thresholds, extremes). Children per parent record: 1–3.

Run in sandbox: Abnormal labs Preview in the browser demo: Abnormal labs

Eligibility gaps

Rare HC_ELIGIBILITY_GAPS

Terminated coverages (eligibility gaps) and claims pended for eligibility review

Valid but uncommon business situations that production samples often miss. Children per parent record: 0–3.

Run in sandbox: Eligibility gaps Preview in the browser demo: Eligibility gaps

Denial resubmission

Rare HC_DENIAL_RESUBMISSION

Denied claims and their corrected resubmissions: the same member, service dates and billed amount, resubmitted 30-59 days after service and paid as ADJUSTED claims; one resubmission in five is denied again

Valid but uncommon business situations that production samples often miss. Children per parent record: 2.

Run in sandbox: Denial resubmission Preview in the browser demo: Denial resubmission

Coverage changes

Rare HC_COVERAGE_CHANGES

Members whose coverage changes mid-year: a terminated period from 1 January and a new active period starting the next day, or after a one-month lapse for one member in four

Valid but uncommon business situations that production samples often miss. Children per parent record: 2.

Run in sandbox: Coverage changes Preview in the browser demo: Coverage changes

Historical claims

Historical HC_HISTORICAL_CLAIMS

Claims history from past decades (archive and migration testing)

Old records for archive, migration and retention tests. Children per parent record: 0–3.

Run in sandbox: Historical claims Preview in the browser demo: Historical claims

Negative tests, kept apart. These scenarios produce deliberately broken data for error handling and never passes certification as valid data:

HC_ORPHAN_CLAIMS — Claims, fills and labs referencing members or providers that do not exist (negative tests)
HC_INVALID_CLAIMS — Business-invalid values (negative amounts, malformed codes) for validation testing

Sample schemas and representative outputs

The schema the pack expects in each system (also as CREATE TABLE DDL in the downloads). A run produces a masked or synthetic dataset with the same tables, a certification report with the gates of the chosen preset, and an evidence manifest with checksums — the rows stay in your environment.

Plan — enrollment.plans · 4 columns

A health benefit plan offered by the payer (reference data, no personal data).

Column	Type	Required	Sensitive classes
`plan_id` (key)	`VARCHAR(12)`	Yes	—
`plan_name`	`VARCHAR(64)`	Yes	—
`plan_type`	`VARCHAR(8)`	Yes	—
`line_of_business`	`VARCHAR(24)`	Yes	—

Member — enrollment.members · 10 columns

A person covered by a plan (the patient in clinical systems).

Column	Type	Required	Sensitive classes
`member_id` (key)	`VARCHAR(16)`	Yes	Direct identifier, PHI
`subscriber_id`	`VARCHAR(16)`	Yes	Direct identifier, PHI
`medical_record_number`	`VARCHAR(20)`	Yes	Direct identifier, PHI
`first_name`	`VARCHAR(64)`	Yes	PII, Direct identifier, PHI
`last_name`	`VARCHAR(64)`	Yes	PII, Direct identifier, PHI
`birth_date`	`DATE`	Yes	Quasi identifier, PHI
`email`	`VARCHAR(128)`	No	PII, Direct identifier, PHI
`phone`	`VARCHAR(24)`	No	PII, Direct identifier, PHI
`relationship_code`	`VARCHAR(8)`	Yes	—
`enrolled_on`	`DATE`	Yes	Quasi identifier, PHI

Demographics — enrollment.demographics · 7 columns

Address and demographic attributes of a member (current row per member).

Column	Type	Required	Sensitive classes
`demographics_id` (key)	`VARCHAR(16)`	Yes	—
`member_id`	`VARCHAR(16)`	Yes	Direct identifier, PHI
`gender_code`	`VARCHAR(2)`	Yes	—
`preferred_language`	`VARCHAR(12)`	No	—
`street_address`	`VARCHAR(96)`	No	PII, Quasi identifier, PHI
`city`	`VARCHAR(64)`	No	Quasi identifier, PHI
`postal_code`	`VARCHAR(10)`	No	Quasi identifier, PHI

Coverage — enrollment.coverages · 8 columns

A member's enrolment in a plan for a period (several rows = coordination of benefits).

Column	Type	Required	Sensitive classes
`coverage_id` (key)	`VARCHAR(16)`	Yes	—
`member_id`	`VARCHAR(16)`	Yes	Direct identifier, PHI
`plan_id`	`VARCHAR(12)`	Yes	—
`group_number`	`VARCHAR(16)`	Yes	Direct identifier, PHI
`coverage_order`	`VARCHAR(10)`	Yes	—
`effective_date`	`DATE`	Yes	Quasi identifier, PHI
`termination_date`	`DATE`	No	Quasi identifier, PHI
`status`	`VARCHAR(10)`	Yes	—

Provider — provider_directory.providers · 7 columns

A practitioner or organisation that delivers or bills care (synthetic ZP… ids, not real registry ids).

Column	Type	Required	Sensitive classes
`provider_id` (key)	`VARCHAR(12)`	Yes	Quasi identifier
`provider_name`	`VARCHAR(96)`	Yes	PII
`provider_kind`	`VARCHAR(12)`	Yes	—
`specialty`	`VARCHAR(40)`	Yes	—
`practice_city`	`VARCHAR(64)`	No	—
`practice_postal_code`	`VARCHAR(10)`	No	Quasi identifier
`phone`	`VARCHAR(24)`	No	PII

Claim — claims.claims · 12 columns

A bill for services submitted to the payer (header).

Column	Type	Required	Sensitive classes
`claim_id` (key)	`VARCHAR(16)`	Yes	Quasi identifier
`member_ref`	`VARCHAR(16)`	Yes	Direct identifier, PHI
`coverage_ref`	`VARCHAR(16)`	No	—
`billing_provider_ref`	`VARCHAR(12)`	Yes	Quasi identifier
`claim_type`	`VARCHAR(16)`	Yes	—
`service_from_date`	`DATE`	Yes	Quasi identifier, PHI
`service_to_date`	`DATE`	Yes	Quasi identifier, PHI
`received_date`	`DATE`	Yes	Quasi identifier, PHI
`claim_status`	`VARCHAR(10)`	Yes	—
`denial_reason_code`	`VARCHAR(8)`	No	—
`total_billed`	`DECIMAL(12,2)`	Yes	—
`total_paid`	`DECIMAL(12,2)`	Yes	—

ClaimLine — claims.claim_lines · 9 columns

One billed service on a claim.

Column	Type	Required	Sensitive classes
`claim_line_id` (key)	`VARCHAR(20)`	Yes	—
`claim_id`	`VARCHAR(16)`	Yes	Quasi identifier
`line_number`	`INT`	Yes	—
`member_ref`	`VARCHAR(16)`	Yes	Direct identifier, PHI
`rendering_provider_ref`	`VARCHAR(12)`	No	Quasi identifier
`service_date`	`DATE`	Yes	Quasi identifier, PHI
`units`	`INT`	Yes	—
`billed_amount`	`DECIMAL(12,2)`	Yes	—
`allowed_amount`	`DECIMAL(12,2)`	Yes	—

Diagnosis — claims.diagnoses · 5 columns

A diagnosis reported on a claim (synthetic ZD… codes).

Column	Type	Required	Sensitive classes
`diagnosis_id` (key)	`VARCHAR(20)`	Yes	—
`claim_id`	`VARCHAR(16)`	Yes	Quasi identifier
`sequence_number`	`INT`	Yes	—
`diagnosis_code`	`VARCHAR(8)`	Yes	—
`present_on_admission`	`VARCHAR(1)`	No	—

Procedure — claims.procedures · 4 columns

A procedure performed for a claim line (synthetic ZC… codes).

Column	Type	Required	Sensitive classes
`procedure_id` (key)	`VARCHAR(20)`	Yes	—
`claim_line_id`	`VARCHAR(20)`	Yes	—
`procedure_code`	`VARCHAR(8)`	Yes	—
`modifier_code`	`VARCHAR(4)`	No	—

Pharmacy — pharmacy.pharmacies · 5 columns

A dispensing pharmacy (synthetic ZRX… ids).

Column	Type	Required	Sensitive classes
`pharmacy_id` (key)	`VARCHAR(12)`	Yes	—
`pharmacy_name`	`VARCHAR(64)`	Yes	—
`city`	`VARCHAR(64)`	No	—
`postal_code`	`VARCHAR(10)`	No	Quasi identifier
`is_mail_order`	`BOOLEAN`	Yes	—

Prescription — pharmacy.prescriptions · 10 columns

A dispensed prescription fill (pharmacy claim).

Column	Type	Required	Sensitive classes
`prescription_id` (key)	`VARCHAR(16)`	Yes	—
`member_ref`	`VARCHAR(16)`	Yes	Direct identifier, PHI
`prescriber_ref`	`VARCHAR(12)`	Yes	Quasi identifier
`pharmacy_id`	`VARCHAR(12)`	Yes	—
`drug_code`	`VARCHAR(16)`	Yes	—
`fill_date`	`DATE`	Yes	Quasi identifier, PHI
`days_supply`	`INT`	Yes	—
`quantity`	`DOUBLE`	Yes	—
`refill_number`	`INT`	Yes	—
`paid_amount`	`DECIMAL(10,2)`	Yes	—

Encounter — clinical.encounters · 8 columns

A visit or stay recorded in the clinical system.

Column	Type	Required	Sensitive classes
`encounter_id` (key)	`VARCHAR(16)`	Yes	—
`member_ref`	`VARCHAR(16)`	Yes	Direct identifier, PHI
`provider_ref`	`VARCHAR(12)`	Yes	Quasi identifier
`encounter_type`	`VARCHAR(16)`	Yes	—
`admit_date`	`DATE`	Yes	Quasi identifier, PHI
`discharge_date`	`DATE`	No	Quasi identifier, PHI
`primary_diagnosis_code`	`VARCHAR(8)`	No	—
`clinical_note`	`VARCHAR(400)`	No	PHI, Sensitive

LabResult — clinical.lab_results · 10 columns

A laboratory observation (synthetic ZL… test codes).

Column	Type	Required	Sensitive classes
`lab_result_id` (key)	`VARCHAR(20)`	Yes	—
`encounter_id`	`VARCHAR(16)`	Yes	—
`member_ref`	`VARCHAR(16)`	Yes	Direct identifier, PHI
`test_code`	`VARCHAR(8)`	Yes	—
`result_value`	`DOUBLE`	No	—
`unit`	`VARCHAR(12)`	Yes	—
`reference_low`	`DOUBLE`	Yes	—
`reference_high`	`DOUBLE`	Yes	—
`abnormal_flag`	`VARCHAR(2)`	Yes	—
`collected_at`	`TIMESTAMP`	Yes	Quasi identifier, PHI

Trial — research.trials · 5 columns

A (fictional) clinical study.

Column	Type	Required	Sensitive classes
`trial_id` (key)	`VARCHAR(16)`	Yes	—
`title`	`VARCHAR(128)`	Yes	—
`phase`	`VARCHAR(8)`	Yes	—
`therapeutic_area`	`VARCHAR(32)`	Yes	—
`status`	`VARCHAR(12)`	Yes	—

ResearchSubject — research.research_subjects · 6 columns

A member enrolled in a study.

Column	Type	Required	Sensitive classes
`subject_id` (key)	`VARCHAR(16)`	Yes	Quasi identifier
`trial_id`	`VARCHAR(16)`	Yes	—
`member_ref`	`VARCHAR(16)`	Yes	Direct identifier, PHI
`consent_date`	`DATE`	Yes	Quasi identifier, PHI
`arm`	`VARCHAR(16)`	Yes	—
`enrollment_status`	`VARCHAR(12)`	Yes	—

Compatible connectors

Verified with this pack version: PostgreSQL and Local files (Parquet / CSV). 25 more connectors are compatible by capability: they support what the pack needs, but have not been verified with this pack yet.

Connector	Status with Healthcare & Life Sciences
Local files (Parquet / CSV)	Verified with this pack
PostgreSQL	Verified with this pack
Amazon DynamoDB	Compatible by capability (not yet verified with this pack)
Amazon Redshift	Compatible by capability (not yet verified with this pack)
Amazon S3 / S3-compatible storage	Compatible by capability (not yet verified with this pack)
Apache Kafka	Compatible by capability (not yet verified with this pack)
Azure Blob Storage / Data Lake Storage	Compatible by capability (not yet verified with this pack)
Azure Cosmos DB	Compatible by capability (not yet verified with this pack)
Azure Synapse Analytics	Compatible by capability (not yet verified with this pack)
CockroachDB	Compatible by capability (not yet verified with this pack)
Databricks	Compatible by capability (not yet verified with this pack)
Generic SQL (SQLAlchemy)	Compatible by capability (not yet verified with this pack)
Google BigQuery	Compatible by capability (not yet verified with this pack)
HTTP APIs	Compatible by capability (not yet verified with this pack)
IBM Db2	Compatible by capability (not yet verified with this pack)
IBM Informix	Compatible by capability (not yet verified with this pack)
Mainframe files (EBCDIC / copybook)	Compatible by capability (not yet verified with this pack)
MariaDB	Compatible by capability (not yet verified with this pack)
Microsoft SQL Server	Compatible by capability (not yet verified with this pack)
MongoDB	Compatible by capability (not yet verified with this pack)
MySQL	Compatible by capability (not yet verified with this pack)
Oracle Database	Compatible by capability (not yet verified with this pack)
Parquet files	Compatible by capability (not yet verified with this pack)
Salesforce	Compatible by capability (not yet verified with this pack)
ServiceNow	Compatible by capability (not yet verified with this pack)
Snowflake	Compatible by capability (not yet verified with this pack)
SQLite (developer evaluation)	Compatible by capability (not yet verified with this pack)

Prerequisites and expected setup effort

You need

A DataNivra account; the Free Trial includes this pack.
One DataNivra agent inside your network (outbound HTTPS only) that ships Healthcare & Life Sciences 2.1.0.
Read-only access to a compatible source (verified with this pack: PostgreSQL, Local files (Parquet / CSV)).
A non-production target environment the agent may write test data to.
A masking key in your own secret store, referenced as vault://…, azure-kv://… or env://… (DataNivra only ever sees the reference).
For production sources, a second person who approves policies (separation of duties).

A DataNivra agent that reports its installed industry packs (releases after agent 0.3.0); the control plane runs a pack job only on an agent holding the exact active pack version with the catalogued integrity digest.

Expected setup effort (estimates)

Step	Estimate
Try the synthetic sandbox No install: sign up and open the sandbox.	Minutes (estimate)
Install (or reuse) the agent One Docker command or a Helm chart; outbound HTTPS only.	Under an hour (estimate)
Connect a source Register a read-only source through the existing connector workflow.	Under an hour (estimate)
Review and approve policies Create drafts from the Healthcare & Life Sciences templates, review and approve them.	Under an hour (estimate)
First certified dataset Run the first job; certification and evidence are produced automatically.	Minutes (estimate)

Certification presets in plain language

`HC_CLINICAL_STRICT`

Every gate; full masking coverage; zero orphans across systems; exact row counts

Masking coverage of at least 100% of sensitive columns
No orphaned child records
Empty-value ratio may rise by at most 5%
Row counts must match exactly

16 gates it requires

POLICY_COVERAGE: every sensitive column is covered by an approved policy
MASKING_COMPLETION: masking finished on every covered column
REFERENTIAL_INTEGRITY: every reference still points at an existing record
SCHEMA_VALIDATION: the output schema matches the source schema
DATA_QUALITY: empty-value ratios stay within the preset’s drift limit
ROW_COUNT_RECONCILIATION: row counts match the plan within the tolerance
ORPHAN_DETECTION: no child record lost its parent
PROVENANCE: every row is tagged masked or synthetic
MANIFEST: a manifest lists every output table with checksums
POLICY_VERSION: the exact approved policy versions are recorded
ENGINE_VERSION: the engine version is recorded
CHECKSUMS: output checksums are recorded for later verification
IDENTITY_CONSISTENCY: linked identifiers got the same pseudonym in every system
SOURCE_READ_ONLY: the source was only read, never written
EGRESS_GUARD: no row-level data left the agent
CONNECTOR_HEALTH: the connectors stayed healthy during the run

`HC_DEVELOPMENT`

Every gate with slightly relaxed data-quality drift for developer sandboxes

Masking coverage of at least 100% of sensitive columns
No orphaned child records
Empty-value ratio may rise by at most 15%
Row counts must match exactly

16 gates it requires

POLICY_COVERAGE: every sensitive column is covered by an approved policy
MASKING_COMPLETION: masking finished on every covered column
REFERENTIAL_INTEGRITY: every reference still points at an existing record
SCHEMA_VALIDATION: the output schema matches the source schema
DATA_QUALITY: empty-value ratios stay within the preset’s drift limit
ROW_COUNT_RECONCILIATION: row counts match the plan within the tolerance
ORPHAN_DETECTION: no child record lost its parent
PROVENANCE: every row is tagged masked or synthetic
MANIFEST: a manifest lists every output table with checksums
POLICY_VERSION: the exact approved policy versions are recorded
ENGINE_VERSION: the engine version is recorded
CHECKSUMS: output checksums are recorded for later verification
IDENTITY_CONSISTENCY: linked identifiers got the same pseudonym in every system
SOURCE_READ_ONLY: the source was only read, never written
EGRESS_GUARD: no row-level data left the agent
CONNECTOR_HEALTH: the connectors stayed healthy during the run

`HC_SCHEMA_ONLY_SMOKE`

Schema, referential integrity and provenance gates only (synthetic-only smoke datasets)

Masking coverage of at least 100% of sensitive columns
No orphaned child records
Empty-value ratio may rise by at most 5%
Row counts must match exactly

3 gates it requires

SCHEMA_VALIDATION: the output schema matches the source schema
REFERENTIAL_INTEGRITY: every reference still points at an existing record
PROVENANCE: every row is tagged masked or synthetic

Activate it and create your first certified dataset

Seven steps in the console, each linked below. Nothing needs DataNivra staff.

Activate the pack for your organization
Activation checks your plan, the pack's integrity digest and its dependencies, then enables Healthcare & Life Sciences 2.1.0.
Open pack activation in the console
Install or reuse your agent
One agent runs every pack you activate; it must report this pack version. Upgrade it if it does not.
Install the agent in the console
Connect a compatible source
Start with a connector verified with this pack: PostgreSQL, Local files (Parquet / CSV).
Connect a source in the console
Create policies from the pack templates
Create drafts from Healthcare linked test data, Safe Harbor-oriented de-identification starter, Research extract test bed; a second person approves them (separation of duties).
Create policies from templates in the console
Request your first dataset
Choose a scenario such as Routine care (HC_ROUTINE_CARE), the subset size and relationship closure.
Request a dataset in the console
Certify
The run is certified against a preset such as HC_CLINICAL_STRICT; a failed dataset is never provisioned.
See certification evidence in the console
Provision and keep the evidence
Provision the certified dataset to a non-production target, download the evidence and schedule refreshes.
Provision the dataset in the console

Downloads

Version 2.1.0, 79 files (233.9 KB), all synthetic and generated from the pack itself. Every file’s SHA-256 is listed in MANIFEST.json.

Start here (2)

QUICKSTART.md 2.8 KB · SHA-256 b848bd9facaf…
TROUBLESHOOTING.md 4.7 KB · SHA-256 6d5b1fa550a8…

Entity–relationship diagram (2)

er-diagram.mmd 5.9 KB · SHA-256 c9610ab72026…
er-diagram.svg 11.2 KB · SHA-256 bb6d922e092e…

Sample schemas (7)

schema/claims.sql 2.5 KB · SHA-256 f0455e1dc924…
schema/clinical.sql 1.5 KB · SHA-256 d2393440a817…
schema/enrollment.sql 2.8 KB · SHA-256 6d9d295e3ddd…
schema/entities.json 36.9 KB · SHA-256 7ae8a18727d1…
schema/pharmacy.sql 1.3 KB · SHA-256 118b3d633e77…
schema/provider_directory.sql 864 B · SHA-256 09f06295c12d…
schema/research.sql 1.1 KB · SHA-256 faa16b8c58ae…

Policy templates (10)

policies/HC_CLASSIFICATION.json 207 B · SHA-256 b88733df9f4b…
policies/HC_CLINICAL_STRICT.json 549 B · SHA-256 df479db4f4bb…
policies/HC_DEVELOPMENT.json 549 B · SHA-256 a0728ad1a443…
policies/HC_LINKED_TEST_DATA.json 20.5 KB · SHA-256 9cc67b9fafcf…
policies/HC_REFRESH_WEEKLY.json 190 B · SHA-256 e54930bed540…
policies/HC_RESEARCH_EXTRACT.json 16.2 KB · SHA-256 62473a434f1e…
policies/HC_SAFE_HARBOR_STARTER.json 15.0 KB · SHA-256 302db7877aed…
policies/HC_SCHEMA_ONLY_SMOKE.json 251 B · SHA-256 89d7e97ca0b6…
policies/HC_SUBSET_DEFAULT.json 112 B · SHA-256 d46c49c10d7c…
policies/README.md 1.4 KB · SHA-256 4f225685846b…

API, CLI, SDK and CI/CD examples (10)

api/curl.sh 2.6 KB · SHA-256 f0cef156a1c5…
api/dataset-request.json 1.5 KB · SHA-256 d966bc7c2696…
api/policy-approval.json 155 B · SHA-256 d55e632a5036…
api/policy-drafts.json 162 B · SHA-256 1e25229c4597…
api/provision.json 63 B · SHA-256 7f02a6a87792…
api/sandbox.json 38 B · SHA-256 db5cb7180307…
ci/README.md 513 B · SHA-256 29082ab861a5…
ci/github-actions.yml 1.9 KB · SHA-256 2fba58aa09bd…
cli.md 1.7 KB · SHA-256 211b22c17f41…
sdk_example.py 1.6 KB · SHA-256 1b3a105b4538…

Synthetic sample data (CSV, JSON, Parquet) (46)

synthetic/SYNTHETIC_MANIFEST.json 3.3 KB · SHA-256 7a2358362921…
synthetic/claims.claim_lines.csv 1.9 KB · SHA-256 87949b64d05b…
synthetic/claims.claim_lines.json 6.3 KB · SHA-256 bbdfe5efdf50…
synthetic/claims.claim_lines.parquet 3.5 KB · SHA-256 67f49a89facb…
synthetic/claims.claims.csv 1.5 KB · SHA-256 d863c5e3f5ce…
synthetic/claims.claims.json 4.8 KB · SHA-256 bd7cde24397e…
synthetic/claims.claims.parquet 4.2 KB · SHA-256 254ef74b49ad…
synthetic/claims.diagnoses.csv 1.1 KB · SHA-256 133ad1e8fafb…
synthetic/claims.diagnoses.json 4.2 KB · SHA-256 da2d9d397ded…
synthetic/claims.diagnoses.parquet 2.1 KB · SHA-256 95b496213d47…
synthetic/claims.procedures.csv 1.1 KB · SHA-256 be74756b4f8b…
synthetic/claims.procedures.json 3.6 KB · SHA-256 367f1cc7fc75…
synthetic/claims.procedures.parquet 1.9 KB · SHA-256 ddc86c62cc9e…
synthetic/clinical.encounters.csv 1.7 KB · SHA-256 dcc9f9c298ea…
synthetic/clinical.encounters.json 4.0 KB · SHA-256 ce7fa4646ca9…
synthetic/clinical.encounters.parquet 3.8 KB · SHA-256 be10f6ca381d…
synthetic/clinical.lab_results.csv 1.4 KB · SHA-256 e536e96e717a…
synthetic/clinical.lab_results.json 4.7 KB · SHA-256 f6c761f21f0f…
synthetic/clinical.lab_results.parquet 3.6 KB · SHA-256 6b74a8c83c49…
synthetic/enrollment.coverages.csv 540 B · SHA-256 ecd8edf5df60…
synthetic/enrollment.coverages.json 1.5 KB · SHA-256 a885057ad18e…
synthetic/enrollment.coverages.parquet 2.7 KB · SHA-256 b1ab7ec4b5cb…
synthetic/enrollment.demographics.csv 466 B · SHA-256 f091f89f56c3…
synthetic/enrollment.demographics.json 1.3 KB · SHA-256 5098bd21d864…
synthetic/enrollment.demographics.parquet 2.6 KB · SHA-256 86fe48b9e209…
synthetic/enrollment.members.csv 781 B · SHA-256 d161e05f3570…
synthetic/enrollment.members.json 1.9 KB · SHA-256 92c1bea1a254…
synthetic/enrollment.members.parquet 3.5 KB · SHA-256 72d6633a51b6…
synthetic/enrollment.plans.csv 416 B · SHA-256 ad35bd40dbc0…
synthetic/enrollment.plans.json 1.0 KB · SHA-256 28392df7523f…
synthetic/enrollment.plans.parquet 1.7 KB · SHA-256 a21422188918…
synthetic/pharmacy.pharmacies.csv 328 B · SHA-256 b2fbfd692489…
synthetic/pharmacy.pharmacies.json 811 B · SHA-256 b12ae1cb2368…
synthetic/pharmacy.pharmacies.parquet 1.9 KB · SHA-256 4f2bdf6b3c21…
synthetic/pharmacy.prescriptions.csv 535 B · SHA-256 75c5956f0a01…
synthetic/pharmacy.prescriptions.json 1.4 KB · SHA-256 85a213cb0438…
synthetic/pharmacy.prescriptions.parquet 3.3 KB · SHA-256 f2720db577fc…
synthetic/provider_directory.providers.csv 846 B · SHA-256 4654d157f184…
synthetic/provider_directory.providers.json 2.2 KB · SHA-256 d85449111040…
synthetic/provider_directory.providers.parquet 3.0 KB · SHA-256 e72bafb3e73c…
synthetic/research.research_subjects.csv 227 B · SHA-256 fbe09106c4c1…
synthetic/research.research_subjects.json 467 B · SHA-256 3b96df21d83d…
synthetic/research.research_subjects.parquet 2.1 KB · SHA-256 6fb1db7f6ca7…
synthetic/research.trials.csv 302 B · SHA-256 9d792aaff81c…
synthetic/research.trials.json 629 B · SHA-256 2f1f95a52be4…
synthetic/research.trials.parquet 2.0 KB · SHA-256 a8e6d010beca…

Troubleshooting

The reason codes you can meet on the way, with the recovery step. Every code is also in the error-code catalog.

SANDBOX_PACK_NOT_OFFERED — Synthetic estate not offered: A requested synthetic estate (industry pack) is not available in the hosted sandbox. What to do: Start the sandbox with the default estates.
ENTITLEMENT_REQUIRED — Plan does not include this: Your plan does not include this feature or industry pack. What to do: Upgrade in Billing & Plan.
PACK_INTEGRITY_UNVERIFIED — Pack integrity not verified: This pack version was registered without an integrity digest, so it cannot be activated (fail closed). What to do: Ask your operator to re-register the pack catalogue with the current control-plane image (register-pack), then activate again.
PACK_DEPENDENCY_INACTIVE — Required pack not active: This pack depends on another industry pack that is not active for your organization. What to do: Activate the packs this pack depends on first, then activate it again.
AGENT_PACK_MISSING — No agent can run this industry pack: The job's agent does not report the pack (older agents report no packs at all), so the job was not sent. What to do: Upgrade the agent to a release that reports its installed packs and ships this pack, then run the request again.
AGENT_PACK_VERSION_INCOMPATIBLE — Industry pack version differs on the agent: The agent holds a different version of the pack than the one the job was approved for. What to do: Deploy an agent with the pack's active version, or roll the pack back in Industry packs.
AGENT_PACK_INTEGRITY_MISMATCH — Agent pack differs from the catalogue: The agent reports the pack's version with a different integrity digest than the catalogued one, so the job was not sent. What to do: Redeploy the agent from the official signed image for this release, then run the request again.
PACK_TEMPLATES_UNAVAILABLE — Pack templates not registered: This pack version was registered without its policy templates. What to do: Ask your operator to re-register the pack catalogue (register-pack); create policies manually meanwhile.
PACK_TEMPLATE_KEY_REF_REQUIRED — Masking key reference required: A selected template keeps identities linked across systems and needs your masking key reference. What to do: Provide key_ref, e.g. vault://your-vault/tdm-masking-key, then create the drafts again.
PACK_NOT_ENABLED — Industry pack not enabled: The industry pack is not enabled for this tenant. What to do: Enable the pack (if your plan includes it).

Frequently asked questions

Are the Healthcare & Life Sciences records on this page real?: No. Every record on this page is synthetic, generated from a fixed seed by the pack's own generator; masked values come from the real masking engine. The masking example uses a fixed public sample key; your own data is masked with a key from your secret store.
Can I activate the Healthcare & Life Sciences pack myself?: Included in Free Trial, Developer, Team, Business, Enterprise and Private Cloud / Self-Hosted. You can activate it for your organization yourself in the console; no call is needed.
Which databases and files does the Healthcare & Life Sciences pack work with?: Verified with this pack version: PostgreSQL and Local files (Parquet / CSV). 25 more connectors are compatible by capability: they support what the pack needs, but have not been verified with this pack yet.
How long does a first certified Healthcare & Life Sciences dataset take?: Estimates, not guarantees — try the synthetic sandbox: minutes; install (or reuse) the agent: under an hour; connect a source: under an hour; review and approve policies: under an hour; first certified dataset: minutes.
Which test scenarios does the Healthcare & Life Sciences pack include?: 10 runnable scenarios (routine care, claim denials, coordination of benefits, chronic care and more), plus 2 negative-test scenario kept apart from valid data.
Do Healthcare & Life Sciences rows leave my network?: No. The DataNivra agent runs inside your environment: it reads the source, masks, subsets, generates and certifies there, and sends only metadata, aggregate counts and evidence to the DataNivra control plane (customer-resident processing, zero raw-production-data egress).

Learn the concepts, then come back to activate

Regulatory context

Supports organisations running HIPAA-related privacy programmes by keeping PHI inside their environment and producing certification evidence. It does not, by itself, make any system compliant with HIPAA.

Try with synthetic data Activate this pack — start free

No call and no credit card needed. Prefer a conversation? Request a demo (optional). Missing something? Request a feature.

Problems this pack solves

Masked data that still joins across 6 systems

The cases production samples rarely contain

Sensitive fields found and masked before anyone sees them

Evidence that each dataset is fit to use

Entities and relationships

Realistic synthetic records

Masking: before and after

Synthetic scenarios you can run

Routine care

Claim denials

Coordination of benefits

Chronic care

Pharmacy refills

Abnormal labs

Eligibility gaps

Denial resubmission

Coverage changes

Historical claims

Sample schemas and representative outputs

Compatible connectors

Prerequisites and expected setup effort

You need

Expected setup effort (estimates)

Certification presets in plain language

HC_CLINICAL_STRICT

HC_DEVELOPMENT

HC_SCHEMA_ONLY_SMOKE

Activate it and create your first certified dataset

Activate the pack for your organization

Install or reuse your agent

Connect a compatible source

Create policies from the pack templates

Request your first dataset

Certify

Provision and keep the evidence

Downloads

Troubleshooting

Frequently asked questions

Learn the concepts, then come back to activate

Regulatory context

`HC_CLINICAL_STRICT`

`HC_DEVELOPMENT`

`HC_SCHEMA_ONLY_SMOKE`