Part 2 electronic-record de-identification

Editorial approval scope: The team checked current source fidelity, scope boundaries, dates, arithmetic, reader usefulness, practical workflow, and general-information limitations.

Current rule checkpoint

Live 42 CFR 2.16(a)(1)(ii)(D) requires formal policies and procedures for rendering electronic patient-identifying information de-identified under 45 CFR 164.514(b) so there is no reasonable basis to believe it can identify a patient. Expert Determination and Safe Harbor are the incorporated methods. The HHS fact sheet identifies February 16, 2026 as the compliance date for the amended Part 2 framework.

Choose and document the method

The Part 2 security rule incorporates HIPAA's de-identification methods. Record whether the data set uses Expert Determination or Safe Harbor, who performed the work, which version was reviewed, and which limitations apply.

Follow the data model

Map patient, encounter, diagnosis, payer, provider, geography, dates, device, message, attachment, audit, analytics, and join-key fields. Derived scores and sparse combinations can remain identifying even when direct identifiers disappear.

Validate the exact export

Test queries, filters, transformations, metadata, row counts, suppressed cells, free text, filenames, attachments, recipient access, download controls, and change history. Recheck when fields, source systems, joins, recipients, or purposes change.

Map data beyond the visible table

Inventory structured fields, free text, notes, messages, filenames, attachments, images, audio, video, metadata, audit trails, logs, row keys, user identifiers, device identifiers, dates, geography, provider and employer data, payer fields, derived features, embeddings, model outputs, join keys, suppressed values, and lookup tables. Trace copies in queries, notebooks, reports, exports, caches, backups, and vendor systems.

Document source version, extraction time, query, filters, joins, transformations, exclusions, row count, field count, owner, and intended recipient. A data dictionary should distinguish direct identifiers, quasi-identifiers, sensitive attributes, operational keys, and values derived from other fields.

Implement the selected method as a repeatable pipeline

For Safe Harbor, remove or transform every specified identifier and complete the no-actual-knowledge review. Inspect free text and attachments instead of applying the checklist only to columns. Prevent hidden fields, metadata, filenames, and export settings from restoring identifiers.

For Expert Determination, preserve expert qualifications, exact data and recipient context, reasonably available external information, statistical and scientific method, very-small-risk conclusion, utility tradeoffs, assumptions, controls, and results. Version the report with the code and data schema it supports.

Use tested code review, approved libraries, access-controlled execution, reproducible environments, change control, and automated checks. Keep source and released data separated and restrict any code or key that could reverse transformations.

Test linkage, sparsity, and recipient context

Evaluate unique and rare combinations, small cells, outliers, temporal patterns, geographic detail, sequence data, provider patterns, exact dates, household links, and repeated releases. Consider what the anticipated recipient and public sources can reasonably supply. Multiple individually reviewed releases can become identifying when combined.

Validate the actual export with row and schema checks, identifier scans, free-text review, attachment inventory, metadata inspection, sample re-identification testing appropriate to the method, and recipient controls. Reject any export that bypasses the approved pipeline.

Govern release and ongoing change

Record method, data version, code version, expert report or Safe Harbor evidence, actual-knowledge review, validation, recipient, purpose, environment, access, retention, sharing, and release date. Restrict downloads and downstream linkage as appropriate to the risk analysis.

Reassess after new fields, source changes, transformation changes, recipient changes, broader distribution, external-data changes, or repeated releases. Preserve prior versions and investigate any identifying output or pipeline failure.

Make the release reproducible

Store the approved query, code, configuration, dependency versions, input snapshot or immutable reference, output hash, data dictionary, validation result, reviewer, and release manifest. Another qualified reviewer should be able to recreate the released file and explain every transformation without gaining unnecessary access to the source.

Before delivery, ask whether a hidden export option, linked dashboard, cached preview, application log, or recipient-side join changes the data actually exposed. Test the same delivery path the recipient will use, then lock the released version and monitor later access or downloads as appropriate.

Example

Sixteen export configurations are assessed. Thirteen have a documented method, field map, metadata review, recipient-context analysis, sample test, approval, and version lock; three bypass the approved pipeline. Readiness is 13 of 16 configurations.

Electronic de-identification checklist

• map fields, text, files, metadata, logs, keys, joins, models, backups, and copies;
• apply complete Safe Harbor or a versioned qualified Expert Determination;
• use reproducible, reviewed, access-controlled code and environments;
• test rare combinations, linkage, repeated releases, text, attachments, and metadata;
• validate and approve the exact export and anticipated recipient context; and
• preserve evidence and reassess schema, code, recipient, purpose, and external change.

Dropping obvious identifier columns is only one transformation. De-identification applies to the complete released data and the context in which identification might occur.