HIPAA and Payment Processing: Merchant Guide

Last updated: 27 May 2026

If you run a healthcare practice in the US and you take card payments over the phone, you're sitting at the intersection of two federal rulebooks: HIPAA and PCI DSS. They were written by different people, for different reasons, and they don't always agree on what "secure" means. But when a patient reads out their Visa number to your front desk, both rules apply at the same time.

This guide walks through what HIPAA actually requires of you when payment data and patient data sit in the same call, what a Business Associate Agreement does, and the specific things to look for in a payment processor before you sign anything. If you'd rather read the broader vendor-selection lens first, our companion guide on HIPAA-compliant credit card processing covers the marketing-claim side and the BAA negotiating points. For the operational view of how claims move and pay across a US insurer or TPA, see the claims processing software guide.

The 30-second HIPAA primer#

HIPAA is the Health Insurance Portability and Accountability Act, signed into law in 1996. The part that matters here is the Privacy Rule and the Security Rule, both enforced by the Department of Health and Human Services Office for Civil Rights — usually shortened to HHS OCR.

HIPAA applies to two types of organizations:

• Covered entities. Healthcare providers (hospitals, clinics, dentists, therapists), health plans (insurers, HMOs), and healthcare clearinghouses.
• Business associates. Any vendor that handles Protected Health Information (PHI) on behalf of a covered entity. Billing companies, EHR vendors, transcription services — and sometimes, payment processors.

The HITECH Act of 2009 added teeth: breach notification became mandatory, and business associates became directly liable for their own HIPAA violations rather than just contractually liable to the covered entity. Before HITECH, OCR could only chase the covered entity when a vendor screwed up. After HITECH, the vendor is on the hook directly — which is why every modern BAA spends so much space on subcontractor flow-down.

Privacy Rule vs Security Rule — what each one actually does#

People talk about "HIPAA" as if it's one document. It isn't. There are three rules that matter for payments, and they regulate different things.

The Privacy Rule (45 CFR Parts 160 and 164, Subparts A and E) governs the use and disclosure of PHI. It defines what counts as PHI, who's allowed to see it, what counts as treatment, payment, and operations (TPO) — the three uses where PHI can move without explicit patient authorization — and what a covered entity has to tell patients about their privacy practices via a Notice of Privacy Practices. The Privacy Rule is where the "minimum necessary" principle lives: don't share more PHI than the person on the other end actually needs to do their job.

The Security Rule (45 CFR Part 164, Subpart C) governs electronic PHI specifically. It's organized into three categories of safeguards. Administrative safeguards cover policies, training, risk analysis, and workforce sanctions. Physical safeguards cover facility access, workstation security, and device disposal. Technical safeguards cover access controls, audit logging, integrity controls, transmission security, and authentication. Each safeguard is flagged as either "required" or "addressable" — "addressable" doesn't mean optional, it means you have to either implement it or document why you didn't and what you did instead.

The Breach Notification Rule (45 CFR §§164.400-414) governs what happens after something goes wrong. It defines what counts as a breach, the timelines for notifying patients, HHS, and (for big breaches) the media, and the content requirements for those notifications.

For phone payments, all three rules are in play. The Privacy Rule decides whether your agent is allowed to talk about the procedure on the call. The Security Rule decides whether your recording infrastructure is good enough. The Breach Notification Rule decides what you do when the recording server gets hit.

What counts as PHI in a payment conversation?#

PHI is any health information tied to an identifiable individual. The obvious things are diagnosis, treatment, lab results, and prescriptions. The less obvious things — and the ones that trip up payment teams — are:

• The fact that a person is your patient at all
• The name of the clinic or department they're paying (a payment to "Boston Oncology Associates" is itself PHI)
• The invoice number, if it ties back to a specific procedure
• The amount, when paired with a service date that reveals something about the care
• Voice biometrics in the call recording — HHS treats voice as a biometric identifier under the 18 HIPAA identifiers list
• The phone number the patient called from, when paired with anything that ties it to a treatment context

