PHI in EDI Files: What's Actually in There — and How to Share Files Without Exposing Patient Data

The Problem No One Talks About at Stand-Up

You’re troubleshooting a claim rejection. Your clearinghouse support rep asks you to send over a sample file. You zip up last week’s 837P batch, attach it to an email, and hit send.

You just shared dozens — maybe hundreds — of real patient records with someone who probably didn’t need all of them.

This happens constantly in healthcare billing. EDI files are treated like log files or config exports — technical artifacts that get passed around freely during troubleshooting, testing, and vendor onboarding. But unlike a log file, an 837 transaction contains real patient names, dates of birth, Social Security Numbers, diagnosis codes, procedure codes, and insurance member IDs. In some transactions, all of those appear in a single file.

This post is a field-level breakdown of exactly what PHI lives inside 837, 835, and 270/271 EDI files — and what you need to do before you share one.

What Is PHI in the Context of EDI?

Under HIPAA, Protected Health Information (PHI) is any individually identifiable health information that is created, received, maintained, or transmitted by a covered entity or business associate. The Privacy Rule (45 CFR § 164.514) defines 18 specific identifiers that, when combined with health information, constitute PHI.

The 18 HIPAA identifiers are:

Names
Geographic subdivisions smaller than a state
Dates (except year) related to an individual — birthdate, admission date, discharge date, date of death
Phone numbers
Fax numbers
Email addresses
Social Security Numbers
Medical record numbers
Health plan beneficiary numbers
Account numbers
Certificate/license numbers
Vehicle identifiers and serial numbers
Device identifiers
Web URLs
IP addresses
Biometric identifiers
Full-face photographs
Any other unique identifying number or code

Of these 18, EDI healthcare transactions routinely contain at least 6 to 10 — depending on the transaction type and trading partner configuration. That’s not an edge case. It’s the design.

What’s Inside an 837 Claim File

The 837 transaction set — the electronic claim — is the richest source of PHI in the EDI ecosystem. It’s the file you generate for every claim submission, whether professional (837P), institutional (837I), or dental (837D).

NM1 — Patient Name and Identifier

The NM1 segment carries the patient’s name and identifier in every 837 file. The loop 2010CA patient name segment is mandatory.

NM1*QC*1*RODRIGUEZ*MARIA*L**MI*9AB1-XZ4-KP88~

Breaking this down:

QC — qualifier: patient
1 — entity type: person
RODRIGUEZ — last name
MARIA — first name
L — middle initial
MI — member ID qualifier
9AB1-XZ4-KP88 — Medicare Beneficiary Identifier (MBI)

The identifier in position 9 may be an MBI, a plan-specific member ID, or in older implementations, a Social Security Number. SSNs were common in Medicare claims prior to the 2018 MBI transition, and you will still encounter them in legacy data.

DMG — Patient Demographics

The DMG segment carries date of birth and gender — both HIPAA identifiers.

DMG*D8*19680517*F~

D8 — date format: CCYYMMDD
19680517 — date of birth: May 17, 1968
F — gender: female

This segment appears in both the subscriber loop (2010BA) and the patient loop (2010CA) when the patient is not the subscriber.

CLM — Claim-Level Information

The CLM segment contains the claim ID, total charge amount, and facility/service place codes. It also links to diagnosis and procedure codes that, in context, identify specific conditions being treated.

CLM*20240315-RDZMR-001*1250.00***11:B:1*Y*A*Y*I~

20240615-RDZMR-001 — provider-assigned claim ID (often contains date + patient initials or account number)
1250.00 — total charge
11 — place of service: office
B — facility code value
1 — claim frequency code

Claim IDs in practice often encode patient account numbers or date-of-service, making them additional indirect identifiers.

DTP — Service Dates

Date of service is a HIPAA identifier. It appears in multiple segments throughout an 837 file.

DTP*472*D8*20240615~

472 — qualifier: service date
D8 — date format
20240615 — June 15, 2024

Service dates appear at the claim level (CLM loop), at the service line level, and in admission/discharge pairs for institutional claims.

HI — Diagnosis Codes

Diagnosis codes (ICD-10-CM) map directly to specific medical conditions. While a standalone diagnosis code isn’t individually identifying, in combination with a name and date of birth — both of which are already in the same file — it constitutes detailed health information.

HI*ABK:Z23~
HI*ABF:E11.9~

ABK — principal diagnosis
Z23 — encounter for immunization
ABF — other diagnosis
E11.9 — type 2 diabetes mellitus without complications

A file containing a patient’s name, DOB, member ID, and a diagnosis of a chronic or sensitive condition is highly sensitive data by any standard.

