EHR HIPAA Compliance Checklist (2026)

1Tell us where to send it
Your name and work email — nothing more.
2Check your inbox
Your checklist arrives in seconds, not days.
3Use it with your team
Editable and ready to share — make it your own.

A peek inside

See exactly what you're getting

Free PDF

Spotsaas · 2026

EHR HIPAA Compliance Checklist

✓ Access controls & authentication

✓ Audit & integrity controls

✓ Vendor due-diligence steps

✓ Questions to ask the vendor

Get the checklist →

What it is

The EHR HIPAA Compliance Checklist is a vendor-evaluation document that maps the administrative, physical, and technical safeguards required by the HIPAA Security Rule onto the specific behaviors an electronic health record system must demonstrate before it ever touches protected health information (PHI). Rather than asking whether a vendor 'is HIPAA compliant' — a claim every vendor makes and no vendor can technically guarantee on your behalf — the checklist breaks compliance into line items you can verify in a live product demo: unique user IDs for every clinician, role-based least-privilege access to PHI, automatic logoff after inactivity, and multi-factor authentication for remote access.

What makes the checklist genuinely useful is that it forces the conversation past marketing language and into audit and integrity controls. It asks for an immutable audit log of every PHI access, tamper-evident record versioning, break-the-glass emergency access logging, and a documented audit-log review workflow. These are the exact artifacts an HHS Office for Civil Rights investigator looks for after a breach, and they are the controls that distinguish a clinical-grade EHR from a generic SaaS tool that happens to store health data. Printing one copy per vendor — whether you are weighing Epic, eClinicalWorks, SimplePractice, or Azalea Health — lets you score each system against the same objective criteria.

The checklist also covers the contractual and operational layer that surrounds the software itself: the Business Associate Agreement (BAA) the vendor must sign, the breach-notification SLA they commit to, how PHI is encrypted at rest and in transit, and who holds the encryption keys. Because HIPAA compliance is a shared responsibility between the covered entity and its business associates, the document is structured to make those boundaries explicit so nothing falls through the cracks at signing.

What it's used for

Practices reach for this checklist at the moments when HIPAA exposure is highest — during vendor selection, before contract signing, and during periodic security reviews. It turns an abstract regulatory obligation into a concrete, repeatable evaluation that any practice administrator or compliance lead can run without a law degree.

✓ Comparing EHR vendors apples-to-apples on safeguards, scoring each one on access controls, encryption, audit logging, and breach-notification commitments instead of trusting a generic 'HIPAA compliant' badge.
✓ Driving the live demo agenda — using each line as a question you make the vendor demonstrate on screen, such as showing automatic logoff, role-based PHI restriction, and the break-the-glass access prompt in action.
✓ Negotiating the Business Associate Agreement, including the breach-notification SLA, sub-processor disclosures, and data-return obligations, before the contract is countersigned.
✓ Documenting your due-diligence trail so that if a breach or audit ever occurs, you can show OCR that you evaluated and verified safeguards rather than relying on vendor assertions.
✓ Running an annual or post-incident security review against your in-production EHR to confirm that audit logs, MFA, and least-privilege roles are still configured the way you scoped them at purchase.
✓ Onboarding a new compliance officer or privacy officer by giving them a structured map of what 'compliant' actually means in the context of your specific EHR.
✓ Aligning IT, clinical leadership, and revenue-cycle stakeholders on a single shared definition of the safeguards the system must satisfy.

Who uses it

HIPAA compliance is rarely one person's job — it sits at the intersection of clinical operations, IT security, and legal risk. The checklist is built to be passed between these roles so that each one verifies the safeguards they own.

Practice administrators and office managersThey own the vendor-selection decision and the BAA negotiation, so they use the checklist to keep every vendor honest and to document due diligence for the practice's records.

Privacy and security officersHIPAA requires covered entities to designate these roles, and they rely on the checklist to verify that administrative, physical, and technical safeguards are actually implemented rather than just claimed.

IT directors and security engineersThey verify the technical safeguards — encryption at rest and in transit, MFA, automatic logoff, immutable audit logs — and confirm the EHR integrates with the practice's existing identity and access management.

Compliance consultants and HIPAA auditorsThey use it as a standardized rubric when assessing a practice's EHR posture or preparing for a Security Risk Analysis.

Clinical leadership (medical directors, nursing leads)They confirm that least-privilege access and break-the-glass emergency access work without blocking legitimate, time-sensitive patient care.

Context & good to know

HIPAA compliance for an EHR is fundamentally a shared-responsibility model, and that is the single biggest source of confusion this checklist resolves. The vendor is responsible for building safeguards into the software and signing a BAA; the covered entity is responsible for configuring those safeguards correctly, training staff, and conducting its own Security Risk Analysis. A system can be perfectly capable of HIPAA compliance and still leave your practice exposed if you never enable MFA, never set up role-based access, or never review the audit logs the system is dutifully recording.