The card number itself isn't PHI. But the conversation around the card number almost always is. That's the bit people miss.

Where HIPAA ends and PCI DSS begins#

PCI DSS is the Payment Card Industry Data Security Standard. It's not a federal law — it's a contract enforced by the card brands (Visa, Mastercard, American Express, Discover, JCB) on anyone who accepts their cards. Version 4.0.1 is the current standard, and 4.0 became mandatory in March 2025.

Here's the split:

• HIPAA protects the patient's health information.
• PCI DSS protects the cardholder's payment information.

When both pieces of data exist in the same phone call, you have to satisfy both standards. A breach that exposes card numbers and the fact that those cards belonged to patients can trigger PCI fines from the card brands and HIPAA penalties from OCR. For deeper context on the PCI side, our piece on PCI DSS v4 for US contact centers walks through the v4.0.1 changes that affect telephony.

The Business Associate Agreement (BAA)#

This is the document that decides whether your payment processor is part of your HIPAA compliance story or a liability sitting on your balance sheet.

If a vendor touches PHI on your behalf, HIPAA requires you to have a signed BAA in place before they handle any data. The legal basis is 45 CFR §164.502(e). The BAA spells out what the vendor will and won't do with PHI, how they'll protect it, what they'll do if there's a breach, and what happens when the contract ends.

Most generic payment processors don't sign BAAs as a default. Some flatly refuse. A few will sign one if you ask, but only after they've reviewed your specific use case. Before you commit to any processor, ask three things in writing:

1. Will you sign a BAA covering the payment workflow we've described?
2. Do you store, transmit, or have access to any data that could be considered PHI?
3. If we route calls through your system, can patient identifiers appear in your call recordings, transcripts, or metadata?

BAA negotiation playbook — the clauses to push back on#

A BAA is a contract, not a form. Most vendor templates are written from the vendor's risk position, not yours, and a privacy officer's first read should be a redline rather than a signature.

The first clause to read carefully is the indemnity cap. Many vendor templates cap liability at "12 months of fees paid" — which on a $2,000/month payment processor is $24,000 against a HIPAA fine that can run to seven figures plus a corrective action plan. Push for either an uncapped indemnity for breach scenarios specifically, or a cap that scales with the number of records the vendor handles for you, or at minimum a multiple of fees rather than a single year.

The second is the subcontractor flow-down. HIPAA requires business associates to bind their subcontractors with equivalent BAAs. The vendor's cloud provider, telephony carrier, recording platform, AI transcription tool, and any analytics vendor all need to be in scope. Templates that say "the BA may use subcontractors that have agreed in writing to comparable obligations" with no specifics are too soft. Ask for the actual subcontractor list, ask to be notified of changes, and ask whether the vendor will indemnify you if a subcontractor breach is traced back to a missing or weak downstream BAA.

The third is the breach notification window. HIPAA gives covered entities 60 days from discovery to notify patients, and the vendor's job is to give you enough notice to meet that clock. Templates that say "as soon as reasonably practicable" or "within 60 days" are giving the vendor your entire notification budget. Push for 5 business days from the vendor's discovery, with daily updates once an incident is declared. If the vendor can't tell you in writing how their security team triages a suspected incident, that's a flag.

The fourth is the return or destruction of PHI on termination. The HIPAA-required language says "return or destroy all PHI, or if return or destruction is not feasible, extend the protections of the agreement to the PHI and limit further uses and disclosures." Vendors often want the "not feasible" exception broadly. Ask what specifically isn't feasible, why, and what the ongoing controls look like. Backup tapes get cited a lot here — fine, but the agreement should still say when those tapes age out.

The fifth is the audit right. You're allowed to audit your business associates' compliance with the BAA. Many templates restrict this to "reasonable notice during business hours" and exclude audits triggered by suspected breaches. Push for the right to commission an independent audit at your cost, with results shared, and a separate right to send your own team in if a breach has been declared.

Vendor due diligence — the checklist#

Before a BAA is signed, you should have answers to a short list of operational questions. None of these are about the vendor's brochure; they're about how the vendor actually runs.

