HIPAA Compliance for Medicare Advantage Eligibility Verification: What You Need to Know

Why eligibility verification is a HIPAA activity

Every Medicare Advantage eligibility file your system receives contains Protected Health Information as defined under 45 CFR 160.103. The file includes member names, dates of birth, Medicare IDs, plan enrollment dates, and in some cases diagnosis codes and benefit codes. The moment that file lands in your SFTP inbox, HIPAA applies to everything downstream: how you store it, who can access it, what you log, and what happens when something goes wrong.

Most supplemental benefit vendors understand they are subject to HIPAA in a general sense. Fewer have mapped HIPAA requirements specifically to their eligibility verification workflow. This article does that mapping.

The Business Associate relationship

If you are a supplemental benefit vendor receiving PHI from a Medicare Advantage plan in order to provide services to that plan's members, you are a Business Associate under HIPAA. This is not a gray area.

The covered entity (the Medicare Advantage plan) must have a signed BAA with you before transmitting any PHI. You must have BAAs with any subprocessors that touch PHI on your behalf. The chain runs: Medicare Advantage Plan → you → your infrastructure providers (cloud, database, etc.).

This creates three specific obligations:

1. Purpose limitation. You may only use PHI for the purposes specified in the BAA — which for eligibility verification means: processing enrollment data, calculating billable days, generating invoices, and related billing operations. Using member PHI for any other purpose (analytics, marketing, product research) without specific authorization is a violation.

2. Safeguard implementation. You must implement the administrative, physical, and technical safeguards required by the HIPAA Security Rule (45 CFR Part 164, Subpart C). This is not optional and not delegated — even if your cloud provider is HIPAA-compliant, you are still responsible for your application layer.

3. Breach notification. You must report any breach of unsecured PHI to the covered entity within 24 hours of discovery, cooperate with their notification obligations to affected individuals, and bear the costs of breach mitigation attributable to your actions.

The four HIPAA Security Rule requirements most relevant to eligibility workflows

45 CFR 164.312(a)

Access control — who can see member data

You must implement unique user identification, automatic logoff after inactivity, and role-based access controls that enforce least privilege. In an eligibility workflow, this means:

• Not every user who can log into your billing system should be able to view raw member enrollment records
• API endpoints that return member-level PHI must require authentication and role validation on every request — not just at login
• Bulk PHI queries (returning hundreds or thousands of member records at once) should require elevated role authorization and be subject to record count limits

The minimum role that should be permitted to access member PHI should be defined explicitly in your access control policy, not left as a system default.

45 CFR 164.312(b)

Audit controls — logging every PHI access

Every access to PHI must be logged. The log entry must capture: who accessed it (user ID and email), when (timestamp), what resource was accessed (member ID, file ID), the source IP address, the outcome (success or failure), and whether the access involved PHI specifically.

These logs must be retained for a minimum of 6 years from the date of creation or the date they were last in effect, whichever is later. They must be immutable — no update or delete operations on audit records. And they must be filterable by date range, user, action type, and PHI access flag for audit response purposes.

An audit log that only records failed access attempts — or that does not log successful PHI reads — does not satisfy 45 CFR 164.312(b).

45 CFR 164.312(e)

Transmission security — how PHI moves

PHI must be encrypted in transit. TLS 1.2 is the minimum acceptable standard; TLS 1.3 is preferred. This applies to:

• Payer SFTP file delivery (must use SSH key-based auth, not password-only)
• REST API calls that carry member data (must use HTTPS with valid certificates)
• Internal service-to-service communication if it crosses network boundaries
• Email delivery of eligibility files (email attachments containing PHI must be encrypted or delivered via secure portal — unencrypted email containing member data is a violation)

PHI must also be encrypted at rest. AES-256 is the standard. This applies to your database, blob/file storage, backups, and any local caches.

45 CFR 164.308(a)(1)

Security management — risk analysis is required

The Security Management Process standard requires a formal, documented risk analysis of your information systems that handle ePHI. This is not a one-time activity — it must be reviewed and updated when there are significant changes to your environment (new payer integrations, new infrastructure, workforce changes) or at least annually.

The risk analysis must identify: what ePHI you hold and where it lives, what threats could affect the confidentiality, integrity, and availability of that ePHI, what vulnerabilities exist, and what the likelihood and impact of each risk scenario is. The output drives your risk management plan — the specific controls you implement to reduce risk to an acceptable level.

Vendors who skip formal risk analysis and rely instead on “we use a HIPAA-compliant cloud provider” are non-compliant regardless of their infrastructure choices.

The five most common HIPAA violations in eligibility workflows

