HIPAA and Local CRM: What Healthcare Needs to Know

Healthcare practices, clinics, and health-adjacent businesses use CRM software to manage patient relationships, track appointments, log communications, and coordinate care. When that CRM contains Protected Health Information — and it often does — HIPAA applies. Most cloud CRM vendors aren't ready for that conversation.

Here's what you need to know about HIPAA and CRM, and why local-first software like DenchClaw provides a fundamentally different compliance posture.

What Counts as PHI in a CRM#

Protected Health Information (PHI) is individually identifiable health information that relates to an individual's past, present, or future physical or mental health condition, the provision of healthcare, or payment for healthcare.

In a CRM context, PHI typically includes:

• Patient name combined with any of the following: diagnosis, treatment, medication, appointment type, or health history
• Appointment notes that mention health conditions
• Insurance information
• Billing information tied to health services
• Communication history about health matters

Crucially, even combining a name with an appointment date at a medical practice can constitute PHI. A CRM entry for "John Smith — appointment scheduled March 15, follow-up for knee pain" is PHI.

Many healthcare businesses underestimate this. A therapy practice using HubSpot to track client sessions is storing PHI in HubSpot. A dental office using Salesforce to manage patient follow-ups is storing PHI in Salesforce. Whether or not those vendors signed a BAA, the data is PHI and HIPAA applies.

The Business Associate Agreement Requirement#

The HIPAA Privacy Rule requires covered entities (healthcare providers, health plans, healthcare clearinghouses) to have a Business Associate Agreement with any vendor that creates, receives, maintains, or transmits PHI on their behalf.

A cloud CRM that stores patient contact information is a business associate. Without a signed BAA, using that CRM with PHI is a HIPAA violation.

This creates immediate problems:

Most standard CRM plans don't include BAAs. HubSpot offers BAAs only on enterprise plans. Salesforce's HIPAA-compliant offering requires specific Health Cloud configuration. Many vendors don't offer BAAs at all. If you're using a standard business CRM plan, you almost certainly don't have a BAA.

BAAs don't make the risk disappear. A BAA means the vendor takes on HIPAA compliance obligations. But it doesn't mean your data is safe. It means that if there's a breach, liability is shared. You still need to perform due diligence on the vendor's security controls.

Sub-processors under a BAA create chain-of-liability complexity. Your CRM vendor's BAA covers their direct handling of PHI, but they use sub-processors. Email delivery, analytics, support tools — each may touch PHI. Each requires their own BAA or coverage under your primary vendor's BAA.

BAA negotiations can be slow. Enterprise healthcare organizations spending months negotiating BAA terms with CRM vendors is common. It delays deployments and creates contractual complexity.

Breach Notification Under HIPAA#

The HIPAA Breach Notification Rule requires covered entities to notify affected individuals, the Department of Health and Human Services, and in some cases the media, following a breach of unsecured PHI.

Key timelines:

• Individuals must be notified within 60 days of discovering a breach
• HHS must be notified — for breaches affecting 500+ individuals, within 60 days; for smaller breaches, annually
• Media notification is required for breaches affecting 500+ individuals in a state

The "wall of shame" — HHS's public breach notification list — is searchable and covers breaches since 2009. Cloud CRM breaches affecting healthcare customers appear on it regularly.

When you use a cloud CRM, you're dependent on the vendor to:

1. Detect breaches promptly
2. Determine scope accurately
3. Notify you within the required timeframes
4. Provide the information you need for your own notifications

This adds time pressure and complexity to an already stressful situation.

Why Local-First Changes the HIPAA Picture#

When your CRM runs locally — patient contact data in a DuckDB file on a machine you control — the HIPAA compliance picture changes fundamentally.

No BAA required with your CRM vendor. Because DenchClaw runs on your machine and patient data doesn't pass through Dench's infrastructure, Dench is not a business associate for your PHI. There's no BAA to negotiate, no vendor HIPAA assessment to perform.