• SOC 2 Type II report covering the last 12 months, with the scope and exceptions sections read by your security team, not just the auditor's opinion page.
• Current PCI DSS Attestation of Compliance showing service-provider Level 1 status if the vendor processes cards, with the named QSA and validation date.
• HITRUST CSF certification is a plus in US healthcare but not mandatory; if the vendor cites it, ask for the report.
• Penetration test summary from the last 12 months, scoped to the systems handling your data.
• Incident response plan with named roles, escalation paths, and a sample timeline from a previous incident if available (redacted is fine).
• Background check policy for staff with access to PHI — most US healthcare buyers require it.
• Training records showing HIPAA training on hire and annually, with completion rates.
• Disaster recovery test results — when was the last full DR exercise, what was the RTO, did it meet target?
• Encryption details in writing — AES-256 at rest, TLS 1.2+ in transit, key management approach, who holds the keys.
• Access logging — who can see your data, how is access logged, how long are logs retained, can you request a log extract on demand?
• Subprocessor list with named entities, the data they touch, and the jurisdiction they operate in.
• Breach history — has the vendor had a reportable HIPAA breach in the last five years, what happened, what changed?

A vendor that has done this work before should be able to send most of that packet under NDA within 48 hours. If it takes weeks, treat that as a data point.

The phone-payment problem#

Most modern payment processors are built for online checkout — you bolt a hosted form into a web page, the patient types their card in, you never touch the digits. That model works for the patient portal. It doesn't work when someone calls your billing office and says "I want to pay over the phone, I don't have a computer in front of me."

The traditional approach is to ask the patient to read the card number out loud. That's a bad idea for two reasons. First, your agent now has the card number — which drags your contact center fully into PCI DSS scope. Second, your call is almost certainly being recorded for quality and training purposes, and those recordings now contain card data, sometimes alongside discussion of the patient's treatment.

That's a double-headed compliance problem: a PCI breach waiting to happen sitting on the same audio file as a HIPAA breach waiting to happen.

How DTMF masking solves the payment side#

DTMF masking is the standard fix for phone payments. The patient stays on the line with the agent and types their card details on their phone keypad instead of reading them out. The system masks the tones (the agent hears flat beeps, not the actual digits), captures the digits in a separate channel, sends them straight to the payment gateway, and writes nothing card-related to the call recording.

For PCI DSS, this is a big deal — your contact center moves from full scope to a much-reduced scope, because card data never enters your environment. Most call recordings, agent screens, and CRM systems stay completely clean of card numbers. Our guide to channel separation covers the architectural pattern in more detail.

For HIPAA, DTMF masking doesn't solve the PHI problem on its own — your agent is still talking to a patient about their care. But it does mean the card data isn't sitting alongside the PHI in your recordings, which materially reduces the blast radius of any single breach. Even better, with the right routing, you can pause the recording during DTMF capture entirely so the silent stretch where the patient is typing produces zero audio at all — useful evidence in an OCR investigation that your control was working as designed.

Telephony-specific HIPAA risks worth naming#

Beyond the card-data issue, phone-based PHI work has a handful of specific failure modes that show up in OCR investigations again and again.

The first is voicemail leakage. Leaving a detailed message on a patient's answering machine that someone else in the household hears is a Privacy Rule disclosure to an unauthorized person. The fix is a documented voicemail policy: name and callback number only, no procedure detail, no balance amount.

The second is warm transfers between departments. The agent who takes the initial call summarizes the patient's situation for the next agent before connecting them. If that summary is recorded and gets shared more broadly than the original consent contemplated, you've potentially crossed a minimum-necessary line. The fix is structured transfer scripts and recording controls that pause during inter-agent briefings if the briefing would expand the disclosure circle.

The third is shared workstations. A billing rep walks away from their desk while a patient's record is on screen. Anyone who walks past sees PHI. The fix is short auto-lock timers (60 seconds is reasonable), privacy screens on monitors visible from waiting areas, and clean-desk enforcement.

