What does it mean to de-identify an EDI 835 or 837 file?

De-identifying an EDI 835 or 837 file means removing or masking direct identifiers and certain sensitive fields so that individual patients or members are much harder to re-identify. This usually involves changing names, IDs, dates of birth, addresses, and other obvious identifiers while keeping the structure of the claims data intact for testing or analysis.

Why would I want to de-identify EDI files?

De-identification allows you to use realistic claims and remittance data for testing, demos, training, or analytics without exposing real patient or member identities. Many organizations prefer to work with de-identified data whenever possible to reduce privacy risk and make it easier to share data internally or with vendors.

Which fields are typically masked or removed during de-identification?

Common targets for de-identification include patient and subscriber names, member IDs, account numbers, Social Security Numbers, dates of birth, street addresses, phone numbers, and email addresses. Some workflows also generalize or shift dates and mask internal reference numbers while preserving claim structure and financial amounts.

Can I safely use de-identified EDI data for demos and training?

De-identified EDI data is often used for demos, training, and proof-of-concept work because it closely resembles real data without exposing actual patient identities. However, you should still confirm that your de-identification approach aligns with your organization’s privacy and security standards, especially if the data will be widely shared.

Does de-identification guarantee that the data is no longer PHI?

De-identification substantially reduces privacy risk but does not automatically guarantee that the data can never be linked back to individuals. Under HIPAA, there are specific standards for de-identification, and organizations must decide whether a dataset still qualifies as PHI based on their chosen method and risk analysis.

How does an automated de-identification mode in a converter work?

An automated de-identification mode in an EDI converter typically looks for known identifier fields in segments like NM1, REF, N3, and N4 and then masks or replaces those values in the exported CSV or Excel. The goal is to preserve claim and payment structure while reducing the likelihood that a specific person can be identified from the output.

Best Practices for De-Identifying EDI Files (HIPAA-Conscious Guide)

Quick Table of Contents

Who this guide is for
What “de-identifying EDI” actually means
Where PHI lives in 835 & 837 files
De-identification strategies: masking, removal, tokenization
Safe de-identification workflow (step-by-step)
Why client-side de-identification matters
Practical examples: before & after de-identification
FAQ: de-identifying EDI

Who this guide is for

This guide is written for:

Data & analytics teams that want to use real claims and remittance data for dashboards, models, or ad‑hoc analysis.
Engineering teams that need realistic EDI data for development, QA, and UAT environments.
Compliance & security teams who want clear, concrete patterns for HIPAA‑conscious workflows.

We’ll focus on practical de-identification patterns that work well in real organizations — not abstract theory.

What “de-identifying EDI” actually means

In plain language, de-identification means:

Removing or transforming all data that can reasonably identify a specific patient, while preserving enough structure and content to be useful for analytics, testing, or training.

In the context of 835 and 837 files, that usually means:

Removing names, street‑level addresses, phone numbers, email addresses.
Replacing member IDs and claim IDs with pseudonyms or hashed values.
Truncating or shifting dates where needed, depending on internal policy.
Preserving codes (CPT, ICD, revenue, CAS, etc.) and financials for analysis.

Important: This article is not legal advice. Always align your de‑identification approach with your organization’s HIPAA/privacy policies and legal guidance.

Where PHI lives in 835 & 837 files

EDI 835 and 837 files are dense with identifiers. Here are some common PHI locations by segment:

Segment	PHI examples	Typical handling when de-identifying
NM1 (Name)	Patient name, subscriber name, guarantor name	Remove or replace with generic labels (e.g., “PATIENT_001”)
N3 / N4 (Address)	Street address, city, state, ZIP	Remove street and city; optionally keep state/ZIP3 for analytics
REF	Member IDs, medical record numbers, account numbers	Tokenize or hash; store raw identifiers only in authorized, appropriately secured systems
DMG	Date of birth, gender	Mask DOB (e.g., year only or age band) depending on use case
CLP / CLM IDs	Internal claim control numbers tied to specific patients	Tokenize or map to synthetic IDs (e.g., CLAIM_00123)
PER	Phone numbers, contact names	Remove entirely for most de‑identified datasets

Codes like CPT, ICD‑10, revenue codes, HCPCS, and adjustment reason codes are usually not PHI by themselves and can safely be preserved, as long as they’re not combined with direct identifiers in a way that re‑identifies specific individuals.

De-identification strategies: masking, removal, tokenization

In practice, you’ll combine three main strategies when de‑identifying EDI data:

1. Removal (redaction)

Completely removing a field or segment that contains PHI.

Example: Removing N3 (street address) and PER phone numbers entirely.
Pro: Very safe; no risk of leakage from those fields.
Con: You lose that information for downstream analysis.

2. Masking (obfuscation)

Replacing PHI with obviously fake or generic values.

Example: Replacing patient names with “PATIENT_001”, “PATIENT_002”, etc.
Example: Masking member IDs as “MEMBER_12345”.
Pro: Preserves structure and relationships (same patient still links across claims).
Con: Requires careful implementation to avoid leaking original patterns.

3. Tokenization / hashing