SBR and NM1 — Subscriber Information

When the patient is not the subscriber (a dependent on a family plan), the file also contains the subscriber’s full name, member ID, and date of birth — a second person’s PHI in the same transaction.

NM1*IL*1*RODRIGUEZ*CARLOS*M**MI*7YZ9-AB2-LM44~

What’s Inside an 835 Remittance File

The 835 — the Electronic Remittance Advice (ERA) — is what comes back from payers after a claim adjudicates. It contains less demographic data than the 837, but it still carries PHI.

NM1 — Patient Name in ERA

The patient name appears in the 835’s claim payment loop (2110).

NM1*QC*1*RODRIGUEZ*MARIA****~

Unlike the 837, the 835 often omits the patient identifier or date of birth — but the name is present, and it’s paired with claim-level detail.

CLP — Claim Payment Data

The CLP segment is the core of the 835. It contains the payer’s internal claim number, payment amounts, and adjudication status.

CLP*20240615-RDZMR-001*1*1250.00*875.00**MC*1234567890A~

20240615-RDZMR-001 — patient control number (from the original 837)
1 — claim status: processed as primary
1250.00 — total charges
875.00 — amount paid
MC — payer claim reference (in Medicare context, the ICN)
1234567890A — Medicare claim number

The patient control number is often sourced from your practice management system and may encode a patient account number.

SVC — Service Line Detail

Each adjudicated service line appears in an SVC segment with procedure codes, allowed amounts, and adjustment codes.

SVC*HC:99213*250.00*175.00**1~

HC:99213 — HCPCS/CPT code: office visit, established patient, moderate complexity
250.00 — submitted charge
175.00 — paid amount
1 — service line number

Procedure codes combined with patient name constitute health information — exactly what HIPAA protects.

DTM — Service and Payment Dates

DTM*232*20240615~
DTM*233*20240615~

232 — claim statement period start
233 — claim statement period end
20240615 — June 15, 2024

What’s Inside a 270/271 Eligibility File

The 270 (eligibility inquiry) and 271 (eligibility response) are often overlooked when discussing PHI exposure, but they carry significant patient data — especially the 271 response.

270 — Eligibility Inquiry

The 270 contains the subscriber’s member ID and, when the patient is a dependent, the patient’s name and date of birth.

NM1*IL*1*CHEN*DAVID****MI*W1A2B3C4D5~
DMG*D8*19751203*M~
NM1*QC*1*CHEN*EMMA****~
DMG*D8*20080914*F~

This file exposes the subscriber’s member ID, his date of birth, and a dependent’s name and date of birth — to whoever receives it.

271 — Eligibility Response

The 271 response from the payer is even richer. It typically includes:

Subscriber name and member ID
Plan name and group number
Coverage effective dates
Benefit details (deductible remaining, co-pay amounts, co-insurance)
Dependent information

Coverage dates and benefit details are health information. Combined with the subscriber name, this is PHI under 45 CFR § 160.103.

Real-World Scenarios Where EDI PHI Gets Exposed

These aren’t hypotheticals. They’re patterns that come up regularly in billing operations.

1. Emailing a Sample File to Clearinghouse Support

A batch of 837s fails validation and the clearinghouse asks for a sample. The biller zips up 5–10 transactions from the current week’s batch and emails them directly. Those files contain real patient names, DOBs, and diagnosis codes — sent over email, which is not an encrypted channel by default.

2. Sending Production Files to a Vendor for “Testing”

A new billing software vendor needs to verify their 835 parser. They ask for sample remittance files. The billing team pulls a few real ERAs from last month. The vendor now has real patient names, claim numbers, and procedure codes — on their servers, potentially accessible to their staff, with no BAA in place.

3. Attaching EDI Files to Jira or GitHub Tickets

Developers building claim processing pipelines need representative data to reproduce parsing bugs. Someone attaches a real 837 file to a ticket as a “sample.” It’s now stored in a ticket tracker — indexed, searchable, and accessible to everyone with repository access, possibly including contractors.

4. Using Production Data as “Test” Data

This is the most common and most invisible problem. EDI files from real submissions are copied into test environments, local developer machines, or shared network drives labeled “sample files.” There’s no formal disclosure or tracking — the data just drifts into spaces where it was never intended to go.

HIPAA Minimum Necessary Standard

The HIPAA Privacy Rule’s minimum necessary standard (45 CFR § 164.502(b)) requires covered entities and their business associates to make reasonable efforts to limit the use and disclosure of PHI to the minimum necessary to accomplish the intended purpose.

When you send a complete 837 batch to a support team to investigate a single segment validation error, you’re almost certainly violating this standard. The support rep needs to see the segment structure — not the actual patient names, DOBs, and diagnoses of 200 people.