The fourth is call analytics. Many contact centers now run speech-to-text on every call to detect compliance phrases, agent sentiment, or upsell opportunities. If that text is stored without the same controls as the audio, you've created a parallel PHI database that often isn't covered by the existing BAA. Either bring the analytics vendor under a BAA or scope your retention so the text is auto-purged on a tighter schedule than the audio.

The fifth is screen sharing during support. When a billing agent shares their screen with a patient — to walk them through their statement, for example — anything visible on the shared screen at that moment becomes a disclosure. The fix is a sanitized agent UI that hides irrelevant patient data during screen-share sessions.

What healthcare-grade payment processing actually looks like#

When you're shopping for a phone payment solution for a covered entity, the checklist is longer than the standard PCI one:

• PCI DSS Level 1 certification for the processor or service provider
• A signed BAA if any PHI could plausibly cross the system
• Card data captured outside your environment — DTMF masking, channel separation, or a hosted IVR
• No card data in call recordings (verifiable, not just promised)
• Tokenization for stored cards if you take recurring payments or store cards on file for future use — see our explainer on what tokenization actually does
• Audit logs tied to the agent, the patient account, and the transaction — for both HIPAA and PCI audits
• A clear position on what happens to the call metadata (phone numbers, timestamps, durations) — these can be PHI in healthcare contexts
• IVR or hosted payment option for after-hours payments without a live agent — our IVR payment guide walks through the trade-offs

EDI X12 and the payment workflow#

HIPAA mandates standard electronic transaction formats for healthcare billing under the Administrative Simplification provisions. These are ASC X12 standards, and the ones you'll meet most often in a payment workflow are:

• 837 — healthcare claim. The provider sends this to the payer to bill for services rendered. There are three variants: 837P (professional), 837I (institutional), and 837D (dental).
• 835 — healthcare claim payment / advice. The payer sends this back to confirm what they're paying, what they're denying, and why. The 835 is also the document that drives the matching of payer remittances to the original claim — without it, posting payments back into your accounting becomes manual labor.
• 270/271 — eligibility inquiry and response. The provider asks whether a patient is covered; the payer responds with the coverage details.
• 276/277 — claim status request and response. Used for the "where's my payment" follow-up loop.
• 278 — referral certification and authorization, used for pre-authorization workflows.
• 820 — premium payment, used for employer-to-payer premium remittances.

For a healthcare provider taking a phone payment from a patient, the X12 layer mostly lives behind the scenes — the patient pays a balance, the provider's system applies that payment, and the 835 from the payer was already booked separately. But for self-insured employers, TPAs, and any payment-side integration with the payer, X12 is the lingua franca. Any vendor that says "we handle EDI integration" without naming the specific transaction sets they support is waving.

Breach notification timeline — what actually has to happen#

The Breach Notification Rule is where most healthcare leaders pay closest attention because it's where the public consequences land.

A breach is the acquisition, access, use, or disclosure of PHI in a manner not permitted by the Privacy Rule that compromises the security or privacy of the PHI. There's a four-factor risk assessment to decide whether an incident actually rises to a breach — most incidents involving unencrypted PHI do.

Once you've confirmed a breach affecting fewer than 500 individuals, you have 60 days from discovery to notify affected patients and you have to log the breach for annual reporting to HHS — the deadline for the annual report is within 60 days of the end of the calendar year.

For breaches affecting 500 or more individuals, the 60-day clock to notify patients still applies, but you also have to notify HHS within 60 days (not annually), and you have to notify prominent media outlets in the affected state. HHS lists these large breaches on its public "Wall of Shame" portal at hhs.gov, which becomes one of the first places journalists and regulators look.

On top of the federal clock, every US state has its own breach-notification law. California's Civil Code §1798.82, New York's SHIELD Act, Texas's Business and Commerce Code §521.053, Massachusetts's 201 CMR 17.00 — they all impose their own notification windows and content requirements, and most of them require notification to the state Attorney General as well as affected residents. The state windows are sometimes tighter than 60 days. California requires "in the most expedient time possible and without unreasonable delay" with a 90-day backstop; New York requires notification "in the most expedient time possible and without unreasonable delay" and the SHIELD Act expanded the definition of private information in 2020.

