HIPAA Compliant EHR Development: The Safeguard-to-Feature Checklist (2026)

A HIPAA compliant EHR is software built so the practice that runs it can meet the HIPAA Security Rule. Its safeguards sit mainly in three sections of federal law: administrative safeguards (45 CFR 164.308), physical safeguards (45 CFR 164.310) and technical safeguards (45 CFR 164.312). In practice that means about a dozen features: unique logins, role-based access, emergency access with review, automatic logoff, audit logs, tamper checks, strong sign-in, encryption, tested backups, and a signed business associate agreement with every vendor that touches patient data.

There is no HIPAA certification. Nobody can sell you one, and no EHR can carry one. What you can do is build each safeguard into the product and keep the test evidence. Our published Launch MVP tier, which has these safeguards built in, is $45K to $70K over 10 to 12 weeks.

This guide is for clinic owners, CTOs and founders building an EHR. It gives you one table to hand your development team, with a test for each row.

There is no "HIPAA certified" EHR

Asked whether an organization must "certify" its Security Rule compliance, HHS says no standard or implementation specification requires it. The same answer says HHS "does not endorse or otherwise recognize private organizations' 'certifications' regarding the Security Rule," and that such a certification does not stop HHS from later finding a violation.

HHS's Office for Civil Rights goes further in its note on misleading marketing claims: HHS and OCR "do not certify any persons or products as 'HIPAA compliant.'"

So read "HIPAA certified" on a vendor page as marketing. Ask for three real things instead:

1. The features. Does the software have each safeguard in the table below?
2. The evidence. Can the builder show a test result for each one?
3. The contract. Will every vendor that stores or handles patient data sign a business associate agreement (BAA)?

Compliance belongs to the organization using the EHR. The software makes it possible; your policies, training and risk analysis finish the job. If you are still deciding whether to build at all, start with our guide to custom EHR software development, then come back here for the security scope.

Required, addressable, and what "addressable" really means

The Security Rule labels each implementation specification as "Required" or "Addressable" (45 CFR 164.306(d)). "Addressable" is easy to misread as "optional." It does not mean that.

For an addressable item, the organization must assess whether it is reasonable and appropriate. If it is, they implement it. If it is not, they must write down why and put an equivalent alternative in place where that is reasonable (45 CFR 164.306(d)(3)).

Encryption is the best-known example: HHS's FAQ confirms it is addressable under the current rule. Our advice is to treat encryption, automatic logoff and integrity checks as required in any EHR you build. That is our judgement, not the text of the rule.

The rule today and the proposed update (status on 27 Oct 2026)

On 6 January 2025, HHS published a proposed rule to update the Security Rule, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (90 FR 898). HHS's fact sheet lists what it would change. Among the changes:

• Remove the "required" versus "addressable" split, so nearly every specification becomes required.
• Require encryption of patient data at rest and in transit, with limited exceptions.
• Require multi-factor authentication, with limited exceptions.
• Require written procedures to restore certain systems and data within 72 hours.

Status, checked 27 October 2026:

• It is still a proposal. The same fact sheet says "the current Security Rule remains in effect" while the rulemaking continues.
• The Federal Register lists only the proposed rule under its regulation number (RIN 0945-AA22). We found no final rule published.
• The official text of 45 CFR 164.308, 164.310 and 164.312 on eCFR (Title 45 up to date as of 23 October 2026) still carries the "Addressable" labels and shows no amendment after 2013.
• The government's regulatory agenda entry for this rule on reginfo.gov now lists it as a "Long-Term Action," with final action projected for July 2027. That is a projection, not a deadline. An earlier agenda entry projected May 2026, and that date passed with no final rule.

For what the proposal would change, see our HIPAA Security Rule proposed changes checklist. For code-level controls, see our HIPAA checklist for developers.

Our advice: build the cheap parts of the proposal now. Multi-factor sign-in, encryption everywhere and a restore test cost little at the start and a lot to retrofit. They are not legal requirements today.

