If you've evaluated EHR platforms for an independent post-acute practice, you've encountered the phrase "HIPAA certified" more than once. It appears in sales decks, on vendor websites, and occasionally in contract language. It is also, to be precise, not a thing. No official body certifies software or covered entities as HIPAA compliant. The Department of Health and Human Services' Office for Civil Rights enforces HIPAA, but HHS does not issue compliance certifications, and the HIPAA statute does not establish a certification program.
That gap between vendor claims and regulatory reality matters for independent post-acute practices in a specific way: small practices often have fewer internal resources to independently evaluate data security and privacy practices, which means they may rely more heavily on vendor claims — including claims that are technically meaningless. Understanding what HIPAA alignment actually requires, and what questions to ask vendors that reveal substantive data protection practices rather than marketing language, puts practices in a much better position when selecting an EHR.
What HIPAA Actually Requires of Your EHR Vendor
Under HIPAA, a covered entity (your practice) is responsible for ensuring that business associates who handle protected health information on its behalf have appropriate safeguards in place. An EHR vendor that hosts, processes, or stores PHI on your behalf is a business associate under HIPAA. The covered entity's obligations include executing a Business Associate Agreement (BAA) with each business associate prior to disclosing PHI.
The BAA is not optional or formalistic. Under the HIPAA Omnibus Rule (2013), business associates are directly liable for HIPAA Security and Privacy Rule compliance with respect to the PHI they handle. If a vendor cannot or will not execute a BAA that specifically addresses their handling of PHI in their hosting environment, that is a disqualifying issue — not a negotiating point.
Beyond the BAA, the HIPAA Security Rule establishes three categories of safeguards that apply to electronic PHI (ePHI): administrative safeguards (workforce training, risk analysis, contingency planning), physical safeguards (facility access controls, workstation security), and technical safeguards (access controls, audit controls, integrity controls, transmission security). The Security Rule describes what categories of safeguard are required but is largely non-prescriptive about the specific technical implementation — which has always been both its strength (flexibility for diverse covered entities) and its vulnerability (vendors can claim compliance without much specificity about implementation).
What "HIPAA-Aligned" Actually Means in Practice
When a vendor says their platform is HIPAA-aligned or designed for HIPAA compliance, the meaningful question is: aligned to what, specifically? The Security Rule's technical safeguard requirements translate to a set of concrete implementation expectations that a vendor should be able to describe in specific terms.
Access controls and user authentication: does the platform support role-based access controls (RBAC) that restrict user access to PHI based on job function? Does it require unique user identification (shared logins are a Security Rule violation)? Does it support multi-factor authentication for remote access, which is increasingly standard practice even where not explicitly mandated?
Audit logging: does the platform maintain audit logs of all access to PHI, with user identification and timestamps, and are those logs available to the covered entity for review? The Security Rule requires audit controls; the operational requirement is that you can actually retrieve and review access logs when a potential breach or inappropriate access needs to be investigated.
Encryption: is ePHI encrypted at rest and in transit? The Security Rule treats encryption as an "addressable" safeguard (meaning organizations must implement it or document why an equivalent alternative was chosen), but in current practice, encryption of ePHI at rest and in transit is the baseline expectation for any credible healthcare platform. Unencrypted ePHI at rest in a cloud environment is not HIPAA-aligned regardless of what the BAA says.
Data backup and recovery: does the platform maintain HIPAA-compliant data backup procedures, with recovery time and recovery point objectives documented? The Security Rule's contingency planning requirements include data backup, disaster recovery, and emergency mode operations — all of which need to be addressed in the vendor's BAA and data processing documentation.
A Scenario Independent Practices Often Encounter
Consider an independent behavioral health practice serving post-acute patients in home health and outpatient settings. The practice has three clinicians, no dedicated IT staff, and relies on its EHR vendor for essentially all electronic PHI infrastructure. The practice negotiates a contract with a cloud-based EHR platform whose sales materials describe the platform as "HIPAA compliant."
Six months after go-live, the practice receives a request from a patient for an accounting of disclosures — a right granted under HIPAA's Privacy Rule for certain disclosures of PHI. The practice asks the vendor to provide the disclosure logs for that patient. The vendor's response is that logging of disclosures for the purpose of patient accounting is not a feature the platform currently supports at the tier the practice purchased.
The HIPAA Privacy Rule at 45 CFR 164.528 requires covered entities to provide patients with an accounting of certain disclosures of their PHI going back six years. A platform that doesn't support disclosure logging isn't HIPAA-aligned for this requirement, regardless of the general claim. The practice is now obligated to reconstruct disclosure records manually or acknowledge they cannot fulfill the patient's request — neither is a good position.
We're not saying this situation indicates bad faith from the vendor — it's an illustration of how "HIPAA compliant" claims can be genuine without being complete. The only way to avoid this gap is to evaluate specific features against specific regulatory requirements before contracting, not after.
The Right Questions for EHR Vendor Due Diligence
Independent post-acute practices evaluating EHR platforms for HIPAA alignment should work through a concrete checklist before signing a contract. The following questions produce substantive information rather than marketing confirmation.
- Will you execute a Business Associate Agreement, and can I see your standard BAA before contracting?
- Where is ePHI hosted? Is it a HIPAA-eligible service configuration on your cloud hosting provider?
- Is ePHI encrypted at rest and in transit? What encryption standards are used?
- What are your audit logging capabilities? Can I retrieve access logs for specific patients or specific time periods?
- Does the platform support disclosure accounting for the purpose of responding to patient requests under 45 CFR 164.528?
- How are breaches detected and reported? What are your notification timelines for reporting to covered entities under the Breach Notification Rule?
- Has the platform undergone a third-party security assessment (SOC 2 Type II audit, HITRUST CSF assessment, or equivalent)?
That last item deserves emphasis. Third-party security assessments — particularly SOC 2 Type II and HITRUST CSF certifications — are the closest analogs to an independent HIPAA compliance evaluation that exist in practice. They are not HIPAA certifications (no such thing), but a SOC 2 Type II audit covering the security and availability trust service criteria evaluates whether a vendor's security controls operate effectively over time. A HITRUST CSF certification specifically maps controls to HIPAA Security Rule requirements. Both provide more substantive assurance than a vendor's self-declaration of HIPAA compliance.
Your Own Obligations Don't Transfer to the Vendor
The final point that independent practices sometimes overlook: even a fully compliant EHR vendor cannot transfer the covered entity's HIPAA obligations to the vendor. Your practice is responsible for workforce training on HIPAA Privacy and Security requirements. Your practice is responsible for conducting and documenting a risk analysis (a Security Rule administrative safeguard requirement that many small practices have never formally completed). Your practice is responsible for having and maintaining a HIPAA Notice of Privacy Practices and providing it to patients.
A well-designed EHR can support your compliance obligations by providing the right tools — audit logs, access controls, BAA documentation, breach notification workflows. It cannot meet those obligations on your behalf. The practices that are best positioned when an HHS audit or patient complaint arrives are those that have treated HIPAA compliance as an ongoing operational function rather than a vendor checkbox. For an independent post-acute practice without dedicated compliance staff, that means assigning explicit ownership of HIPAA policy review, maintaining a current risk analysis, and scheduling at least annual workforce training — not because these are comfortable activities, but because they are the activities that determine whether the practice is actually protected when it matters.
