1. HIPAA Overview for Dental Software Vendors

The Health Insurance Portability and Accountability Act (HIPAA) establishes national standards for protecting patient health information. As a dental software vendor that processes Protected Health Information (PHI), IntakeIQ operates as a Business Associate and is directly subject to HIPAA requirements.

Covered Entity vs. Business Associate

Covered Entity (CE): The dental practice — they collect and maintain patient records and submit claims to insurers. Every dental practice is a Covered Entity under HIPAA.

Business Associate (BA): IntakeIQ — we create, receive, maintain, or transmit PHI on behalf of the Covered Entity. As a BA, we are directly liable for HIPAA compliance under the HITECH Act and must meet the same Security Rule standards as the practice itself.

Business Associate Agreement (BAA)

HIPAA requires a written BAA between every Covered Entity and Business Associate before any PHI is shared. IntakeIQ executes a BAA with every customer before onboarding begins.

Our BAA covers: permitted uses and disclosures, safeguard requirements, breach notification obligations, subcontractor requirements, PHI return/destruction upon termination, and audit cooperation.

$50K-$1.5MHIPAA Violation Penalties (per category)
60 DaysBreach Notification Deadline
6 YearsRecord Retention Minimum
100%BAA Coverage Rate

2. Security Rule Checklist

The HIPAA Security Rule requires administrative, physical, and technical safeguards for electronic PHI (ePHI). Below is IntakeIQ's implementation status for each safeguard category.

Administrative Safeguards

Security Management Process

  • Formal risk analysis conducted annually and after significant changes
  • Risk management plan with documented mitigations for identified risks
  • Sanction policy for workforce members who violate security policies
  • Regular review of information system activity (audit logs, access reports)

Workforce Security

  • Background checks for all employees with PHI access
  • Role-based authorization — minimum necessary access principle
  • Documented termination procedures — immediate access revocation
  • Annual security awareness training for all team members

Information Access Management

  • Access authorization policies tied to job function
  • Documented access establishment and modification procedures
  • Quarterly access reviews by security team
  • Privileged access requires manager approval + MFA

Contingency Plan

  • Data backup plan — automated daily backups with geographic redundancy
  • Disaster recovery plan — RTO of 4 hours, RPO of 1 hour
  • Emergency mode operation procedures documented
  • Annual testing of backup restoration and disaster recovery

Physical Safeguards

Facility Access Controls

  • Cloud-hosted on HIPAA-eligible AWS infrastructure
  • AWS data centers: SOC 2 Type II, ISO 27001, FedRAMP certified
  • No on-premise PHI storage — all data resides in encrypted cloud infrastructure
  • Employee workstations use full-disk encryption (FileVault / BitLocker)

Device & Media Controls

  • Media disposal policy — cryptographic erasure for decommissioned storage
  • No PHI stored on portable media (USB drives, external disks)
  • Mobile device management (MDM) for company-issued devices
  • Automatic screen lock after 5 minutes of inactivity

Technical Safeguards

Access Control

  • Unique user identification — every user has a unique account
  • Emergency access procedure documented and tested annually
  • Automatic session timeout after 15 minutes of inactivity
  • Encryption and decryption of ePHI using AES-256

Audit Controls

  • Comprehensive audit logging of all PHI access and modifications
  • Logs include: timestamp, user ID, IP address, action, affected records
  • Logs are immutable (append-only) and retained for 7 years
  • Automated alerts for anomalous access patterns

Integrity Controls

  • Mechanisms to authenticate ePHI — checksums and version history
  • Database-level constraints prevent unauthorized modification
  • API input validation and sanitization on all endpoints
  • Automated integrity checks during data sync operations

Transmission Security

  • TLS 1.3 for all data in transit (browser, API, PMS sync)
  • Certificate pinning for mobile connections
  • Encrypted API keys and credentials (never transmitted in plaintext)
  • Secure SMS delivery via Twilio (carrier-grade encryption)

3. Privacy Rule

The HIPAA Privacy Rule governs how PHI is used and disclosed. As a Business Associate, IntakeIQ may only use PHI as permitted by the BAA and for the specific purposes outlined below.

Minimum Necessary Standard

IntakeIQ only accesses the minimum amount of PHI necessary to perform intake automation services. Our system architecture enforces this principle:

  • API endpoints return only the fields needed for each function
  • PMS sync transfers only demographics, insurance, and medical history — not clinical notes, imaging, or billing beyond intake scope
  • Internal team access is restricted by role — support agents see less than engineers, who see less than security administrators
  • AI models process PHI in memory only; training data is never derived from customer PHI

