Key takeaways
- HIPAA’s Privacy, Security and Breach Notification Rules all shape how software handling PHI must be built and run.
- The Security Rule requires administrative, physical and technical safeguards, starting with a documented risk analysis.
- Every vendor that handles PHI for you, including developers with production access, needs a business associate agreement.
- In January 2025, HHS proposed significant updates to the Security Rule; they were proposals, not final requirements, at the time of writing.
Whether you are building a patient portal, an admissions CRM or an integration with an EHR, the Health Insurance Portability and Accountability Act (HIPAA) applies to how protected health information (PHI) is handled. Technology is only part of compliance; policies and processes matter just as much.
This article is general guidance, not legal advice. Your compliance officer and legal counsel should confirm the requirements for your organization.
The three rules that matter for software
| Rule | What it covers |
|---|---|
| Privacy Rule | Who may use and disclose PHI, minimum necessary access and patient rights |
| Security Rule | Administrative, physical and technical safeguards for electronic PHI |
| Breach Notification Rule | Notifying individuals, HHS and sometimes the media after a breach of unsecured PHI |
Policies to have in place
- Risk analysis and risk management. A documented assessment of where ePHI lives, the threats to it and the controls in place, reviewed regularly.
- Access control. Unique user IDs, role-based access on the minimum-necessary principle, and prompt removal of leavers.
- Audit controls. Logs of who accessed or changed PHI, and a process for reviewing them.
- Encryption and transmission security. Encryption in transit and at rest wherever reasonable and appropriate.
- Contingency planning. Backups, disaster recovery and emergency access procedures.
- Workforce training and sanctions. Regular training and a sanctions policy for violations.
- Vendor management. Business associate agreements and due diligence for every vendor handling PHI.
- Incident response and breach notification. How incidents are reported, investigated and, where required, notified.
Breach notification timelines
Under the Breach Notification Rule, affected individuals must be notified without unreasonable delay and no later than 60 days after discovery. Breaches affecting 500 or more people must also be reported to HHS within that period, and to prominent media outlets when more than 500 residents of a state or jurisdiction are affected. Smaller breaches are reported to HHS annually.
Building it into software projects
- Include PHI data flows in the design, and minimize the PHI each component touches.
- Keep PHI out of logs, error messages, analytics tools and email notifications.
- Use separate environments, and never copy production PHI into test systems without safeguards.
- Sign BAAs with hosting, CRM, messaging and AI vendors before PHI flows to them.
- Restrict developer access to production and log it.
The proposed Security Rule update
In January 2025, HHS published a proposed rule to strengthen the HIPAA Security Rule, including proposals such as removing the distinction between required and addressable specifications, and more explicit expectations for encryption, multi-factor authentication and asset inventories. At the time of writing it was a proposal under public comment, but many of the measures are already good practice and worth adopting now.
We build healthcare workflows in Salesforce and custom software with these controls designed in from the start. See our industry solutions for how we approach regulated projects.
Technical safeguards in practice
| Safeguard | Practical implementation |
|---|---|
| Unique user identification | Named accounts, no shared logins, single sign-on where possible |
| Emergency access | A documented break-glass procedure with logging |
| Automatic logoff | Session timeouts appropriate to the environment |
| Audit controls | Access and change logs retained and reviewed |
| Integrity | Controls that prevent improper alteration of ePHI, such as field history and restricted edit rights |
| Authentication | Strong passwords plus multi-factor authentication |
| Transmission security | TLS for all connections, encrypted file transfers |
A pre-launch checklist for PHI-handling software
- Risk analysis updated to include the new system and data flows.
- BAAs signed with every vendor that will touch PHI.
- Access roles defined on the minimum-necessary principle and tested.
- Logging enabled, with PHI excluded from application logs and error tracking.
- Backups and restore tested.
- Users trained on the new workflows and privacy expectations.
- Incident response contacts and procedures confirmed.
Common gaps we find
- PHI in email notifications or subject lines.
- Production data copied into development or test environments.
- Former staff or contractors with active accounts.
- Analytics or chat widgets on pages that display patient information.
- Vendors processing PHI without a signed BAA.
Frequently asked questions
Does HIPAA require encryption?
Under the current Security Rule, encryption is an addressable specification, meaning it must be implemented where reasonable and appropriate or an equivalent measure documented. In practice, encryption is expected.
Do software developers need to sign a BAA?
If they create, receive, maintain or transmit PHI on your behalf, for example with access to production data, they are business associates and need a BAA.
How often should we do a HIPAA risk analysis?
HIPAA requires it to be accurate and current. Most organizations review it at least annually and whenever systems change significantly.
