HIPAA compliant software development means building the safeguards the HIPAA Security Rule asks for, such as access control, audit logging, integrity checks, authentication and encrypted transmission, into an application that handles protected health information. HHS does not certify software as "HIPAA compliant", so compliance comes from your system's design together with the policies, contracts and people of the organization that runs it.
This article is general information about how HIPAA affects software design. It is not legal advice. Have your privacy officer or counsel review decisions for your own situation.
Our healthcare software development services page gives the short version of how we handle this. This guide goes further: what the rules actually say, how each safeguard turns into code, where teams leak data without noticing, and how to test that the controls work.
What HIPAA asks of software
HIPAA's rules apply to covered entities (health plans, health care clearinghouses, and health care providers that conduct certain transactions electronically) and to their business associates, according to HHS's Security Rule summary. If you build software that creates, receives, maintains or transmits PHI for one of them, the rules reach your product.
Two rules matter most for a build:
- The Privacy Rule limits how PHI may be used and disclosed and gives patients rights over their information.
- The Security Rule covers electronic PHI (ePHI). It requires regulated entities to ensure the confidentiality, integrity and availability of ePHI, protect against reasonably anticipated threats and impermissible disclosures, and make sure their workforce complies (45 CFR 164.306).
The Security Rule groups its requirements into administrative, physical and technical safeguards. Engineers mostly touch the technical ones, but customers' security reviews ask about all three.
Two details are often misread:
"Addressable" does not mean optional. Some implementation specifications are marked Required and others Addressable. HHS says the addressable label lets an organization decide whether a specification is reasonable and appropriate. If it is, they must implement it. If it is not, they must document why and adopt an equivalent alternative where reasonable (HHS summary; 45 CFR 164.306(d)). Encryption at rest is addressable, so you will need a written reason if you skip it.
There is no HIPAA certification. HHS and OCR state that they "do not certify any persons or products as 'HIPAA compliant'" (HHS). AWS, Google Cloud and Microsoft say the same on their own HIPAA pages. When a vendor shows you a "HIPAA certified" badge, ask what was actually assessed and by whom.
One more note on timing. HHS proposed changes to the Security Rule in December 2024. HHS says the current rule stays in effect while that rulemaking continues (HHS NPRM page). Build to the current rule, and check that page before you finalize your controls.
The proposal would turn several practices in this guide into rules. HHS's fact sheet says it would require multi-factor authentication and the encryption of ePHI at rest and in transit, each with limited exceptions. It would also drop the line between required and addressable specifications, a change that reaches every addressable item in this guide (HHS NPRM fact sheet).
As of November 10, 2026, no final rule has been published. The Fall 2025 Unified Agenda lists it as a long-term action, with July 2027 as the target for a final rule (Fall 2025 Unified Agenda entry). Agenda dates are planning estimates, so this one may change.
Technical safeguards in code
The technical safeguards live in 45 CFR 164.312. Here is how each one usually lands in an application.
Access control on every operation
The rule asks you to allow access to ePHI only to people or software that have been granted it. Its required specifications are unique user identification and an emergency access procedure. Automatic logoff and encryption are addressable.
In practice:
- Every person gets their own account. No shared "front desk" login.
- Authorization is checked where the data is read or written, in the service layer, and not only on the screen. A check that lives in the UI does nothing for a request that arrives through your API.
- Permissions follow the job. A billing clerk and a nurse should see different parts of the same patient.
- API responses get trimmed to the fields the caller is allowed to see.
- Plan "break-glass" access for emergencies. Make it possible, make it logged, and have someone review it afterward.
Audit controls
You need mechanisms that "record and examine activity" in systems holding ePHI. The administrative safeguards also require regular review of those records (45 CFR 164.308(a)(1)(ii)(D)). So logs that nobody reads do not meet the requirement on their own.
Log who did what, to which record, when, and from where. Include reads, because "who looked at this chart" is a common question after an incident. Store audit records where application users cannot alter them.
Integrity
You must protect ePHI from improper alteration or destruction, and the addressable specification asks for an electronic way to confirm it has not been changed without authorization. For clinical data, the useful design is to never silently overwrite. Keep versions, record the reason for a correction, and reject an edit made against a stale version of the record.
Person or entity authentication
You must verify that whoever is asking for ePHI is who they claim to be. Strong sign-in for staff, scoped tokens for integrations, and a clear separation between a patient acting for themselves and a staff member acting on a patient's record.
The current text of this standard does not mention multi-factor authentication (MFA). It asks only for procedures that verify a person or entity "is the one claimed" (45 CFR 164.312(d)). The proposed rule described above would require MFA, with some exceptions. Under its definition, MFA checks at least two of these three kinds of proof (proposed rule in the Federal Register):
- Something the user knows, such as a password or PIN
- Something the user has, such as a token or smart card
- A personal trait, such as a fingerprint
We recommend MFA now on every staff account that can reach ePHI, including admin and support accounts. A stolen password alone then does not open the account. Building MFA in from the start also means sign-in will not need rework if the proposal becomes final.
Transmission security
You must guard ePHI sent over a network against unauthorized access. Integrity controls and encryption in transit are both addressable. In a modern web or API product, encrypting every connection, including internal service-to-service calls and links to interface engines, is the normal answer.
Hosting and Business Associate Agreements
A business associate is a person or organization that performs functions or services for a covered entity involving PHI. A subcontractor that handles PHI for a business associate is also a business associate (HHS sample BAA provisions). Before a business associate handles ePHI, there must be a written agreement that, among other things, requires it to follow the Security Rule, bind its subcontractors to the same terms, and report security incidents (45 CFR 164.314).
For hosting, HHS's cloud computing guidance settles a few questions developers ask often:
- A cloud provider that stores or processes ePHI for you is a business associate, and you need a BAA with it.
- That holds even if the provider only stores encrypted data and has no key. HHS also notes that encryption alone does not cover integrity and availability.
- The "conduit" exception covers transmission-only services. A provider that stores ePHI does not qualify.
- Using a cloud provider to maintain ePHI without a BAA violates the HIPAA Rules.
- OCR "does not endorse, certify, or recommend specific technology or products."
The major clouds offer BAAs, but each limits which services are covered. AWS says PHI should only be processed, stored and transmitted in the HIPAA-eligible services named in its BAA (AWS). Google Cloud advises that if you cannot disable an unsupported service, you must not use it for PHI (Google Cloud). Microsoft lists in-scope services and says that a BAA on its own does not make you compliant (Microsoft).
So the hosting task is an inventory. List every service that could touch PHI, including databases, queues, object storage, backups, email, error tracking, log search, analytics and AI APIs. Then confirm each one is covered by a BAA or is kept away from PHI by design.
Disposal and media re-use
The Security Rule also governs how ePHI leaves your systems. Its physical safeguards include a device and media controls standard for hardware and electronic media that hold ePHI. Two of its specifications are required (45 CFR 164.310(d)):
- Disposal. Policies and procedures for the final disposition of ePHI and of the hardware or media it is stored on.
- Media re-use. Procedures that remove ePHI from electronic media before the media are made available for re-use.
The other two specifications are addressable. Accountability means keeping a record of where hardware and media move and who is responsible for them. Data backup and storage means making an exact copy of ePHI that can be retrieved before equipment is moved.
In a cloud product, most of the media are not physical. A disposal plan should give each of these an owner and, for stored data, a retention period:
- Database volumes, snapshots and backups past their retention period
- Exports, reports and files left on shared drives after their job is done
- Staff laptops and phones that held PHI, before they are reissued or retired
- A customer's data when its contract ends, removed by an offboarding job that records what it deleted or returned
HHS breach guidance points to NIST Special Publication 800-88 for how media should be cleaned. PHI on media that "have been cleared, purged, or destroyed" that way, so that it cannot be retrieved, counts as unusable (HHS breach guidance). PHI destroyed that way is no longer "unsecured" (see breach notification below). On cloud hosting, the team cannot wipe the provider's disks. The risk analysis should record what the provider's documentation says about how it retires storage media.
Integrations: HL7 v2 and FHIR
Most healthcare apps exchange data with an EHR, a lab or a billing system over HL7 v2, FHIR, or both. Our guide on how HL7 v2 and FHIR differ covers the standards. The point here is that every integration is another path to PHI and needs the same controls as your screens.
- An integration account should only be able to read and write what that feed needs.
- Messages sitting in a queue or retry store are ePHI at rest. Protect and log them like any other storage.
- Repeated and out-of-order messages are normal, so processing must be safe to repeat.
- Interface errors often get dumped into a log with the full message attached. That is PHI in your logs (see the mistakes section below).
What changes in the delivery process
The rules do not only shape the product. They shape how the team builds it.
Environments. Keep PHI in production only. Development, test and demo environments should run on synthetic or properly de-identified data. HIPAA recognizes two de-identification methods, Expert Determination and Safe Harbor (HHS de-identification guidance; 45 CFR 164.514(b)). Stripping names out of a production dump usually is not enough to meet either one.
Access. Developers should not have standing access to production data. When support work needs it, grant it to a named person for a set time and log it. The Security Rule's workforce security and access management standards cover granting, changing and ending access (45 CFR 164.308(a)(3)–(4)).
Your vendors. If a development partner will have access to PHI, for example through production support, it is likely a business associate and needs a BAA. If it works only with synthetic data and never touches production, ask your counsel whether a BAA is needed. Either way, decide this before the work starts.
Training. The Security Rule requires a security awareness and training program for all members of the workforce, including management (45 CFR 164.308(a)(5)). On a product team, that means developers, QA and support staff, along with anyone else who has production access. Two of the program's four addressable parts are about staff habits: periodic security reminders and protection from malicious software. The other two, log-in monitoring and password management, depend partly on the product. The application's own sign-in can report failed log-in attempts and enforce password rules, so the training should teach the rules the product enforces.
HHS adds that covered entities must train staff on their breach policies and procedures (HHS breach notification page). We suggest building the sessions around the mistakes listed later in this guide, since engineers and support staff make them in daily work. Each person's completion date goes with the other records described under Documentation.
Code review. Add HIPAA-specific checks to review: does this endpoint enforce authorization at the service layer, does this change log any PHI, does it send data to a new third party, does it create a new copy of PHI somewhere?
Incident response. The Security Rule requires procedures to identify and respond to security incidents, mitigate harm and document outcomes (45 CFR 164.308(a)(6)). For engineers, that means alerting that reaches a person, audit logs you can actually query during an incident, and a written plan for who calls whom. When an incident involves PHI, the breach notification deadlines in the next section also apply.
Documentation. Policies and required records must be kept in writing for six years from creation or from when they were last in effect, whichever is later (45 CFR 164.316). Architecture decisions, risk analysis notes and "why we did not implement this addressable item" records belong here.
Breach notification and the records it depends on
The Breach Notification Rule (45 CFR 164.400 to 164.414) applies to covered entities and business associates when unsecured PHI is breached (HHS breach notification page). PHI that was encrypted or destroyed as HHS guidance describes is secured, so no notice is owed for it.
An impermissible use or disclosure of PHI is presumed to be a breach unless the entity shows a low probability that the PHI was compromised. That showing rests on a risk assessment of at least four factors:
- The nature and extent of the PHI involved
- The unauthorized person who used or received it
- Whether the PHI was actually acquired or viewed
- How far the risk has been mitigated
Most deadlines below run from the day of discovery. A breach counts as discovered on the first day it is known, or would have been known with reasonable diligence. Knowledge by any workforce member or agent counts, except the person who caused the breach (45 CFR 164.404). The same discovery rule applies to a business associate (45 CFR 164.410(a)(2)).
- A covered entity must notify each affected person without unreasonable delay and no later than 60 calendar days after discovery (45 CFR 164.404).
- If more than 500 residents of a state or jurisdiction are affected, it must also notify prominent media outlets there, on the same deadline (45 CFR 164.406).
- It must notify HHS at the same time as individuals when 500 or more people are affected. Smaller breaches go in a log and are reported within 60 days after the end of the calendar year (45 CFR 164.408).
- A business associate must notify the covered entity without unreasonable delay and no later than 60 calendar days after discovery. Where possible, it must identify each person whose PHI was involved (45 CFR 164.410).
A notice can be delayed only when a law enforcement official states that it would impede a criminal investigation or damage national security (45 CFR 164.412). A written statement delays the notice for the period it specifies. An oral statement allows a delay of no more than 30 days unless a written statement follows. The entity must document an oral statement and the identity of the official who made it.
For a software vendor working as a business associate, three parts of this rule depend on engineering. Read logging is the evidence for the "acquired or viewed" factor, and a system that logs only writes leaves that factor unanswered. Alerting and log review decide when a breach is discovered. Slow detection does not add time, because the clock can start on the day the breach would have been found with reasonable diligence. The same audit logs produce the list of affected people that the business associate gives the covered entity.
The rule also puts the burden of proof on the covered entity or business associate. It must be able to show that every required notice went out, or that an incident was not a breach (45 CFR 164.414). Counsel decides whether an incident is a reportable breach. The engineering team supplies the records that decision rests on.
Common mistakes that leak PHI
None of these shows up in a feature demo.
PHI in application logs. A request logger that records full bodies, an exception handler that prints the object it failed on, or an interface error that dumps a whole HL7 message. Logs then flow to a log service that may not be under a BAA. Log record IDs, not record contents.
PHI in analytics and tracking tools. HHS's online tracking guidance says tracking technologies on logged-in pages such as patient portals generally have access to PHI. A tracking vendor that receives PHI on your behalf is a business associate and needs a BAA, and a cookie banner is not a valid HIPAA authorization. A federal court vacated part of that guidance in June 2024, about tracking on unauthenticated public pages. HHS notes this at the top of the page. The logged-in portion still stands, and session replay and analytics scripts in a portal are the most common way PHI reaches a vendor.
Production data copied into test. Someone needs "realistic data" to reproduce a bug, so a production snapshot lands in staging, where access is looser and logging is thinner. Build a synthetic data set early so nobody is tempted.
Screenshots in tickets and chat. A support agent pastes a screenshot of a patient's chart into a ticket or a chat thread. Now PHI lives in a system nobody listed in the risk analysis. Give support staff a way to reference a record by ID, and say plainly in the support process that screenshots of PHI do not go into tickets.
Third-party services added without review. An email provider, an error tracker, a PDF service or an AI API gets added in a sprint. If PHI can reach it, it needs a BAA or a design that keeps PHI out.
An example from our own work
We built a clinical records and patient data platform for a private client. The case page describes a data layer that "logs why each value changed and checks permissions on every service call." An existing observation cannot be saved without a change message. When a clinical value changes, the service adds a replacement and voids the earlier entry, keeping the reason on record, and interceptors block direct edits that try to skip that path. Roles and privileges are enforced on service calls, so clinician screens and API modules go through the same checks. Masking can show that a record was withheld instead of leaving an unexplained gap.
Two other builds show the same pattern from different angles. The practice management platform with a shared encounter workflow runs staff actions and API requests through authorization before they reach any domain service. Its case page is direct about the limits: clinical deployment review and security setup are still needed before a practice goes live, and those controls alone do not make it compliant. The FHIR integration with access policies and a local message queue uses policies that can limit resource types or hide fields for a given caller, and it refuses an update made against an outdated version of a record.
These pages describe technical design. They do not claim, and we do not claim here, that those systems went through a HIPAA audit.
Build checklist: requirement, implementation, test
A starting point for your own risk analysis, not a substitute for one.
| Requirement (source) | What to implement | How to test it |
|---|---|---|
| Risk analysis (164.308(a)(1)(ii)(A), Required) | Data-flow map of every place PHI is stored, processed or sent, with risks and chosen controls | Review the map against the actual infrastructure inventory; every PHI-touching service appears |
| Unique user identification (164.312(a)(2)(i), Required) | Individual accounts for every person and integration | Try to find any shared credential in config, docs or the identity provider |
| Access control (164.312(a)(1)) | Role- and record-level authorization in the service layer; trimmed API responses | Call each API endpoint directly with a lower-privilege token and confirm refusal or trimmed fields |
| Emergency access (164.312(a)(2)(ii), Required) | Break-glass procedure that is logged and reviewed | Run a drill; confirm the access is logged and the review happens |
| Automatic logoff (164.312(a)(2)(iii), Addressable) | Session timeout after inactivity, or a documented alternative | Leave a session idle past the limit and confirm it ends |
| Audit controls (164.312(b)) | Append-only log of reads and writes with user, record, time and source | Perform a read and an edit, then find both events; confirm an app user cannot delete them |
| Activity review (164.308(a)(1)(ii)(D), Required) | Scheduled review of audit logs and access reports, with alerts | Check the review record exists for the last period |
| Integrity (164.312(c)) | Versioned records, recorded correction reasons, stale-version rejection | Submit an edit against an old version and confirm it is refused |
| Authentication (164.312(d)) | Strong staff sign-in; MFA on every staff and admin account (recommended now, required under the proposed rule); scoped tokens for integrations | Attempt access with expired, revoked and wrong-scope tokens; confirm every staff and admin account asks for a second factor |
| Transmission security (164.312(e)) | Encryption on all external and internal connections | Scan endpoints and internal links for unencrypted traffic |
| Encryption at rest (164.312(a)(2)(iv), Addressable) | Encrypted databases, backups and queues, or a documented alternative | Confirm encryption settings on every store in the inventory, backups included |
| BAAs (164.308(b), 164.314(a)) | Signed BAA with every vendor that handles PHI; PHI kept out of non-covered services | Compare the vendor list to signed BAAs and to each cloud's covered-service list |
| Incident procedures (164.308(a)(6), Required) | Alerting, on-call, written response plan | Run a tabletop exercise using real audit-log queries |
| Contingency plan (164.308(a)(7)) | Backups, restore procedure, emergency mode plan | Restore a backup into an isolated environment and verify the data |
| Disposal and media re-use (164.310(d)(2)(i)–(ii), Required) | Retention periods; deletion jobs for data, snapshots and backups; device wipe before re-use; customer data removed or returned at contract end | Pick a retired backup and a reissued device; confirm the PHI is gone and the deletion is on record |
| Security awareness and training (164.308(a)(5)) | Training for developers, QA, support and anyone with production access | Check the completion record for every person who can reach PHI |
| Breach notification (164.404 to 164.410) | Audit queries that list affected people; a written notice path to the covered entity | In a tabletop exercise, produce the affected-person list from the logs; time the exercise against "without unreasonable delay", with 60 calendar days as the outer limit |
| No PHI outside production | Synthetic or properly de-identified test data | Search lower environments, logs and tickets for real identifiers |
| Documentation (164.316) | Written policies, decisions and addressable-item rationale, kept six years | Confirm each addressable item has a recorded decision |
FAQ
Is there an official HIPAA certification for software?
No. HHS and OCR say they do not certify any persons or products as HIPAA compliant. A third-party "certification" can be useful evidence for a customer's review, but it does not replace the organization's own obligations.
How do SOC 2 and HITRUST relate to HIPAA?
SOC 2 is a CPA firm's report on the controls of a service organization. The AICPA's SOC 2 guide names five areas such a report can cover: security, availability, processing integrity, confidentiality and privacy. The AICPA has also published exposure drafts of proposed 2027 SOC 2 Trust Services Criteria, so check which version a report uses (AICPA).
HITRUST assesses and certifies organizations against its own set of controls, the HITRUST CSF, which HITRUST says brings several standards and regulations together. It also offers reports that translate its results into HIPAA terms (HITRUST).
In our view, both are useful evidence in a customer's security review, and neither replaces the HIPAA work itself. The risk analysis under 164.308(a)(1), the BAAs under 164.314 and the organization's own policies still have to exist.
Does my software development company need to sign a BAA?
If it will create, receive, maintain or transmit PHI on your behalf, such as by supporting production systems, it is likely a business associate and a BAA is required. If it only ever works with synthetic data, check with your counsel.
Is encryption required under HIPAA?
Encryption at rest and in transit are "addressable" specifications. You must implement them if reasonable and appropriate, or document why not and use an equivalent alternative. For most cloud-hosted applications, encryption is the expected choice.
Can I host PHI on AWS, Google Cloud or Azure?
Yes, if you sign the provider's BAA and keep PHI inside the services that BAA covers. Signing the BAA does not make your application compliant on its own.
Talk to us about your build
If you are planning a healthcare product, start with the data-flow map and the vendor inventory, because most of the decisions above follow from them. Our custom software development services page explains how we work, and when you are ready you can get a range for your healthcare build. For EHR-specific planning, see our guide to planning EHR software development.