Patient Rights

Patients retain all HIPAA rights over their PHI. IntakeIQ supports practices in fulfilling these rights:

  • Right to Access: Patients can request copies of their intake data through the practice; IntakeIQ provides export tools
  • Right to Amendment: Patients can request corrections; IntakeIQ's forms allow edits before submission and flag amendment requests post-submission
  • Right to Accounting: IntakeIQ maintains a disclosure log that practices can provide to patients upon request
  • Right to Restriction: Patients can request restrictions on certain uses; practices can configure form exceptions

4. Breach Notification

In the event of a breach of unsecured PHI, HIPAA requires notification to affected individuals, HHS, and (for breaches of 500+ records) the media. IntakeIQ maintains a rigorous incident response plan.

The 60-Day Rule

If a breach of unsecured PHI is discovered, IntakeIQ must notify the affected Covered Entity (dental practice) without unreasonable delay and no later than 60 days after discovery. The practice then notifies affected patients within the same 60-day window.

For breaches affecting 500+ individuals in a single state/jurisdiction, the practice must also notify prominent local media. For breaches affecting fewer than 500, an annual log is submitted to HHS.

Notification Contents

  • Description of what happened (date, nature of breach)
  • Types of information involved (names, SSN, insurance IDs, etc.)
  • Steps individuals should take to protect themselves
  • What IntakeIQ and the practice are doing to mitigate harm
  • Contact information for questions

IntakeIQ Incident Response Plan

Phase 1: Detection (0-4 hours)

Automated monitoring detects anomalous access, data exfiltration, or system compromise. Security team receives immediate alert. Incident is logged and classified (severity 1-4).

Phase 2: Containment (4-24 hours)

Affected systems are isolated. Access credentials are rotated. Forensic data is preserved. Preliminary scope assessment: what data, how many records, what systems.

Phase 3: Investigation (24-72 hours)

Root cause analysis. Full scope determination. Engagement of external forensic firm if needed. Legal counsel reviews breach determination (was PHI actually compromised?).

Phase 4: Notification (Within 30 days)

If breach is confirmed: notify all affected Covered Entities (dental practices) with full details. Provide template patient notification letters. Coordinate with practices on timing and messaging.

Phase 5: Remediation (Ongoing)

Fix the vulnerability. Update security controls. Document lessons learned. Update incident response plan. Brief all customers on security improvements made.

5. IntakeIQ's Security Architecture

Security is foundational to IntakeIQ's architecture — not a feature added after the fact. Every layer of our stack is designed to protect PHI.

Data Flow Diagram

Patient Device IntakeIQ Platform Practice PMS | | | |--- TLS 1.3 ------> [API Gateway] | | | WAF + Rate Limiting | | | Input Validation | | v | | [Application Layer] | | | RBAC Enforcement | | | PHI Tokenization | | v | | [AI Processing] | | | In-memory only | | | No PHI in training data | | v | | [Database Layer] | | | AES-256 at rest | | | Field-level encryption for SSN, DOB | | | Automated backups (encrypted) | | v | | [Audit Log] [PMS Sync Engine] ---TLS 1.3--> | | Immutable | | 7-year retention |

Encryption Standards

LayerStandardDetails
Data in TransitTLS 1.3All browser, API, and PMS sync connections. HSTS enforced. Certificate pinning for mobile.
Data at Rest (Database)AES-256Full database encryption via AWS RDS. Encryption keys managed by AWS KMS with annual rotation.
Data at Rest (Files)AES-256Insurance card images, uploaded documents encrypted in S3 with server-side encryption.
Field-Level EncryptionAES-256-GCMSSN, date of birth, and insurance member IDs encrypted at the application layer before database write.
BackupsAES-256Automated daily backups encrypted and stored in a separate AWS region.
API Keys / SecretsAWS Secrets ManagerNo secrets in code. All API keys, PMS credentials, and tokens stored in encrypted vault.

Access Controls (RBAC)

RolePHI Access LevelExample Users
Practice AdminFull — all patients at their location(s)Office manager, practice owner
ProviderAssigned patients only — chair-side summaryDentist, hygienist
Front DeskDemographics + insurance — no medical flagsReceptionist, scheduling coordinator
IntakeIQ SupportMetadata only — no PHI content without consentCustomer success, support engineers
IntakeIQ EngineeringAnonymized / tokenized data only in productionDevelopers, QA engineers
Security AdminAudit logs + access management (not PHI content)CISO, security engineers