The checklist: safeguard, feature, test

This is the table to hand your development team. Each row names the rule, the feature that meets it, and a test that proves the feature works. The tests are our recommended checks. HIPAA does not prescribe any of them.

Most of these tests run automatically on every release. The restore drill, the BAA register check and the access review are scheduled human tasks.

Technical safeguards in more detail

Most of the build effort goes into the technical safeguards in 164.312. This is one chart read in a well-built EHR: sign-in, role check, encrypted read and an audit event, whether access is allowed or denied.

Role-based access and "minimum necessary"

The access control standard says systems must allow access "only to those persons or software programs that have been granted access rights." The Privacy Rule adds that, outside of treatment, a covered entity must make reasonable efforts to limit patient data to the minimum necessary for the purpose.

In an EHR, this becomes a role model plus record-level rules. A biller needs diagnosis codes and insurance details but not the full progress note. Design roles with the clinic's real staff in the room. Roles that are too narrow push staff toward break-the-glass for routine work.

Break-the-glass: emergency access with review

The rule requires an "emergency access procedure" for getting patient data during an emergency (164.312(a)(2)(ii)). "Break the glass" is the industry name for the usual design. The phrase does not appear in the regulation.

A good break-the-glass feature has four parts:

1. A clear prompt. The user sees that they are outside their normal access and must state a reason.
2. Time-limited access. The extra access expires, for example at the end of the shift.
3. An alert. The privacy or security officer is told at once.
4. A review queue. Every event stays open until someone reviews it. Without this, break-the-glass is a back door nobody watches, and activity review expects someone to look.

Audit controls

164.312(b) asks for mechanisms that "record and examine activity." It does not list fields. Log reads as well as writes. Read logging is the part teams skip, and it is the part an investigation into snooping needs.

The rule does not set a retention period for audit logs themselves. The documentation rule requires keeping security documentation for six years (164.316(b)(2)(i)), and patients can ask for an accounting of certain disclosures going back six years (164.528). We recommend keeping audit logs for six years to match. That is our recommendation, not a legal ruling.

Encryption at rest and in transit

HHS's breach guidance says patient data encrypted consistent with NIST SP 800-111 (at rest) or NIST SP 800-52 and related guides (in transit), with the key not breached, is not "unsecured". In plain terms, a properly encrypted copy that is lost, with its key kept elsewhere, may fall outside breach notification. So encrypt every copy: backups, logs and search indexes too. Teams often encrypt the main database and forget the copies.

Administrative safeguards the software must support

Most administrative safeguards in 164.308 are policies. Several still need product work. The clinic must do a risk analysis (Required), and it cannot do an accurate one without your architecture document, data-flow map and list of every place patient data is stored. Hand those over with the software. Activity review (Required) needs real reports, because a practice manager cannot review raw log tables. Incident response (Required) needs alerts that reach a named person and a quick export of the relevant logs. The contingency plan (Required) needs an emergency mode: for a clinic, usually read-only access to today's schedule and charts while the main system is down.

Physical safeguards in a cloud build

164.310 covers facility access, workstation use and security, and device and media controls. In a cloud-hosted EHR, the data center's doors and locks are the cloud provider's job under its BAA. Your EHR still owns three things:

1. Workstations. Automatic logoff, and no patient data left in browser storage after sign-out.
2. Mobile devices. Encrypted local storage if offline use is needed, and the ability to wipe the app's data remotely.
3. Media disposal and re-use. Both are Required. In the cloud this means deleting data and keys on a schedule, and making sure test environments never receive real patient data.

A BAA with every vendor that touches patient data

The rule allows a vendor to handle patient data on your behalf only with a written contract that meets 164.314(a). That contract must require the vendor to follow the Security Rule, to bind its own subcontractors, and to report security incidents and breaches.