The minimum necessary standard applies to:

Disclosures to business associates (including clearinghouses and vendors)
Internal uses of PHI by workforce members
Requests for PHI from other covered entities

It does not require you to identify the absolute minimum in every case — only that you have reasonable policies and apply them in practice. But “we just sent the whole file” is not a reasonable policy.

Business Associate Agreements Don’t Eliminate the Risk

A signed BAA with your clearinghouse or vendor doesn’t mean you can send them unrestricted PHI for any purpose. The BAA governs the ongoing operational relationship. Ad hoc sharing for troubleshooting falls under the minimum necessary analysis — and if the shared data exceeds what’s needed, the BAA doesn’t cover the excess.

You have a few practical options when you need to share EDI data without exposing the underlying PHI.

Option 1: Manual Redaction

You can open the file in a text editor, find every NM1, DMG, and CLM segment, and replace the real values with placeholder text. This works for a single transaction. For a batch of 500 claims, it’s not realistic — and it’s error-prone, since PHI appears in multiple segments and loops that are easy to miss.

Option 2: Scripted Anonymization

A scripted approach — a Python or shell script that parses EDI segment structure and replaces identifier fields with synthetic values — is more consistent than manual edits and can handle batch files. The challenge is that EDI structure is context-dependent: the same NM1 qualifier means different things in different loops, and a naive find-replace can corrupt the file’s referential integrity.

A good anonymization script needs to:

Parse loop and segment context, not just segment IDs
Replace names, DOBs, and identifiers with structurally valid synthetic values
Preserve the file’s validity for parsing and testing purposes
Handle multiple transaction sets within a single interchange envelope

Option 3: Purpose-Built Tools

Purpose-built EDI anonymization tools handle the parsing complexity and give you a file that’s safe to share without spending engineering time on a custom script.

EDI Paisan’s Anonymization Feature

EDI Paisan includes a built-in PHI anonymization tool designed for exactly these scenarios.

When you need to share an EDI file for support, testing, or vendor integration work, you can run it through the anonymizer first. It identifies PHI-carrying segments across 837P, 837I, 835, 270, and 271 transactions — names, dates of birth, member IDs, SSNs, claim IDs — and replaces them with realistic synthetic values that preserve the file’s structure and validity.

The anonymized file is safe to email, attach to a ticket, or hand to a vendor without exposing real patient data. The structure remains intact so the recipient can actually use it for debugging or testing.

This isn’t about compliance theater. It’s about removing the path of least resistance that leads to unnecessary PHI disclosures — which happen not because people are careless, but because the right tool wasn’t in the workflow.

If you’re already using EDI Paisan for claim validation or remittance reconciliation, the anonymizer is available from the same interface.

Quick Reference: PHI by Transaction Type

PHI Field	837P	837I	835	270	271
Patient Name	✓	✓	✓	✓	✓
Patient Date of Birth	✓	✓	—	✓	✓
Subscriber Name	✓	✓	✓	✓	✓
Subscriber Date of Birth	✓	✓	—	✓	✓
Member / Beneficiary ID	✓	✓	✓	✓	✓
Social Security Number (legacy)	✓	✓	—	✓	—
Dates of Service	✓	✓	✓	—	✓
Diagnosis Codes (ICD-10)	✓	✓	—	—	—
Procedure Codes (CPT/HCPCS)	✓	✓	✓	—	—
Patient Account Number	✓	✓	✓	—	—
Claim Reference Number	—	—	✓	—	—
Coverage / Benefit Detail	—	—	—	—	✓
Rendering Provider NPI	✓	✓	✓	—	—
Admission / Discharge Dates	—	✓	—	—	—

Notes:

NPIs are not PHI on their own (they’re provider identifiers, not patient identifiers), but they do appear in files containing PHI and may be relevant in certain disclosure analyses.
SSN use in EDI is largely deprecated but persists in legacy trading partner configurations and archived data.
The presence of a field depends on the trading partner agreement and transaction configuration; not every field is mandatory in every implementation.

The Bottom Line

EDI files are not logs. They’re not configuration files. They’re structured healthcare transactions containing real patient names, dates of birth, insurance identifiers, diagnoses, and procedure histories.

Every time you share one of these files — for support, for testing, for onboarding — you’re making a disclosure decision. HIPAA’s minimum necessary standard applies to that decision whether or not you’re thinking about it in those terms.

The practical answer isn’t to stop sharing EDI files. It’s to have a path between “send the raw file” and “spend three hours manually redacting it.” Anonymization before sharing is that path — and it should be as natural as opening the file in the first place.