A breach affecting patients in multiple states triggers parallel reporting obligations under each state's law. Your incident response plan needs a state-by-state matrix, not just a HIPAA flowchart.

State laws layered on top#

Two state regimes get cited often enough to be worth naming for healthcare payment work.

The New York SHIELD Act (Stop Hacks and Improve Electronic Data Security Act) took effect in March 2020. It applies to any business that holds private information on New York residents — not just New York businesses. "Private information" was expanded in 2020 to include biometric data, email addresses with passwords or security questions, and health information. The act requires reasonable administrative, technical, and physical safeguards — broadly mirroring the HIPAA Security Rule but with the New York AG as an enforcement actor. For a healthcare provider with patients in New York, the SHIELD Act is effectively a parallel HIPAA-like obligation.

California's SB 130 updates and the Confidentiality of Medical Information Act (CMIA, California Civil Code §56) impose obligations on top of HIPAA for any health information about California residents. CMIA covers entities HIPAA doesn't reach (some employers, some marketing organizations) and gives patients a private right of action — meaning patients can sue directly for CMIA violations, which they can't do under HIPAA. Statutory damages under CMIA start at $1,000 per violation, and class actions are common.

Massachusetts's 201 CMR 17.00 requires a written information security program for any business that holds personal information about Massachusetts residents, with specific technical requirements (encryption of laptops and portable devices, secure user authentication, monitoring of records). Healthcare data is in scope.

The takeaway: HIPAA is the federal floor, not the ceiling. Any nationwide healthcare operation has to layer state requirements on top, and the state with the tightest rule effectively sets your operational standard.

What the penalties actually look like#

HIPAA penalties are tiered by the level of culpability and inflation-adjusted annually. After the 2023 OCR penalty adjustment, the bands run from a minimum of $137 per violation at Tier 1 (no knowledge) to a maximum of $2,067,813 per violation at Tier 4 (willful neglect, not corrected), with an annual cap that reached $1,919,173 per identical violation category in the 2023 update. OCR adjusts these for inflation each year; check the current figures on the HHS Federal Register notices before quoting them to your board.

Recent settlements give you a sense of scale. Anthem paid $16 million in 2018 over a breach that exposed nearly 79 million records — the largest HIPAA settlement on record. Premera Blue Cross paid $6.85 million in 2020 after a breach affecting around 10.4 million people. Memorial Healthcare Systems paid $5.5 million in 2017 over a breach where employees and an affiliated physician practice accessed PHI without authorization, and the system's auditing controls didn't catch it for over a year. Most enforcement actions are smaller — six figures rather than seven or eight — but they almost always come with multi-year corrective action plans (CAPs) that cost more than the fine itself.

The CAP is often the underappreciated cost. A typical CAP runs three to five years and requires the entity to revise policies, retrain staff, submit to ongoing monitoring by an independent assessor approved by OCR, file regular compliance reports, and notify OCR of any incident that might be a breach. The compliance team and external assessor cost on a five-year CAP for a mid-size health system is routinely in the seven figures over the life of the CAP.

PCI DSS penalties don't come from a regulator. They come from your acquirer, who's been levied by the card brand. Typical numbers are $5,000 to $100,000 per month until you remediate, plus forensic investigation costs, card reissuance costs, and potential class actions if cards are misused. Combined with the HIPAA exposure, a single multi-vector breach can run a healthcare organization $20-50 million all in once you add legal, notification, credit monitoring, and remediation costs.

Where Paytia fits#

We're a PCI DSS Level 1 service provider, certified since 2016, and we've processed more than $500 million in card payments through our DTMF-masking platform. Our US operation is based in New York.

We're a payment security layer, not a healthcare workflow vendor. We don't manage PHI, we don't replace your EHR or billing system, and we're not a HIPAA-native platform in the way a clinical software vendor is. What we do is take the card data out of your call recordings, your agent screens, and your contact center environment — which addresses the PCI side of the healthcare phone-payment problem and reduces the surface area for the HIPAA side.

If you're a covered entity and you want to take card payments over the phone with a vendor that signs BAAs, talk to our New York team. We'll walk through what data actually crosses our platform and confirm whether a BAA makes sense for your specific setup.

Recent enforcement cases — what OCR has been chasing#

The pattern of recent OCR settlements tells you what the agency is paying attention to. A few that should be on every healthcare privacy officer's reading list.

Banner Health (2023) paid $1.25 million over a 2016 cyberattack that exposed PHI of 2.81 million people. The OCR resolution found Banner failed to conduct an accurate and thorough risk analysis, failed to monitor system activity, and didn't have adequate technical safeguards in place. The corrective action plan ran two years and required Banner to overhaul its risk analysis program. The lesson: "we have antivirus" isn't a risk analysis. OCR wants to see a documented, refreshed, organization-wide assessment of where PHI lives and how each location is protected.

Yakima Valley Memorial Hospital (2023) paid $240,000 after 23 security guards used a shared login to access PHI of 419 patients without legitimate purpose — basically nosy snooping into VIPs and acquaintances. The OCR finding cited inadequate access controls and inadequate auditing of system activity. The lesson: shared credentials are a single point of catastrophic failure, and the controls around access need to be matched by controls around monitoring of access.

Doctors' Management Services (2023) paid $100,000 in OCR's first-ever ransomware settlement, over a 2017 incident that exposed PHI of 206,695 people. The finding cited failure to conduct an accurate risk analysis and insufficient monitoring. The lesson: ransomware is now an OCR enforcement category in its own right, and ransom payment alone doesn't reset the regulatory clock.

iHealth Solutions LLC (2023), a business associate, paid $75,000 over a 2017 breach exposing PHI of 267 patients. The case is notable because it's OCR enforcement against a business associate directly, post-HITECH — the covered entity wasn't separately fined, but the BA was. The lesson: business associates can no longer hide behind the covered entity.

The patterns across these cases: missing or stale risk analysis, weak access controls, inadequate monitoring, and slow detection of incidents. None of these are exotic. The fix is operational discipline more than new technology.

An incident response plan that survives first contact#

Most healthcare organizations have an incident response plan on paper. Fewer have one that works on the day the alert fires. The pieces that distinguish a working plan from a paper one are worth naming.

A named on-call privacy officer with the authority to declare a breach and trigger notification preparation. Not "escalate to legal," which adds a day or two during which the notification clock is ticking. Someone who can make a call.

A pre-built notification template that meets the HIPAA content requirements (45 CFR §164.404(c)): brief description of what happened, types of PHI involved, steps individuals should take, what the covered entity is doing to investigate and mitigate, contact information. Pre-built so the legal review on the day takes hours, not days.

A vendor contact map with the named contact at every business associate in scope, escalation paths, and the BAA's notification SLA captured against each vendor. When the incident starts at a vendor, you need to know who to call and when to expect updates.

A state-by-state notification matrix covering the states where your patients reside, with each state's notification timeline, AG notification requirement, and content rules captured. Pre-built so it's a lookup on the day rather than a research project.

A credit monitoring contract with a vendor that can scale on short notice. Most large breach notifications include an offer of credit monitoring; sourcing this in the middle of an incident wastes precious days.

A communications plan covering patient call center scripts, website FAQ, media holding statements, and internal staff briefing. The first 48 hours after a public breach announcement generate a wave of inbound questions; being ready for them is what protects the brand.

Run the plan as a tabletop exercise at least annually. The first time you walk through it, you'll find the gaps. The point of running it in advance is to find them before they cost you.

Annual housekeeping — the rhythm OCR expects#

HIPAA compliance isn't a one-time setup. The Security Rule expects an ongoing cadence of administrative work, and the absence of that cadence is what OCR investigators latch onto when something goes wrong. The annual rhythm a covered entity should be running looks roughly like this.

Risk analysis refresh. At least annually, and whenever there's a material environment change (new vendor, new system, new integration, breach, merger). The refresh should produce a documented output a regulator can read, not just an internal slide deck.

Workforce training. On hire and at least annually for everyone with access to PHI. The training should cover the Privacy Rule, the Security Rule, the entity's specific policies, and the most recent enforcement themes. Completion has to be tracked.

Business associate review. Walk through the list of business associates, confirm each BAA is still current, confirm each vendor's SOC 2 / PCI AOC is still current, flag any contract renewals coming up. Stale vendor inventories are an OCR audit finding.

Access review. Confirm that staff who left no longer have access, that staff who changed roles have access matched to their new role, and that privileged access is still justified. Most identity-and-access platforms can automate the review.

Incident response tabletop. Run the IR plan as an exercise at least annually. Find the gaps before they're real.

None of this is glamorous. All of it is what the difference between a routine OCR inquiry and a multi-year corrective action plan looks like in practice.

Frequently asked questions#

Does HIPAA certify payment processors?

No. HHS doesn't run a certification program for payment vendors, and the Office for Civil Rights doesn't approve anyone in advance. Any "HIPAA certified" badge on a processor's website is marketing shorthand, usually pointing to a SOC 2 Type II report or a HITRUST CSF certification. Those are useful evidence in due diligence, but they're not a regulatory finding. Real HIPAA compliance comes from a signed Business Associate Agreement, an architecture that handles PHI in line with the Security Rule's safeguards, and a breach response process that can meet the 60-day notification clock under 45 CFR 164.400-414.

What's the difference between HIPAA and PCI DSS for healthcare payments?

HIPAA protects patient identity and treatment information; PCI DSS protects the 16-digit card number. When a patient calls your billing office and pays for a procedure, both rulebooks apply to the same conversation at the same time. HIPAA is federal law enforced by HHS OCR. PCI DSS is a contract enforced by the card brands through your acquirer. A breach exposing card numbers tied to patient records can trigger PCI fines from the brands and HIPAA penalties from OCR in parallel, plus state-level actions under laws like California's CMIA and the New York SHIELD Act.

Do I need a BAA with my credit card processor?

It depends on what data crosses to the processor. If only a tokenized card and an opaque transaction reference reach the vendor, with no patient name, invoice tied to a procedure, or treatment context, a BAA may not be required. In practice most healthcare integrations pass at least a patient identifier alongside the payment, so most processors do end up needing one. The safest default is to ask for a signed BAA and have your privacy officer review the data flow against the vendor's answers. Get it in writing before any data moves.

How long do I have to report a HIPAA breach?

You have 60 days from discovery to notify affected individuals under the Breach Notification Rule at 45 CFR 164.400-414. For breaches affecting fewer than 500 people you can log the breach and report it to HHS annually within 60 days of year-end. For breaches affecting 500 or more individuals, you also have to notify HHS within 60 days and disclose to prominent media in the affected state. State laws layer on top — California, New York's SHIELD Act, Texas and Massachusetts each impose their own windows and Attorney General notification rules, and the tightest state effectively sets your operational clock.

What are the maximum HIPAA penalties?

After the 2023 OCR inflation adjustment, civil monetary penalties run from about $137 per violation at Tier 1 (no knowledge) up to $2,067,813 per violation at Tier 4 (willful neglect, not corrected), with an annual cap reaching $1,919,173 per identical violation category. OCR adjusts these figures each year. The fine itself is often the smaller cost — a corrective action plan typically runs three to five years and requires independent monitoring, ongoing reports, and staff retraining. For context, Anthem paid $16 million in 2018 over a breach of 79 million records, the largest HIPAA settlement on record.

The bottom line#

HIPAA and PCI DSS aren't optional and they aren't a one-time project. When you take phone payments in healthcare, you need a processor that understands both sides of the conversation — not just the card and not just the patient. Ask about the BAA. Ask about the call recordings. Ask about who sees what, and when.

Get those answers in writing, and the rest of the compliance story gets a lot easier to defend.