HHS's cloud computing guidance settles a common argument. A cloud provider that stores only encrypted patient data, and has no key, is still a business associate. "Lacking an encryption key does not exempt a CSP from business associate status."

The vendors that get missed are rarely the big ones. Build your BAA register from the system's real outbound connections. Check each of these:

• the cloud host (compute, database, storage, backups);
• email, SMS and patient-reminder services;
• e-fax and document services;
• error tracking and log tools, if any patient data can reach them;
• speech-to-text or AI note services;
• the support desk tool, if staff paste screenshots or chart details into tickets;
• the billing clearinghouse and any lab or imaging interface.

If a vendor will not sign a BAA, either keep patient data away from it by design, or replace it.

Patient rights the EHR must make easy

Two Privacy Rule rights also need features from day one:

• Right of access. Patients can inspect and get a copy of their records, and the covered entity must act on the request no later than 30 days after receiving it, with limited extensions. Build a records export that staff can run in minutes.
• Accounting of disclosures. Patients can ask for an accounting of certain disclosures made in the prior six years. Treatment, payment and operations disclosures are excluded. Log disclosures to outside parties as their own event type so this report is possible.

When a breach does happen, a covered entity must notify affected people without unreasonable delay and no later than 60 calendar days after discovery. Your audit log decides how fast you can work out who was affected.

Behavioral health: 42 CFR Part 2 adds rules on top of HIPAA

If the EHR will hold substance use disorder (SUD) treatment records, HIPAA is only part of the picture. 42 CFR Part 2 protects records from federally assisted programs that provide SUD diagnosis, treatment or referral (42 CFR 2.12 sets out exactly which records are covered). Whether a given clinic or unit is a "Part 2 program" is a legal question for the clinic's counsel.

HHS revised Part 2 in a final rule published 16 February 2024 (89 FR 12472). It took effect on 16 April 2024, and the compliance date was 16 February 2026. So these rules apply now. What they mean for the build:

• Label Part 2 records at the source. The system must know which notes, diagnoses, billing lines and messages came from a Part 2 program.
• Capture consent properly. Patients can give a single consent for future uses and disclosures for treatment, payment and health care operations, according to HHS. Store the consent as structured data so the system can check it before any disclosure.
• Attach the required notice. Each disclosure made with consent must carry one of the written statements set out in 42 CFR 2.32. Generate it automatically on every export, fax or interface message that includes Part 2 data.
• Block use against the patient. Part 2 bars use of these records in legal proceedings against the patient without their consent or a court order and subpoena (or a similar legal mandate), as HHS summarizes it. Flag Part 2 data in any release-of-information workflow.
• Security and breach handling. 42 CFR 2.16 requires formal policies to protect these records, and the section now covers breach notification as well.

Psychotherapy notes have their own rule under HIPAA. Most uses and disclosures of them need the patient's specific authorization. Store them apart from the general chart, with their own access rule.

What this looks like in a Nirmitee build

We start EHR builds from our open-source headless EHR, which exposes a FHIR R4 API with SMART App Launch. It passed 47 of 47 ONC (g)(10) SMART App Launch tests in Inferno on 11 June 2026 (repository). Those tests check standards-based access and authorization. They do not test HIPAA compliance, and we do not present them that way.

Our published price for a Launch MVP, with role-based access, audit logging and the HIPAA safeguards in this guide built in, is $45K to $70K over 10 to 12 weeks. We confirm a fixed price after a short discovery.

Before you sign with any builder

Ask for three things in writing:

1. The table above, filled in for your product, with the test for each row.
2. The list of every outside service that will receive patient data, and a BAA status for each.
3. The date of the last restore drill and how long the restore took.

If you want us to fill in that table for your EHR, talk to our team about our work as a custom EHR development company.

Building an EHR and want the safeguard table filled in for your product? See prices and example screens on our custom EHR development services page, or explore custom healthcare software development. Talk to our team.