1. Unencrypted SFTP credentials. Payer SFTP connections authenticated with reusable passwords instead of SSH keys. A compromised password gives an attacker access to every eligibility file in the inbox. SSH key-based authentication, key rotation, and per-payer credential isolation are required.

2. PHI in application logs. Debugging logs that write member IDs, names, or enrollment dates to stdout or log files that are not protected with the same controls as the primary database. Once PHI enters an uncontrolled log stream, it can flow to log aggregators, developer workstations, or third-party monitoring tools that are not covered by your BAA.

3. No audit trail for member data access. Application code that queries member records without writing an audit log entry. Common in systems where audit logging was added as an afterthought rather than built into the data access layer. If you cannot produce a log showing who accessed member Dorothy Hayes' enrollment record on February 3, 2025, you cannot respond to an OCR audit.

4. Overly broad data access. All authenticated users can access all member records regardless of role. A billing manager reviewing invoice totals should not have the same read access to raw member PHI as the operations engineer who needs to debug a processing error. Minimum necessary access is a HIPAA requirement, not a best practice.

5. Missing or unsigned BAA. Operating with a payer or subprocessor that has not executed a BAA, or relying on a BAA template that was never countersigned. Common during rapid onboarding when a new payer integration goes live before legal paperwork catches up. The technical integration being live does not satisfy the BAA requirement.

42 CFR Part 2 — the SUD exception you must know

This section covers a requirement that many Medicare Advantage supplemental benefit vendors are unaware of until they encounter it.

42 CFR Part 2 governs the confidentiality of Substance Use Disorder patient records. It is stricter than HIPAA in several ways: it requires explicit patient consent for most disclosures, it prohibits re-disclosure without patient authorization, and it carries criminal penalties for violations.

When does it apply to you? If any of your eligibility files contain benefit codes or diagnosis codes indicating SUD treatment — ICD-10 codes F10 through F19, benefit codes such as SUD, SA, DETOX, MAT, or OTP, or SUD-related procedure codes — those records are subject to Part 2 in addition to HIPAA.

What this means operationally:

• SUD-flagged records must be identified and segregated during file processing
• They cannot be included in standard eligibility reporting without patient authorization
• Access controls for SUD records must be stricter than for general PHI
• Audit logging for SUD record access must be tracked separately

What a HIPAA-compliant eligibility verification workflow looks like

A compliant workflow has six components. Each is required — not recommended, not best practice, required.

1. Signed BAA in place before first file transfer. No PHI transmitted, no SFTP connection opened, no API key issued until the BAA is executed and filed.

2. Encrypted transmission with key-based auth. All payer SFTP connections use SSH key authentication. All API endpoints use HTTPS with TLS 1.2+. No plaintext PHI in email unless delivered via a secure portal covered by the BAA.

3. PHI encrypted at rest. Member data encrypted with AES-256 in the database. Eligibility files encrypted in blob/file storage. Encryption keys managed in a dedicated key vault, not hardcoded or stored in application config.

4. Role-based access with minimum necessary. Named user accounts for all staff. Role assignments based on job function. Separate role levels for viewing member PHI vs. running bulk eligibility queries vs. exporting data. No shared credentials.

5. Immutable audit log for every PHI access. Every API call that returns member-level data writes an audit log entry with user ID, email, timestamp, resource ID, IP address, and PHI access flag. Audit logs are append-only, retained for 6 years, and filterable for OCR audit response.

6. Breach response plan with 24-hour notification capability. A documented procedure for identifying, containing, and reporting a PHI breach. The 24-hour notification clock to the covered entity starts at discovery — not at conclusion of investigation. You need to be able to notify within 24 hours even if the full scope of the breach is not yet known.

Data Subject Requests under state law — the layer on top of HIPAA

HIPAA is the federal floor, not the ceiling. Several states have enacted privacy laws that give individuals additional rights over their health data — including the right to request deletion of their records.

Here is where it gets complicated: HIPAA's record retention requirements (6 years for covered entity records, state medical record retention laws for clinical data) may directly conflict with a state-law deletion request. A member in California submitting a CCPA deletion request for their eligibility records cannot necessarily have those records deleted if retaining them is required by HIPAA or CMS audit obligations.

The correct response to a deletion request that conflicts with HIPAA retention requirements is a documented denial with explanation — not deletion, and not silence. The denial must reference the specific legal authority that overrides the deletion request and must be delivered within the timeframe required by the applicable state law (typically 30–45 days).

If your eligibility system has no process for receiving, logging, and responding to data subject requests, you have a gap — even if HIPAA alone does not require a formal DSR process.