PHI Retention & Destruction

Retention Policy

6. SOC 2 Type II Roadmap

SOC 2 Type II certification demonstrates that IntakeIQ's security controls are not just designed well (Type I) but have been operating effectively over time (Type II). This is the gold standard for SaaS security assurance.

Q1 2026 — Readiness Assessment

Engage SOC 2 advisory firm. Gap analysis against Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality). Remediate gaps in policies, procedures, and technical controls.

Q2 2026 — Type I Audit

Point-in-time assessment of control design. Auditor confirms controls are suitably designed. Report issued to customers and prospects under NDA. Addresses: "Are the right controls in place?"

Q3-Q4 2026 — Observation Period

6-month continuous monitoring period for Type II. Auditor reviews evidence of control operation: access logs, change management records, incident response tests, vulnerability scan results.

Q1 2027 — Type II Report Issued

Type II report confirms controls have been operating effectively over the observation period. Report available to all customers and prospects. Annual renewal thereafter.

What SOC 2 Means for Customers

A SOC 2 Type II report means an independent auditor has verified that IntakeIQ protects your data according to industry-leading standards — not just on paper, but in practice, over time. For DSOs and enterprises that require vendor security certifications, our SOC 2 report satisfies the most common security questionnaire requirements and dramatically reduces vendor risk assessment timelines.

7. Pediatric Considerations