The technical safeguards in the checklist exist because PHI breaches almost always trace back to a small number of failure modes: shared or generic logins instead of unique user IDs, over-broad access that ignores least-privilege, unencrypted data, and the absence of an audit trail that would have caught inappropriate access early. By insisting on an immutable audit log and tamper-evident versioning, the checklist targets the controls that both prevent breaches and provide the evidence OCR demands when one happens. Break-the-glass logging matters specifically because emergency access is the most legitimate-looking way for inappropriate access to occur, so it must be logged and reviewed rather than disabled.

Vendor due diligence is where this checklist earns its keep against real products. SimplePractice and Azalea Health, for example, market heavily to small and mid-sized behavioral health and ambulatory practices, where the practice often lacks a dedicated security team — making a structured checklist even more valuable. Epic and eClinicalWorks serve larger organizations with more complex access hierarchies and more interfaces touching PHI, which raises the stakes on audit logging and key management. In every case the right move is the same: make the vendor demonstrate each safeguard live and get the BAA and breach-notification SLA in writing before signing.

✓ Independent · vendors can't pay to rank

Built on verified data, not vendor spin

Every Spotsaas resource draws on the Spotsaas Score — a blend of verified review ratings, review volume, and feature depth across 74 EHR software tools. Refreshed regularly; data as of June 2026.

FAQ

Questions, answered

What is an EHR software, and why does HIPAA apply to it?

An EHR (electronic health record) is the digital system a practice uses to chart patient encounters, place orders, prescribe medications, and store the full medical record. Because it creates, receives, maintains, and transmits protected health information, the EHR vendor is a 'business associate' under HIPAA and the practice is a 'covered entity,' so the Security Rule's administrative, physical, and technical safeguards apply to both parties and must be backed by a signed Business Associate Agreement.

Does signing a BAA make my EHR HIPAA compliant?

No. A BAA is necessary but not sufficient. It establishes the vendor's legal obligations and breach-notification duties, but compliance still depends on how you configure the system — enabling MFA, setting least-privilege roles, turning on audit logging, and conducting your own Security Risk Analysis. HIPAA is a shared responsibility; the BAA covers the vendor's half, and your configuration and policies cover yours.

What are the three categories of HIPAA safeguards an EHR must support?

Administrative safeguards (security management, workforce training, access authorization policies), physical safeguards (facility access controls, workstation and device security), and technical safeguards (access controls, audit controls, integrity controls, and transmission security). The checklist is organized so you can verify each category against the live product.

Why does the checklist insist on an immutable audit log?

Because the audit log is both a preventive and a forensic control. An immutable, tamper-evident log of every PHI access lets you detect inappropriate access early, satisfies HIPAA's audit-control requirement, and gives the HHS Office for Civil Rights the evidence it requires after any incident. If a vendor cannot show you the log and a review workflow, that is a serious gap.

What is 'break-the-glass' access and why is it called out separately?

Break-the-glass is emergency access that lets a clinician bypass normal least-privilege restrictions to reach a patient's record in an urgent situation. It is essential for patient safety but is also the most plausible cover for inappropriate access, so the EHR must log every break-the-glass event and route it into a review workflow rather than letting it pass silently.

Is Epic HIPAA compliant out of the box?

Epic, like other clinical-grade EHRs, provides the safeguards required for HIPAA compliance — unique user IDs, role-based access, encryption, audit logging — but no EHR is 'compliant out of the box' for your practice. Compliance is the result of correct configuration, staff training, signed agreements, and your own risk analysis. The checklist exists precisely so you verify these in your deployment rather than assume them.

How should I use this checklist during a vendor demo?

Treat each line as a request to demonstrate, not a question to answer verbally. Ask the vendor to show automatic logoff triggering after inactivity, to log in as a restricted role and prove they cannot see PHI outside their scope, to open the audit log on a record, and to walk the break-the-glass prompt. Score what you see, not what you are told.

Who at my practice should own HIPAA EHR compliance?

HIPAA requires you to designate a privacy officer and a security officer. In a small practice these may be the same person or the practice administrator; in larger organizations they are distinct roles supported by IT and clinical leadership. The checklist is designed to be shared across these roles so each verifies the safeguards within their domain.

What encryption questions should I ask the vendor?

Ask how PHI is encrypted at rest and in transit, which standards are used, and critically, who holds the encryption keys. Key custody affects who can technically access your data and how a breach is scoped, so it belongs in both the demo and the contract discussion.

How often should I re-run this checklist after going live?

At minimum annually as part of your Security Risk Analysis, and again after any major EHR upgrade, configuration change, or security incident. Safeguards drift over time — roles get over-provisioned, MFA exceptions accumulate — so periodic re-verification keeps your in-production system aligned with what you scoped at purchase.

Keep exploring