Healthcare Software Testing: A QA Checklist for HIPAA Apps

Most HIPAA test plans fail in the same place: they check that the app works for the right user and never check what happens for the wrong one. Healthcare software testing has to prove the second half, because the Security Rule is written around who can reach patient data and what the system records when they do.

The good news is that the rule gives you a ready-made test outline. The technical safeguards in 45 CFR 164.312 name five standards, and each one converts into test cases a QA team can run.

What the Security Rule actually asks you to prove

It asks you to prove five things about electronic protected health information (ePHI): that access is controlled, that activity is recorded, that data isn't improperly altered, that users are who they claim to be, and that data in transit is guarded.

Those are the standards for access control, audit controls, integrity, person or entity authentication and transmission security. Every test case in your plan should trace back to one of them, and anything that doesn't is probably general functional testing, which still matters but isn't compliance evidence.

Traceability is also what makes the plan defensible later. When someone asks why you tested session timeouts, the answer is a line in the regulation, not a habit.

Required versus addressable: what that means for your test plan

The regulation labels only some of its implementation specifications as required. Everything else is addressable, which means you decide how to meet it and document the decision. It doesn't mean you can skip it.

Safeguard	Designation in 164.312	What QA should confirm
Unique user identification	Required	No shared logins; every action maps to one user
Emergency access procedure	Required	Break-glass access works and is logged
Automatic logoff	Addressable	Idle sessions end after the configured time
Encryption and decryption	Addressable	ePHI is unreadable at rest without the key
Mechanism to authenticate ePHI	Addressable	Altered or corrupted records are detected
Transmission integrity controls	Addressable	Data modified in transit is caught
Transmission encryption	Addressable	No ePHI travels over an unencrypted channel

Only two of the seven are required, which tempts teams to treat the rest as optional. That's a mistake, because an addressable item you skip needs a written reason, and "we ran out of sprint" isn't one. Test all seven.

A healthcare software testing checklist, safeguard by safeguard

Work through the safeguards in order and keep the evidence for each: test case, result, build number and date. Screenshots of passing runs are weak evidence, while logs and exported reports are strong.

Access control

Start with roles, because that's where leaks hide. Sign in as a patient and try to open another patient's record by editing the ID in the URL or the API call. Do the same as a receptionist reaching for clinical notes, and as a nurse reaching for billing.

Then test the edges: lockout after repeated failed logins, password-reset links that expire and can't be reused, and a session token replayed after logout. Pressing the back button after signing out should never show a cached chart.

Automatic logoff deserves its own cases, covering both idle timeout and a forced end after a fixed total time. And test emergency access properly. It should let a clinician in when normal permissions would block them, and it should leave a clear trace afterwards.

Audit controls

The rule asks for mechanisms that record and examine activity in systems holding ePHI. So trigger the events, then read the log. Log in, view a record, edit it, change a permission, export a file. Each action should appear with a timestamp, the user, the event and the device.

Next, try to break the log. Attempt to edit or delete entries as an ordinary admin. Either the attempt should fail or the attempt itself should be logged. A log that an administrator can quietly rewrite won't satisfy anyone who reads it during an investigation.

Integrity

Integrity is the safeguard teams forget, because nothing visibly breaks when it fails. Alter a record directly in the database and confirm the application notices. Upload a deliberately corrupted file and check that it's rejected or flagged.

Interrupt uploads halfway by cutting the network, then confirm you don't end up with a half-written record that looks complete. Backups belong here as well: restore into a staging environment, both partially and in full, and check the restored data matches what you backed up.

Transmission security and authentication

For transmission, inspect every channel that carries ePHI: the web app, the API, push notifications, email, and any link to a third party. Confirm the connection is encrypted, that an invalid certificate is refused, and that nothing sensitive sits in a URL or a notification preview.

For authentication, test that the system verifies the person asking is the person claimed. Multi-factor prompts shouldn't be bypassable by replaying an earlier request, and a password reset shouldn't hand over an account without a second check.

If your app exchanges clinical data with other systems, the same scrutiny applies to those interfaces. Our guide to FHIR integration for healthcare apps covers the integration side in detail.

Keep real patient data out of the test environment

Every test environment you fill with real records becomes another system that needs the full set of safeguards. Most teams find it far cheaper to test with invented patients.

Synthetic records cover the cases you need: a patient with no history, one with a long history, a record with unusual characters in a name, a duplicate. They also let you share failing cases in a bug report without a second thought. Where you can't avoid production-shaped data, restrict who can reach that environment as tightly as production itself.

Whichever route you take, write down where each test dataset came from. That sentence in the test plan will be the first thing an auditor asks for.

Testing mobile apps and third-party services

Photo by Sanket Mishra on Pexels

Mobile adds ePHI that lives on the device. Check what the app caches, whether data shows in the app switcher preview, and what remains after logout or uninstall. The OWASP Mobile Top 10, which has a 2024 release, is a sensible list to build the security cases from.

Third-party services need the same treatment. A video visit tool, a cloud host or an analytics script that touches ePHI belongs in the data-flow map you test against. We go deeper on the build side in our piece on healthcare app security best practices.

Test the breach response, not just the code

Software testing usually stops at the app boundary, but a breach is an organisational event. Under 45 CFR 164.404, notice to affected individuals is due without unreasonable delay and in no case later than 60 calendar days after discovery of a breach.

You can rehearse this. Take a simulated incident, such as a lost admin laptop, and time how long it takes to answer three questions: which records were exposed, which patients they belong to, and who sends the notice. If the audit log can't answer the first two quickly, that's a defect to file against the product.

It's also the cheapest way to find out whether your audit controls are useful in practice or only present on paper.

Where to start if you're building from scratch

Build the test plan alongside the design, not after it. The role model, the logging scheme and the session rules are far cheaper to get right in the first sprint than to retrofit after launch.

When we built OptimalMD's digital product end to end, from design through development to launch, that covered the website, the members portal and the mobile app. You can read about it in the OptimalMD case study.

If you're planning a new product, our apps and SaaS development team can scope compliance testing in from the first sprint. And if you're choosing who builds it, this guide to choosing a healthcare app development company lists what to ask about QA. For the wider rulebook around all of this, see what HIPAA compliant app development actually takes.

Finish by writing the plan down as a short matrix: safeguard, test case, evidence location, last run date. Rerun it before every release that touches authentication, logging or data storage.

Frequently asked questions

Is encryption mandatory under the HIPAA Security Rule?

Encryption is an addressable specification, both for stored ePHI and for data in transit. That means you must assess it and document your decision, not that you can ignore it. In practice, test that it's in place.

Which HIPAA safeguards are strictly required?

In the technical safeguards section, two implementation specifications carry the required label: unique user identification and the emergency access procedure. Every other specification there is addressable.

How long do we have to notify patients after a breach?

Without unreasonable delay and no later than 60 calendar days after discovering the breach, per 45 CFR 164.404. Earlier is better, so test how fast your team can identify the affected records.

Can we use real patient data for testing?

You can, but the environment then holds ePHI and needs the same safeguards as production. Synthetic data avoids that burden and covers the same test cases.

Cover photo by Pavel Danilyuk on Pexels