Converting an identifier to a consistent pseudonym via a one‑way function or lookup.

Example: Hashing member IDs to a new ID used only in analytics environments.
Example: Using a tokenization service that maps real IDs to synthetic IDs.
Pro: Preserves join keys and relationships across files without exposing raw IDs.
Con: Needs strong key management and clear separation from PHI‑bearing systems.

Most organizations end up with a hybrid: remove direct contact info, mask names, and tokenize IDs.

Safe de-identification workflow (step-by-step)

Step 1: Decide where de-identification happens

The safest pattern is:

Start from an authorized, appropriately secured system such as a governed data warehouse or billing platform.
Run de‑identification there or in a tightly controlled environment.
Only export already de‑identified data into broader analytics, dev, or training environments.

Step 2: Define a clear PHI field list

For 835/837 data, build a table similar to the one above and classify each element as:

Direct identifier (must be removed, masked, or tokenized).
Quasi‑identifier (may need generalization or truncation).
Non‑identifier (safe to keep as‑is for analytics).

Step 3: Implement a repeatable transformation

Whether you’re using Python, SQL, or a dedicated tool, ensure that:

The same real member ID always maps to the same synthetic ID.
Names and addresses are transformed consistently across files.
Dates are handled according to policy (exact dates vs shifted vs year‑only).

Step 4: Validate the output

Before using a new de‑identification pipeline in production:

Spot‑check raw EDI vs de‑identified output using tools like the EDI Viewer.
Confirm that no names, phone numbers, or raw IDs remain.
Verify that analytical structure is preserved (claims still link properly, codes and amounts unchanged).

Step 5: Restrict access to mapping keys

If you use tokenization, keep the mapping between real IDs and synthetic IDs in a secure, access‑controlled system. Analytics users should never need direct access to that mapping.

Why client-side de-identification matters

When de‑identifying EDI files, you want to avoid creating new systems that handle PHI unless necessary. That’s where client‑side processing is especially helpful.

Client-side de-identification with the EDI Converter

The Client-Side EDI 835/837 Converter is designed so that:

Supported EDI file content is parsed locally in the browser using JavaScript.
Browser-local processing reduces the need to transmit that content to the application server.
Optional de‑identification logic can be applied before export.
The resulting CSV/Excel can be saved and used in non‑PHI environments.

This means you can sit at a PHI‑enabled workstation, load an EDI file into your browser, and de‑identify it on the fly. Browser-local processing reduces the need to transmit source EDI file contents to the application server before export.

For a deeper dive into how the client‑side model works, see the Safety & Privacy page.

Practical examples: before & after de-identification

Example 1: Patient name and member ID

NM1*IL*1*SMITH*JANE****MI*ABC123456~
REF*MI*ABC123456~

After de-identification (mask + token):

NM1*IL*1*PATIENT*001****MI*MEMBER_00001~
REF*MI*MEMBER_00001~

Here we’ve removed the real last/first name and replaced the member ID with a synthetic value, while preserving structure.

Example 2: Address

N3*123 MAIN STREET APT 5B~
N4*ANYTOWN*NY*10001~

After de-identification (removal + partial location):

N3*DE-IDENTIFIED ADDRESS~
N4*NY*NY*100**~

Street and precise location are removed or generalized, while state and partial ZIP (if allowed by policy) are retained.

Example 3: Keeping analytics detail

SVC*HC:99213*150*95**1~
CAS*CO*45*55.00*1~

These segments usually don’t require de‑identification by themselves. You can keep CPT/HCPCS codes and financials intact for analytics since they don’t directly identify a person when used without raw identifiers.

FAQ: De-identifying EDI 835/837 Files

Is de-identified EDI still subject to HIPAA?

HIPAA restrictions generally apply to PHI. Properly de‑identified data that cannot be used to identify an individual is treated differently, but the exact threshold is a legal/compliance question. Always align with your organization’s privacy office and legal counsel.

Can we keep exact dates of service in de-identified data?

It depends on your internal policy. Some organizations keep exact service dates; others shift all dates by a fixed offset, or keep only month/year, especially for smaller populations. The key is avoiding combinations that could re‑identify individuals.

Do we have to remove all provider information?

Provider names and NPIs are usually not PHI. Many organizations keep provider identifiers in de‑identified datasets so they can analyze performance by provider, group, or facility. Again, confirm with your compliance team.

Can I use de-identified EDI in non-production environments?

Yes — that’s one of the primary benefits. By de‑identifying EDI files, you can safely use realistic data in development, QA, UAT, and training environments that are not approved for PHI.

What’s the easiest way to get started?

Start small: pick a single 835 or 837 file, identify a handful of PHI elements (names, member IDs, addresses), and run a manual de‑identification pass. Once you’re comfortable with the pattern, automate it and formalize it as part of your ingestion or export process.

Try de-identifying an EDI file now

Load an 835 or 837 into the client-side converter, explore its structure, and generate a flat CSV/Excel output that you can safely use for analysis once de‑identified.

Open the Client-Side EDI Converter Inspect an EDI file in the viewer

Compare all EDI tools before choosing how to inspect or transform the file.