After being forced to re-authenticate every few minutes at a common workstation, the nurse eventually forgets to log out. That one habit is more security that most audits can't see. This happens to healthcare web applications every day. In paper, controls pass, and in practice, workarounds, support tickets and abandoned patient accounts are created. The solution is to create and evaluate security solutions that are based on real-world clinician and patient interactions.
Why Security and Usability Keep Colliding in Healthcare Software
Clinicians consider all additional logins to the system and the time they spend with patients. Patients have other restrictions. Many are older or anxious or opening the portal for the first time following a diagnosis. Controls that do not consider either group will have predictable behavior. One log-in for staff for an entire shift, tape passwords on monitors, leave sessions open on nursing station monitors, and take pictures of records with personal phones to pass along.
All of these are the incident that the original control was designed to prevent. On the patient's side, friction is expensive and has an impact on the outcome. A registration process that drops users at ID verification puts them back on the phone lines and paper registration. If a patient does not click on the portal, then he or she will not see the message for an abnormal lab result.
Security and usability are not mutually exclusive. They both fail the same users in the same situations, and should be in the same design process.
Designing Authentication and Access Around Real Clinical Workflows
Role-based access is problematic when roles are similar to actual roles. A need for scheduling and demographics for front desk staff. Codes and insurance information are required for billing. Both do not require clinical notes. There are generic tiers such as "basic" and "admin" that tend to over-provision due to every exception being addressed by tiering up.
The strength of the check is as important as how quickly the re-authentication can be done. Single sign-on, badge tap at shared workstations, biometrics at managed devices, and push-based multi-factor authentication all make proving identity easier, while not compromising on its strength. Timeouts should be used as contextually appropriate. A short one is required for a nursing station in a public corridor, a longer one can be used for a patient's own phone. In either case, there needs to be a way to store unsaved form data for an expired session.
In the design, there should be a break glass access. When a clinician needs to get to the record, they will do it in any way they can, and a logged, reviewed override maintains access to the record. Remove it and the override will be on a borrowed login. Adaptive authentication only introduces friction when signals change, like when a new device is used, an unusual location or a sudden bulk export.
Keeping PHI Contained Across the Front End, APIs, and Third Parties
The minimum requirement is to encrypt data in transit and at rest. The leaks occur where there is no encryption. In URLs and query strings that are seen in server logs, protected health information (PHI) is found. It also remains in the browser cache and local storage after logout, appears in the autofill on shared computers and is recorded in the verbose client side logs sent to a monitoring vendor.
The greater risk is from third-party scripts. In December 2022, the HHS Office for Civil Rights (OCR) provided guidance on online tracking technologies, and updated the guidance in March 2024. In August 2024, HHS withdrew its appeal of that federal court's ruling in Texas, which overturned the portion of the ruling that held IP addresses gathered on unsecured public pages to be protected. The trackers behind the logins weren't included in that ruling and guidance had already sparked class actions and breach notifications across the country. Do not use third party analytics on authenticated pages, unless a business associate agreement is in place for the vendor.
Scoping is required for FHIR integrations. An API should return the record that a particular screen requires, not the entire record. It also has to do with performance. Slow encrypted payloads force teams to aggressively cache on the client, thus reopening the exposure that was closed by encryption.
Accessibility, Consent, and Error Handling as Compliance Work
HHS-funded entities must make their websites and mobile apps compliant with WCAG 2.1 AA in the 2024 HHS Section 504 final rule. In May 2026, an interim final rule delayed the compliance date by a year, to May 11, 2027, for businesses of 15 or more employees, and to May 10, 2028, for businesses with fewer than 15 employees. Those dates did not move and so did not their nondiscrimination duty.
Consent flows should be no different. Four screens of legalese and a checked box is all that results when patients scroll over them. A plain language summary with the full terms at a single tap is more beneficial to patients and is more likely to stand up to a complaint.
Security weight is given to error messages. Login and password reset screens should not provide information about the existence or not of an email or patient ID, but should indicate what to do next. Provide alternatives to image CAPTCHAs and codes that can only be displayed for a few seconds. Users can see the protection in action, which helps to minimize support calls, as they can see the protection is working or not.The visible session status, last-login information and explicit confirmation before sharing or downloading minimize support calls, as users can see the protection is working or not.
Testing Security and UX as One Discipline
The defects that cause the most damage are missed by separating security and UX test tracks. A 10-minute "timeout" is considered to have passed security review. It also has a usability test on a new session. It doesn't work if a clinician is called away during a note, and returns to an empty form, which is not covered by either track.
There is a need to systematically test the role-permission matrix for access control. That's not only positive cases that specify what each role should see, it's also negative cases that specify what each role should NOT see, and the matrix should be re-run when a role or feature changes. Early detection of regressions through automated security, dependency and accessibility scans in the pipeline. They don't stand in for penetration testing, screen-reader testing or usability sessions with actual clinicians and patients. Those sessions should include shared devices, session interruptions, weak connectivity and emergency access.
Teams without in-house penetration testers or accessibility specialists often bring in outside validation before a major release or compliance audit. When comparing the top medical software testing providers, look past general QA credentials. Ask whether they've tested HIPAA-scoped systems, run usability sessions with clinical staff, and audited against WCAG 2.1 AA.
Conclusion
The cheapest security control in a healthcare web application is one nobody has a reason to bypass. Before approving the next one, put it in front of a nurse at a shared workstation near the end of a 12-hour shift. If she would work around it, others will too, and an attacker only needs one of them to do it.