Pediatric dental practices must comply with both HIPAA and COPPA (Children's Online Privacy Protection Act) when collecting information from patients under 13. IntakeIQ has built-in safeguards for pediatric intake.

COPPA Compliance

COPPA applies when a platform collects personal information directly from children under 13. In dental intake, the child is typically the patient but the parent/guardian completes the forms. IntakeIQ enforces this workflow:

  • Intake links are sent to the parent/guardian's phone or email — never to the child
  • All forms require parental verification (e-signature + checkbox acknowledgment)
  • No account creation by the child — the parent is the authenticated user
  • No data collection from the child beyond what is clinically necessary

Parental Consent Workflow

IntakeIQ's pediatric workflow is specifically designed for the parent-child relationship in dental intake:

  • Step 1: Parent receives SMS/email link for their child's appointment
  • Step 2: Parent verifies their identity and relationship to the child
  • Step 3: Parent completes intake on behalf of the child — medical history, medications, allergies
  • Step 4: Parent signs consent forms (treatment consent, HIPAA notice, financial responsibility)
  • Step 5: For divorced/separated parents — configurable dual-consent workflows when required by state law

8. State-Specific Requirements

Several states impose data protection requirements beyond federal HIPAA standards. IntakeIQ complies with the most restrictive state laws to ensure coverage for all US customers.

California (CCPA/CPRA)

The California Consumer Privacy Act (as amended by CPRA) grants California residents broad data rights. While HIPAA-regulated PHI has a partial exemption, IntakeIQ takes a conservative approach:

  • Right to know what data is collected — IntakeIQ provides a clear privacy notice
  • Right to delete — supported via our data destruction workflow
  • Right to opt-out of sale — IntakeIQ never sells patient data (we have no data sales)
  • Data minimization — we collect only what's needed for intake functions
  • Service provider agreement provisions aligned with CPRA requirements

Texas (TDPSA + HB 300)

Texas has both a general data privacy act (TDPSA, effective 2024) and a health-specific law (HB 300) that imposes stricter requirements than federal HIPAA:

  • HB 300 requires employee training on state-specific health privacy — IntakeIQ trains all staff
  • Stricter penalties for unauthorized disclosure of health information
  • Patient authorization required for electronic disclosure — IntakeIQ's consent forms include Texas-specific language
  • Covered entities and their vendors must have a training program — IntakeIQ provides documentation to support practice compliance

New York (SHIELD Act + NYDFS)

New York's SHIELD Act expanded the definition of private information and imposed data security requirements on any company holding NY residents' data:

  • Broader definition of "private information" — includes biometric data and email + password combinations
  • Requires "reasonable safeguards" — IntakeIQ's security architecture exceeds the SHIELD Act's standard
  • Breach notification within "most expedient time" — IntakeIQ's 30-day internal SLA exceeds this requirement
  • While NYDFS cybersecurity rules primarily apply to financial services, DSO-affiliated practices with financial components may be impacted

9. BAA Template Outline

IntakeIQ's standard Business Associate Agreement covers the following areas. Full BAA is provided during the sales process and must be executed before any PHI is transmitted.

IntakeIQ BAA Coverage

  1. Definitions: PHI, ePHI, Security Incident, Breach, Covered Entity, Business Associate, Subcontractor — all defined per 45 CFR 160.103
  2. Obligations of IntakeIQ (BA): Use PHI only as permitted; implement safeguards (Security Rule); report security incidents and breaches; ensure subcontractor compliance; make PHI available for patient access requests; return or destroy PHI on termination
  3. Permitted Uses: Intake form processing, insurance verification, medical history analysis, PMS synchronization, customer support (with access limitations), product improvement (de-identified data only)
  4. Subcontractors: IntakeIQ may use subcontractors (AWS, Twilio, clearinghouses) who are bound by equivalent BAA obligations. Current subcontractor list provided upon request.
  5. Breach Notification: IntakeIQ will notify Covered Entity within 30 days of discovering a breach (inside the HIPAA 60-day maximum). Notification includes: nature of breach, PHI involved, mitigation steps, corrective actions.
  6. Term & Termination: BAA effective upon execution; terminates when agreement ends or upon material breach. PHI returned or destroyed within 90 days of termination (with certification of destruction).
  7. Indemnification: Mutual indemnification for losses arising from the other party's violation of the BAA or HIPAA.
  8. Governing Law: Federal HIPAA/HITECH regulations; state law of the Covered Entity's primary location for non-federal matters.

10. Compliance FAQ

The 10 most common questions we hear from dental practices about data security and compliance.

Q1: Is IntakeIQ HIPAA compliant?

Yes. IntakeIQ was built from the ground up as a HIPAA-compliant platform. We execute a Business Associate Agreement (BAA) with every customer, encrypt all PHI at rest (AES-256) and in transit (TLS 1.3), maintain comprehensive audit logs, and enforce role-based access controls. Our SOC 2 Type II certification is in progress (target: Q1 2027).

Q2: Do you sign a BAA?

Yes — always. We provide our standard BAA during the sales process, and it must be fully executed before any PHI is transmitted to our platform. We also ensure our subcontractors (AWS, Twilio, clearinghouses) have BAAs in place.

Q3: Where is our data stored?

All data is stored on HIPAA-eligible AWS infrastructure in US-based data centers (US-East-1 and US-West-2). No data is stored outside the United States. We do not use shared hosting or multi-tenant databases without encryption isolation.

Q4: Can our staff see patient data?

Your staff sees patient data according to their role. Practice Admins see everything for their location(s). Providers see assigned patients. Front desk staff see demographics and insurance but not medical risk flags. IntakeIQ support staff can only access metadata (not PHI content) unless your admin grants explicit temporary access for troubleshooting.

Q5: What happens to our data if we cancel?

Upon cancellation, you have a 90-day window to export all your data (we provide a full encrypted export). After 90 days, all PHI is cryptographically destroyed — encryption keys are permanently deleted, rendering the data unrecoverable. You receive a certification of destruction for your records.

Q6: How do you handle insurance card photos?

Insurance card images are encrypted immediately upon upload (TLS 1.3 in transit, AES-256 at rest in S3). OCR processing happens in memory — the image is read, data is extracted, and the processing memory is cleared. The original image is retained only as long as your practice's retention policy requires (configurable). Images are never shared or used for any purpose beyond your practice's intake workflow.

Q7: Is your AI trained on our patient data?

No. IntakeIQ's AI models are never trained on customer PHI. Our models are trained on de-identified, synthetic, and publicly available medical data. When our AI processes your patients' medical histories, it operates in inference mode only — data flows through the model but does not update it. No PHI is retained in the model.

Q8: What if there's a data breach?

IntakeIQ maintains a formal incident response plan (see Section 4). If a breach of unsecured PHI is discovered, we will notify your practice within 30 days with full details: what happened, what data was involved, what we're doing about it, and what you should tell your patients. We also provide template patient notification letters and coordinate with your legal team.

Q9: Do you comply with state privacy laws (CCPA, etc.)?

Yes. IntakeIQ complies with CCPA/CPRA (California), HB 300 (Texas), SHIELD Act (New York), and other state-specific requirements. We apply the most restrictive standard across all states so that every customer — regardless of location — benefits from the highest level of data protection.

Q10: Can we run our own security assessment on IntakeIQ?

Yes. Enterprise and DSO customers can request our SOC 2 report (when available), review our security documentation, and submit security questionnaires. We respond to standard formats including SIG Lite, CAIQ, and custom questionnaires. For enterprise accounts, we also support on-site or virtual security assessments by your team or a third-party auditor.