Breach risk is contained to your infrastructure. Your attack surface for PHI is your own machines and network, not a multi-tenant cloud shared with thousands of other customers. A breach of your local system is discoverable immediately — you're not waiting for a vendor to tell you.

Deletion is complete and verifiable. HIPAA's minimum necessary principle and retention requirements are easier to implement when you control the database. Deleting PHI means running a SQL DELETE on your local DuckDB. No uncertainty about whether backups or analytics systems retain copies.

Encryption is under your control. macOS FileVault, BitLocker on Windows, LUKS on Linux — the encryption protecting PHI at rest is your choice and your implementation. You know what keys are used and who has access.

Audit logs are local. HIPAA requires audit controls — records of activity related to PHI. DenchClaw's local architecture means audit logs are on your machine, under your control, not dependent on a vendor's logging infrastructure.

DenchClaw for Healthcare Practices#

DenchClaw is purpose-built for local-first CRM — the kind of architecture that makes HIPAA compliance simpler by design.

For a healthcare practice, here's what a HIPAA-aware DenchClaw deployment looks like:

Machine encryption: Enable FileVault (macOS) or BitLocker (Windows) on any machine running DenchClaw. This encrypts the DuckDB file at rest.

Access controls: DenchClaw's workspace is tied to the OS user account. Use strong passwords and screen lock policies.

Backup encryption: Time Machine backups and any other backup systems should use encrypted destinations.

Network security: If running DenchClaw on a server accessible over your network, use VPN or other network security controls for access.

Audit documentation: Maintain records of who has access to the machine running DenchClaw and document your access control policies for your HIPAA risk analysis.

No external AI calls with PHI: If using DenchClaw's AI features with patient data, configure a local AI model rather than an external API to keep PHI off third-party servers.

This isn't a complete HIPAA compliance program — you'll still need policies, training, a risk analysis, and potentially a BAA with your IT infrastructure providers. But the technical controls are architecturally simpler than with a cloud CRM.

When You Still Need a BAA#

Local-first CRM doesn't eliminate all HIPAA BAA requirements. You'll still need BAAs with:

• Your cloud backup provider if you back up your machine to a cloud service (iCloud, AWS, Dropbox) and that backup includes the DenchClaw workspace
• Your email provider if you send PHI via email
• Your telehealth platform
• Your EHR/EMR vendor

The point isn't that local-first eliminates all vendor relationships with PHI — it's that it eliminates the CRM layer of that risk. Your patient relationship management data stays local and doesn't add another vendor to your BAA list.

Comparing HIPAA Posture: Cloud vs Local-First CRM#

Frequently Asked Questions#

Can I use a standard HubSpot plan for a healthcare practice?#

No. Standard HubSpot plans don't include a BAA. Using PHI in HubSpot without a signed BAA is a HIPAA violation. HubSpot's BAA is available only on enterprise plans at significant additional cost.

Does DenchClaw sign a HIPAA BAA?#

Because DenchClaw runs locally and PHI doesn't pass through Dench's infrastructure for the CRM function, a BAA with Dench isn't typically required. Consult your HIPAA compliance advisor for your specific situation.

Is a dental practice or therapy office a covered entity under HIPAA?#

Yes. Dental practices, therapy practices, medical offices, and other direct care providers are covered entities under HIPAA. Their business software that handles PHI must comply.

What if staff access DenchClaw remotely?#

Remote access to a locally-hosted DenchClaw instance should use encrypted channels (VPN or similar). The PHI remains on your local server; the remote access doesn't move PHI to another location.

Does local-first CRM satisfy the HIPAA Security Rule?#

The Security Rule requires administrative, physical, and technical safeguards. Local-first software helps with technical safeguards (encryption, access controls, audit logs) but doesn't address administrative safeguards (training, policies) or physical safeguards (physical access controls). A complete HIPAA compliance program requires all three.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →