Healthcare payment processing in the US involves unique security and privacy challenges. Beyond standard PCI DSS payment rules, covered entities must protect PHI (Protected Health Information) under HIPAA. In fact, breaches in healthcare are extremely costly – healthcare data incidents averaged $10.93 million per incident in 2023. Any payment workflow that combines patient identifiers with billing or insurance data is subject to HIPAA.
At the same time, organizations must juggle multiple overlapping frameworks, including HIPAA (for Protected Health Information, or PHI), PCI DSS (for payment card data), and state health privacy laws. These regimes share standard controls, such as those required by both HIPAA and PCI, including strong encryption, strict access controls, activity logging, formal incident response, and rigorous vendor oversight.
A healthcare payment solution must therefore integrate safeguards that protect PHI with proven payment security measures. We will cover how HIPAA applies to billing, required contracts and documentation, technical security measures, portal design, EDI claims integration, and special scenarios (telehealth, mental health, DME) – along with ongoing compliance and state regulatory notes.
Under HIPAA, payment information becomes PHI when it is linked to an individual’s healthcare. The HIPAA Privacy Rule defines PHI as any health, treatment, or payment information that includes patient identifiers and is maintained by a covered entity or its business associates. So, a patient’s name and treatment, combined with billing details or an insurer’s claim response, are all considered PHI.
A credit card number by itself isn’t PHI, but “Visa ending in 1234 used for a root canal procedure” is explicitly protected (patient, procedure, and card match). Similarly, insurance claims data (e.g., EDI 837 or 835 transactions) are PHI because they contain patient IDs, dates, diagnoses, procedure codes, and payment details.
HIPAA specifically mandates use of standardized EDI formats (ANSI X12) for such transactions – e.g., X12 837 for claims and 835 for remittances. Therefore, any system processing claims or remittance advice must handle ePHI securely in accordance with HIPAA rules.
Payment processors for healthcare often occupy a gray zone under HIPAA. A pure credit card processor or bank is generally not considered a HIPAA business associate when simply authorizing transactions, as the regulations explicitly exclude regular financial services from HIPAA coverage. However, suppose a payment vendor performs additional tasks, such as storing PHI, integrating with the EHR, sending invoices, or reporting on patient balances. In that case, it is likely to become a Business Associate (BA).
In those cases, HIPAA requires a formal BAA with the provider. The BAA must impose all appropriate HIPAA safeguards on the vendor (such as encryption, access controls, breach notification, and auditability) and prohibit any unauthorized uses of the PHI.
Covered entities should vet any vendor handling payment data by asking: Does the vendor handle any patient health or treatment information alongside payments? Do they store claim explanations or billing records? Do they access the patient’s medical record system? If yes, a HIPAA BAA is required. Even when no BAA is needed, providers often still insist on HIPAA-grade security from the vendor as a best practice.
Key items to verify include:
One should require evidence that the processor uses tokenization or point-to-point encryption, never stores unencrypted card data, and regularly undergoes security audits.
Written contracts should clearly delineate the vendor’s scope and security obligations. Besides the BAA, providers should verify vendor compliance through documentation. So, review third-party audit reports (e.g., SOC 2 or HITRUST if available), request results of any HIPAA/PCI assessments, and ensure the processor carries cyber liability insurance.
Periodic reassessment is essential as a re-run of due diligence on vendors annually or when business needs change. All checks and agreements should be documented in the HIPAA compliance files to prepare for any audit by regulators.
Both covered entities and their BAs must maintain detailed records of HIPAA compliance activities. This includes written policies, risk assessments, training logs, security configurations, and evidence of access controls. In the context of payment processing, keep records of any encryption setup, key management, and audit trail configurations.
Regulators expect that, if a breach occurs, entities can demonstrate that they have implemented “reasonable and appropriate” safeguards. HIPAA guidance emphasizes that companies must document workforce training, risk analyses, system audits, and all incident responses to demonstrate their readiness for audit. A robust BAA, together with complete documentation, will satisfy the Privacy Rule’s requirements if patient payment data were ever at risk.
Whether on-prem or cloud-based, all systems processing patient payments must implement HIPAA’s technical safeguards. The Security Rule’s five technical standards – Access Control, Audit Control, Integrity, Authentication, and Transmission Security – apply fully to payment systems just as to any EHR component.
Key measures include:
All PHI and payment data must be encrypted both at rest and in transit. Card details and any linked billing info stored in databases must use strong encryption (AES-256 or higher is standard). Channels between point-of-sale terminals, web portals, and processors should use TLS 1.2 or later.
HIPAA explicitly includes encryption in its addressable list, meaning organizations must either implement it or justify an equivalent level of protection. Compliant payment systems utilize point-to-point encryption (P2PE) or tokenization, ensuring that raw card numbers are never stored on provider systems.
Technical controls must ensure that only authorized personnel and systems can access payment data. Each user (e.g., billing clerk, cashier) should have a unique login ID, with role-based permissions that limit access to PHI to the minimum necessary.
Multifactor authentication is strongly recommended, especially for remote access or administrative functions. Automatic logoff or session timeout must be enabled to prevent unattended terminals from leaking data. HIPAA’s Access Control rule mandates precisely this: unique IDs, emergency access protocols, and automatic logoffs, which align well with PCI requirements for strong access management.
Systems must log all access, transactions, and changes involving payment and PHI. This includes login attempts, payment authorizations, and administrative actions (like reversing a charge). The logs should be tamper-resistant and retained in accordance with HIPAA’s audit control requirements. Regular review of these logs is critical.
By correlating payment events with user IDs and timestamps, an organization can quickly detect anomalous activity (for example, a sudden surge in declined transactions or multiple failed logins might signal an attack). When used correctly, automated audit controls can alert staff to issues as they happen.
HIPAA’s contingency planning mandates data backup and a disaster recovery plan. For payment processing, backups should securely capture recent transactions, billing records, and configuration settings. These backups themselves must be encrypted and stored offsite or in a highly durable cloud vault.
Plans should be in place to restore operations with minimal downtime. Switching to a standby payment gateway in the event of a primary one failing. The HHS guidance on risk analysis explicitly notes that organizations should determine “what data to back up and how” as part of security planning. Regularly test backup integrity and recovery procedures (for example, by simulating a database restore) to ensure compliance in the event of an actual incident.
In combination, these technical safeguards ensure payment data is protected as rigorously as any other ePHI. They also overlap closely with PCI DSS measures, allowing healthcare organizations to leverage a single security framework often to satisfy both HIPAA and PCI requirements.
Online payment portals are increasingly common for patient billing. A HIPAA-compliant patient payment portal must be designed with privacy by default.
This means the portal’s architecture and user experience should explicitly enforce security, rather than treating it as an afterthought. Key requirements include:
1. Secure Authentication and Identity Verification:
Patients must create or use strong credentials to access the portal. Two-factor authentication (2FA) is strongly advised. Where possible, link portal accounts to verified patient records rather than open self-registration (to prevent impersonation). Implement account lockout after a specified number of repeated failed attempts.
On first-time payments, additional verification (e.g., confirming the last four of the SSN or sending a one-time code via email/SMS) can help confirm identity. The portal should also enforce strict session timeouts. HIPAA rules urge verifying patient identities, especially in remote interactions, which applies equally to portal logins.
2. HIPAA-Ready Design:
Keep PHI handling to a minimum. A portal might display charges but never show full medical details or diagnoses – only invoice codes and amounts. Any PHI shown (like procedure names) should be critical for billing clarity. The portal must use HTTPS (TLS) for all pages and avoid insecure components.
Additionally, adhere to good UX practices without compromising privacy: for example, use dynamic forms that only ask for necessary information (name, DOB) and avoid free-text fields for health details. A design tip from healthcare UX experts is to build tokenized and mobile-friendly checkouts.
Portals should be fully responsive and protect local data. Implement mobile security measures, such as disabling local storage of PHI, and utilize a Mobile Device Management (MDM) approach to enable remote wiping of app data in the event a device is lost.
3. Payment Method Security and Tokenization:
The portal should never store raw credit card numbers. Instead, it should use a PCI-compliant gateway or vault. Tokenization is ideal when the patient enters their card information once, receives a random token, and the portal saves only that token for future charges. This way, if the database is compromised, attackers find only meaningless tokens.
Many HIPAA-compliant payment vendors offer tokenization or point-to-point encryption (P2PE) solutions specifically designed for healthcare. As Clarity Ventures notes, “tokenized payment methods” simplify checkout while securing data. Support multiple payment methods (cards, ACH, mobile wallets) via secure, HIPAA-friendly APIs or SDKs.
4. Encryption in Transit:
All financial and patient data exchanged with the portal must be encrypted. This includes card entry fields, form submissions, and any linked EHR calls. Use TLS 1.2+ for APIs. If the portal interacts with other patient systems (such as retrieving a patient’s balance), ensure that those API calls also use secure channels.
5. Mobile Accessibility:
Patients increasingly pay bills on mobile. A portal must be both mobile-optimized and secure. Avoid storing PHI on the device; any client-side storage (such as cookies or localStorage) should only hold encrypted session tokens.
Offer biometric login (fingerprint/face ID) as an option, since HIPAA supports MFA. Thoroughly test the portal on both Android and iOS for potential security issues. (Healthcare UX experts note that HIPAA-compliant portals should implement strong authentication and be responsive on mobile.)
Payments in healthcare often tie into insurance adjudication processes. Electronic Data Interchange (EDI) transactions – notably ANSI X12 837 (claims), 835 (remittance), 270/271 (eligibility), and 276/277 (claim status) – must be secured end-to-end. Key points include:
All EDI files containing PHI should be exchanged via secure, encrypted channels. The common practice is to transmit 837 claims and receive 835 remittances over SFTP or HTTPS APIs using TLS. HIPAA-covered clearinghouses and payers typically require TLS 1.2 or higher for connectivity.
Even if EDI X12 formats themselves have no built-in encryption, the transport must. Some organizations also encrypt the file payload (e.g., PGP-encrypted .zip) before upload.
If using a clearinghouse or payer portal, treat it as a covered entity/business associate scenario. Ensure a BAA is in place for claims exchange. Confirm that the clearinghouse platform stores PHI and payments in compliance with HIPAA. According to industry guidance, many clearinghouses now implement AES-256 encryption on their servers and keep immutable logs of all transactions.
They might apply full-disk encryption (AES-256) on EDI databases and maintain write-once receipts for each claim/response pair. Providers should also configure audit logging on their own systems to record each outgoing claim file and incoming remittance.
When an insurer (such as Medicare) acts as the primary payer and must coordinate payments with a secondary payer, the 837 transaction can include COB (Coordination of Benefits) information. The same security measures apply; there are no separate HIPAA rules for COB, only that all PHI in those COB fields is protected.
Ensure that any secondary-claim workflows (e.g., sending a 837 COB to a secondary insurer) utilize the same secure EDI channels and comply with HIPAA and payer rules. (Some advanced clearinghouses provide specific COB transaction support.)
When patients have more than one insurer, there may be additional steps (like insurance follow-ups or patient-pay differences). Systems automating these tasks should still follow HIPAA safeguards. For example, if the practice sends remittance data to a billing vendor for secondary claims, that vendor is handling PHI and must have a BAA and secure processes.
Even automated provider-to-provider notifications (like notifying a patient’s auto insurer or workers’ comp) count as disclosures that need HIPAA safeguards.
Telehealth introduces unique compliance challenges because care and billing occur remotely, yet the same HIPAA Privacy and Security rules still apply. Virtual visits often rely on video apps or messaging platforms, so any system handling billing or payments must meet HIPAA standards. This includes using end-to-end encrypted audio/video channels, securely storing call logs or chat transcripts containing PHI, and requiring a Business Associate Agreement (BAA) when a telehealth vendor processes co-pays or credit cards.
A HIPAA risk assessment tailored to telemedicine workflows helps confirm that all integrations, from scheduling to claim submission, use secure APIs, encryption, and proper access controls.
Licensure and payment rules create additional complexity. Providers must be licensed in the patient’s state or participate in an interstate licensure compact, and insurers may impose state-specific telehealth coverage requirements. To avoid denied claims, providers should verify and document the patient’s location and consent at every session and ensure compliance with applicable interstate agreements. Proper identity verification, such as secure logins, multi-factor checks, or secondary video ID, further protects against fraud and confirms that services are delivered to the correct patient.
Secure telehealth billing means combining HIPAA-compliant technology with careful administrative safeguards. From encrypted video visits and secure EHR/billing integrations to state-specific licensing checks and patient identity confirmation, each step must be documented and audited. These measures help prevent data breaches, fraud, and payment rejections while ensuring patients receive safe, verifiable virtual care.
Behavioral health billing requires additional safeguards due to heightened privacy protections. Under HIPAA, psychotherapy notes, therapists’ detailed session records, are stored separately from standard medical records and generally cannot be shared without the patient’s specific authorization. Claims should contain only essential billing details such as diagnosis codes and session length.
Practices must ensure their EHR and billing systems clearly flag psychotherapy notes and prevent them from being exported or accidentally included in claims, electronic remittance advices (ERAs), or payment fields where privileged details might appear.
Substance use disorder (SUD) treatment carries even stricter confidentiality under federal 42 CFR Part 2 rules. Except in limited cases (e.g., court order), SUD records cannot be disclosed for payment or operations without explicit patient consent. Although recent HHS updates allow a single consent for future disclosures, providers must still obtain comprehensive patient authorization before transmitting SUD-related claims.
Billing systems often rely on specialized payer codes and isolated claim workflows to maintain the separation of SUD data, and explanations of benefits (EOBs) must align with the scope of consent. All electronic exchanges of Part 2 data should be secured by strict policies and appropriate business associate agreements to prevent unauthorized sharing.
Durable Medical Equipment (DME) billing is more complex than standard medical claims because it often requires prior authorization and different handling for rentals versus purchases. Before submitting a claim, providers may need to send documentation (for example, diagnostic test results) through encrypted email, secure eFax, or insurer APIs, all of which are covered by a Business Associate Agreement (BAA). These secure channels ensure that protected health information (PHI) and billing codes remain confidential throughout the authorization and claim preparation process.
Within the EHR or billing system, DME workflows must be able to distinguish between rental and purchase claims. Rentals typically involve monthly billing, while purchases are billed as a single lump sum, and both must meet HIPAA requirements. Recurring credit card payments, for instance, should rely on tokenization and secure payment profiles. The same care applies when exporting DMEPOS claim forms (such as the 837D) to clearinghouses, which must support encrypted transmission.
Because DME transactions can be high-value and long-term, practices should verify insurance benefits upfront to avoid denials and maintain detailed audit trails of authorizations, claims, and patient communications. Patient portals or payment plans that store card information for recurring charges must protect tokens as PHI-linked financial data. In short, successful DME billing combines strict HIPAA security with meticulous workflow design to safeguard PHI while ensuring accurate and auditable complex rental and purchase payments.
HIPAA compliance is an ongoing process. For payment processing, organizations should institute continuous risk management and training:
The HIPAA Security Rule requires an “accurate and thorough” risk analysis of all electronic protected health information (ePHI) systems. For payment systems, this means identifying potential threats (e.g., malware on POS devices, insecure network links to the gateway) and vulnerabilities (outdated terminals, weak passwords). Use the risk analysis to prioritize safeguards.
If the assessment finds that data backup procedures are inadequate, remediate this under 164.308(a)(7). Periodically (at least annually), review and update the risk analysis to reflect new threats, such as emerging payment fraud schemes or software changes.
While HIPAA does not explicitly mandate penetration testing, it does encourage “good faith” measures to secure systems. It is best practice to conduct periodic vulnerability scans and penetration tests on payment systems and networks to identify potential security risks.
Any issues found (such as outdated SSL libraries or open ports on payment servers) should be remediated promptly. The results of these tests should feed back into the risk management process.
All staff who handle patient payments (front desk, billing office, IT) need HIPAA security training. This includes recognizing phishing attempts (which could target payment information), understanding the importance of not sharing PHI over insecure channels, and following the proper procedures for handling credit card data.
Annual training refreshers and documentation of attendance are required. Additionally, role-based training for IT and compliance personnel should cover specific areas, such as secure EDI handling and incident protocols for payment systems. As one compliance guide notes, the workforce must understand its HIPAA obligations, and training should be ongoing to reinforce these concepts.
Have a written incident response plan that includes payment systems. If a breach involves payment data (e.g. ransomware encryption of billing records), the plan must specify internal notification, evidence preservation, and HIPAA breach reporting steps (60-day notice to patients/HHS for breaches over 500 records).
Test the plan with drills. Remember, in a breach of PHI involving financial information, both HIPAA and possibly PCI DSS breach rules may apply (PCI has its own incident procedures to notify card brands). Document every security incident, investigation, and remediation action.
Maintain logs of all compliance activities to present to auditors as needed. Keep copies of signed BAAs, risk assessment reports, penetration test summaries, and training records. Utilize automated tools whenever possible to monitor compliance controls across HIPAA and PCI.
The goal is to be prepared for any audit by HHS or card brands without scrambling – detailed documentation should always be within reach.
In addition to HIPAA, payment processors must heed state and federal rules:
Some states impose privacy protections that exceed HIPAA. For example, the Texas Medical Records Privacy Act extends HIPAA-like rights to a broader range of entities and prohibits the re-identification of de-identified PHI without explicit patient permission.
California and others have strong consumer data laws (e.g. CCPA/CPRA) – note, however, that these generally exempt HIPAA-covered entities for medical information. Still, providers should be aware of any state-specific mandates (such as stricter breach notification timelines or additional security requirements) that apply to patient billing data.
When billing Medicare or Medicaid, providers must use the mandated HIPAA-standard electronic transactions (5010-format EDI). They also must meet CMS’s security requirements for system access (for example, Medicare providers use CMS’s authentication and must follow its desktop security guidelines). Separate from HIPAA, CMS has rules governing telehealth coverage, DME reimbursement, and other related matters.
Medicare now permanently allows more telehealth services than before the COVID-19 pandemic (no longer limited to rural origin sites) and requires states to follow specific “fee parity” rules for Medicaid telehealth payments, unless CMS grants an exception. Providers should stay current with CMS advisories to ensure billing systems and payment processes are updated accordingly.
Medical devices that require online connectivity (like networked infusion pumps or imaging devices) may also trigger FDA cybersecurity guidance. If a payment system interfaces with an FDA-regulated device (e.g., charging patients for device-based services), ensure that the device’s own data security standards are met.
If a remote patient monitor bills the provider based on usage, the data pipeline from the FDA device to the billing system should use encryption and validate integrity. While HIPAA focuses on the PHI, FDA guidance can add device-level requirements (like software updates and vulnerability management), which indirectly impact payment security.
State laws on telehealth have proliferated. Currently, 23 states + DC require payment parity for telehealth under private insurance (meaning telehealth visits are reimbursed the same as in-person). Many state Medicaid programs also expanded telehealth coverage. However, the rules vary widely: some states cover audio-only counseling, while others limit telehealth codes to specific specialties, and so on.
Providers should consult state regulations when coding telehealth claims to ensure compliance with applicable laws and regulations. This regulatory patchwork also means billing systems must flexibly handle place-of-service (POS) codes and modifiers required by each state’s law.
Compliance requires adherence to both national HIPAA regulations and awareness of local rules. A healthcare provider in a multi-state network or an online telehealth company should maintain a legal guide or subscription service for state health payment laws. When expanding services or markets, review the state’s privacy protections, licensing reciprocity, and telehealth billing mandates to avoid potential missteps.
Any payment workflow that links patient identifiers with medical or billing details counts as PHI. This means that HIPAA rules apply in conjunction with PCI DSS whenever protected health information is involved.
If a vendor stores, accesses, or transmits PHI (e.g., invoices with treatment details or EDI claim data), they are a HIPAA Business Associate and must sign a BAA. Pure card authorization without PHI typically does not require a separate approval.
Core controls include end-to-end encryption (AES-256/TLS 1.2+), strong access controls with unique logins and MFA, audit logging, and encrypted backups with tested recovery plans.
Use secure logins with 2FA, tokenization to avoid storing card numbers, HTTPS/TLS encryption, minimal PHI display, and mobile-ready security features like remote wipe and short session timeouts.
Maintain signed BAAs, risk assessments, training logs, and penetration test reports. Perform annual risk analyses, document incident responses, and regularly review vendor compliance and state-specific privacy laws.
