Written and maintained by CASRAI Editorial Board
Last updated
Outpatient practice managers, healthcare compliance officers, and digital health engineers evaluating IntakeQ (and its full practice management suite, PracticeQ) use this reference to verify IntakeQ PCI compliance and HIPAA security controls—including how client-side payment tokenization isolates cardholder data from Protected Health Information (PHI), how Business Associate Agreements (BAAs) apply, and what administrative safeguards clinics must configure.
What Is IntakeQ PCI Compliance and Is IntakeQ HIPAA Compliant? (Short Answer)
Yes—IntakeQ is both HIPAA compliant for Protected Health Information (PHI) and PCI-DSS compliant for payment card processing through client-side tokenization. For clinical and intake data, IntakeQ executes formal HIPAA Business Associate Agreements (BAAs) with covered entities, encrypts all PHI in transit (`TLS 1.2+`) and at rest (`AES-256`), and undergoes annual third-party HIPAA compliance verification. For credit card and HSA/FSA copay collection, IntakeQ never stores raw Primary Account Numbers (PANs) or CVV security codes on its own application servers; instead, card data entered on digital intake forms or billing portals is captured and tokenized directly by integrated PCI-DSS Level 1 Service Providers (PracticeQ Payments, Stripe, or Square), returning only a non-sensitive cryptographic reference token to IntakeQ.
How IntakeQ Separates PCI-DSS Cardholder Data from HIPAA PHI
In healthcare revenue cycle and digital registration workflows, combining clinical intake questionnaires with credit card-on-file authorization creates dual regulatory obligations under the Payment Card Industry Data Security Standard (PCI-DSS v4.0) and the HIPAA Security and Privacy Rules (45 CFR Parts 160 and 164). IntakeQ’s architecture segregates these two data streams at the browser level:
| Compliance Domain | Governing Standard | IntakeQ / PracticeQ Technical Implementation | Data Stored in IntakeQ Database |
|---|---|---|---|
| Payment Card Processing (PCI-DSS) | PCI-DSS v4.0 (PCI Security Standards Council) | Client-side hosted payment fields (Stripe Elements, Square Web Payments SDK, or PracticeQ Payments) transmit PAN and CVV directly from the patient’s browser to the PCI Level 1 gateway | Zero raw cardholder data: Stores only the gateway reference token, card brand, last 4 digits, and expiration month/year |
| Protected Health Information (HIPAA) | 45 CFR § 164.308 (Administrative), § 164.310 (Physical), § 164.312 (Technical Safeguards) | End-to-end HTTPS/TLS 1.2+ transport encryption, AES-256 database and document storage encryption, automated session timeouts, and Compliancy Group audited controls | Encrypted clinical intake forms, e-signatures, patient demographics, progress notes, and superbill claims |
| Financial Clearinghouse Boundary | Social Security Act § 1179 & 45 CFR § 164.501 | Payment gateway receipts omit ICD-10-CM diagnosis codes and clinical narrative notes so that third-party card processors handle pure financial settlement without ingesting clinical PHI | Itemized CPT/ICD-10-CM superbills and clinical invoices remain inside the HIPAA-covered IntakeQ portal |
How Tokenized Credit Card Capture Works on IntakeQ Forms
When a practice adds a Credit Card Question or pre-visit deposit requirement to a digital patient intake form, the transaction follows a four-step PCI-scoped workflow:
- Iframe Isolation in the Patient Browser: The credit card number, expiration date, CVV, and billing ZIP code fields rendered inside the IntakeQ questionnaire are served from an isolated iframe controlled by the connected PCI-DSS Level 1 processor (`Stripe`, `Square`, or `PracticeQ Payments`).
- Direct Vaulting & Token Generation: When the patient submits the form, the payment fields post directly to the payment processor’s vault over TLS, which validates the card and returns a single-use or customer-bound cryptographic token (`tok_…` or `card_…`) to IntakeQ.
- Card-on-File & Automated Copay Charging: When an administrator or automated booking rule charges a copay, deductible, or no-show fee inside PracticeQ, IntakeQ sends the stored reference token and dollar amount to the processor API—meaning raw card numbers never traverse IntakeQ’s memory or logs.
- Merchant PCI Self-Assessment Questionnaire (SAQ) Scope Reduction: Because cardholder data is fully outsourced to validated PCI Level 1 third-party hosted fields, the medical practice qualifies for simplified merchant PCI validation (typically SAQ A or SAQ A-EP depending on implementation) rather than full on-premises network penetration testing.
Required Practice-Level HIPAA and PCI Safeguards (Shared Responsibility)
Executing a BAA with IntakeQ satisfies vendor-side infrastructure compliance, but outpatient clinics and telehealth practices remain responsible for configuring six practice-side controls:
- Execute the IntakeQ Business Associate Agreement (BAA): Before collecting live patient forms, the account administrator must execute and retain the counter-signed IntakeQ BAA inside the account settings.
- Enforce Mandatory Two-Factor Authentication (2FA): Enable 2FA across all practitioner, front-desk, and billing staff accounts, and prohibit shared staff login credentials (`45 CFR § 164.312(a)(2)(i)` Unique User Identification).
- Configure Role-Based Access Control (RBAC): Restrict access to clinical progress notes versus financial billing/superbill queues based on minimum-necessary job duties.
- Prevent PHI Leakage in Gateway Invoice Descriptions: Configure Stripe and Square integration settings so that emailed card receipts display generic merchant descriptions (e.g., “Medical Services / Copay”) rather than psychiatric or specialty CPT procedure descriptions, a standard practice across patient onboarding software.
- Signed Card-on-File Authorization Consent: Include an explicit financial policy and card-on-file authorization clause (specifying maximum charge thresholds and cancellation notice windows) within the electronic signature block of the intake packet to prevent chargeback disputes.
- Cyber and Breach Liability Alignment: Maintain appropriate HIPAA breach insurance and healthcare cyber liability coverage that covers both ePHI regulatory notifications and PCI-DSS payment card forensic obligations.
Common Misunderstandings
- Assuming Stripe or Square will sign a HIPAA BAA: Standard payment processors (including Stripe and Square) operate under the Section 1179 financial institution exemption and do not sign HIPAA BAAs; compliance requires keeping clinical PHI inside IntakeQ and never passing diagnostic descriptions into payment processor metadata fields.
- Collecting credit card numbers via custom free-text fields: Practices must never build a custom text-box question asking patients to type a 16-digit card number into a standard clinical form field, as doing so bypasses PCI tokenization and writes raw cardholder data into the EHR database.
Frequently Asked Questions
Is intakeq hipaa compliant?
Yes. IntakeQ (and PracticeQ) is fully HIPAA compliant: it executes Business Associate Agreements (BAAs) with covered entities, encrypts all Protected Health Information (PHI) in transit via TLS 1.2+ and at rest via AES-256, provides role-based access controls, audit trails, and Two-Factor Authentication (2FA), and undergoes annual third-party HIPAA compliance verification.
How does IntakeQ handle PCI compliance for credit cards and patient payments?
IntakeQ achieves PCI-DSS compliance by never storing raw credit card numbers or CVV codes on its servers; instead, payment fields on digital intake forms and patient portals use client-side tokenization through PCI-DSS Level 1 Service Providers (PracticeQ Payments, Stripe, and Square), storing only secure cryptographic reference tokens for recurring billing and copay processing.
Sources
- IntakeQ / PracticeQ. Security and HIPAA Compliance Architecture. https://intakeq.com/security (2026-11-09).
- PCI Security Standards Council (PCI SSC). Payment Card Industry Data Security Standard (PCI-DSS v4.0) Document Library. https://www.pcisecuritystandards.org/document_library/ (2026-11-09).
- U.S. Department of Health and Human Services (HHS) Office for Civil Rights. HIPAA Security Rule Guidance (45 CFR Part 164, Subpart C). https://www.hhs.gov/hipaa/for-professionals/security/index.html (2026-11-09).
