Healthcare Software Design: Building Patient-Centred Digital Products

• Classify your product before you design anything, since each regulatory category needs a different amount of design evidence.
• Make the wrong action impossible where you can, and treat warnings and confirmation dialogs as the fallback.
• Treat HIPAA and FTC rules as interface requirements, because what a screen shows after automatic logoff and which tracking scripts run on it are design decisions.
• HHS-funded healthcare organizations must meet WCAG 2.1 Level AA from May 11, 2027 (May 10, 2028 if they have fewer than 15 employees), and they'll expect the same of the software they buy.

Patient-centered design means the product works for the patient and for every clinician acting on the patient's behalf. The second half is easy to miss, because a nurse fighting a cluttered order screen is a patient safety problem even when the patient never sees the software.

In practice, it comes down to testable decisions made early, mainly which rules apply and which mistakes your product makes possible, and you only find the second by watching real users. Color palettes and rounded buttons come later, if ever.

Classify the product first, because that sets the evidence you'll need. A consumer symptom tracker and software that suggests a drug dose to a doctor sit under very different rules, and that changes both the scope of the design phase and what your team has to document.

A business associate is a company that handles protected health information (PHI, meaning health data that identifies a person) for a HIPAA-covered organization such as a hospital. Software intended for medical purposes may qualify as a medical device. ONC, the HHS office that certifies EHR software, now operates within ASTP, HHS's Assistant Secretary for Technology Policy.

Where you land depends on your product and contracts. HHS publishes health app use scenarios that explain when an app developer acts as a business associate, plus an FTC-led interactive tool that points you to the federal laws that may apply [2]. Run your product through it before the first workshop, then have a healthcare lawyer confirm the answer, because I build software and I'm not a legal adviser.

The FDA revised its clinical decision support software guidance in January 2026 [6]. Clinical decision support (CDS) is software that provides clinicians with recommendations, and one condition for staying outside device rules is that the clinician can independently review the basis for each recommendation. A screen that shows a recommendation without explaining why can push your product toward device territory.

Founders often call their product HIPAA-compliant in our very first conversation, usually before we've seen a data flow diagram or a single contract, and my reaction to that phrase never changes:

When a founder tells me their app is 'HIPAA-compliant,' my honest reaction is: compliant with what, and who checked? Compliance isn't a feature you ship. It covers how the whole system is run, not only the software. So my next question is always the same: where does patient data go, and who can see it?

Clinicians use your product in small gaps between other work. In a 2017 study in the Annals of Family Medicine, primary care physicians spent 355 minutes (5.9 hours) of an 11.4-hour workday in the EHR, including 86 minutes after clinic hours [7]. In the Mayo Clinic Proceedings study, each 1-point increase in SUS rating was associated with a 3% lower odds of burnout [1].

Good healthcare UX design starts with watching that work, though Milo has done less of it than I'd like:

We don't do many projects like this, so I don't have a large body of feedback from clinicians to draw on. I'd rather say that than pretend to a method we haven't practiced at scale.

Titan is the clearest example. It is desktop imaging software for surgeons and specialists working with fluorography and X-ray images. The hard problems were mostly technical. We built optimized algorithms for processing and compressing X-ray images, used GPU acceleration to take load off the CPU, created a system for manipulating data in real time during live fluoroscopy sessions, and designed it to handle patient information securely and in line with HIPAA. For a surgeon with no time, speed is the design. If the software lags during a session, no screen layout can fix it.

On Titan and on any other project of this kind, we work with the client the way we always do. Our designer runs workshops with the client, or with someone who represents them, and the number of sessions depends on the project. Our technical lead participates in those sessions and reviews the designs from a technical perspective. The designer builds a clickable prototype in Figma, and we work from that. A short walk-through of a real screen is easier for a busy clinician to react to than a document.

What did the Titan project involve?

Our Titan project page describes medical imaging software for surgeons and specialists, built to process X-ray images quickly while protecting patient data. One full-time developer worked on it for six months, alongside a project manager and a designer.

We haven't published measured outcomes for Titan, such as task times or error rates, so treat it as an example of how we set design priorities rather than as proof of results.

On a small budget, watch two or three clinicians do the real task in their real setting before you design, and note every workaround and paper form you see. Then test speed on the hardware they actually use.

The FDA defines a use error as a user action, or lack of action, that differs from what the manufacturer expected and could lead to harm [5]. The familiar cases are a wrong patient's record left open or a value typed in the wrong unit.

Evidence on usability-related harm is thin but useful. In a 2018 JAMA study, researchers reviewed 1.735 million patient safety reports filed from 2013 to 2016 at 571 Pennsylvania facilities and a large mid-Atlantic health system [8]. Only 557 of them, about 0.03%, explicitly suggested EHR usability contributed to possible patient harm, and 14% of those 557 potentially caused temporary harm.

Don't read that tiny percentage as reassurance, because a report only counted if the person filing it explicitly blamed usability, so 557 is a floor. AHRQ's primer on human factors engineering describes forcing functions, meaning design features that stop an unintended action from being performed, and it cites a serious medication overdose that happened partly because of confusing displays in one institution's order entry system [9].

In medical software, a small interface mistake can reach a patient, so I treat errors as a design problem first and a testing problem second. The best safeguard makes the wrong action impossible. A warning comes after that.

On Titan, surgeons work with fluorography and X-ray images in real time, so nothing can make them stop and think. A confirmation step that costs two seconds in a calm office gets clicked through automatically in a theatre. We design the wrong action out where we can. The patient's identity stays visible on screen; a save can only go to the open study; and a unit is fixed instead of being typed. Our technical lead reviews every screen in the Figma prototype for actions that are too easy to get wrong before the client sees it.

Most clinical products carry some version of the five risks below. Each has a safeguard that removes the mistake, plus a weaker fallback for when you can't build it.

Your designer needs to know the HIPAA Security Rule as well as your engineers do. Most of its technical safeguards end up as interface decisions, such as who sees which screen and what a locked phone displays.

On Titan, privacy and security were a design requirement from the start. The software handles patient information in medical imaging, so we designed it to protect that data under HIPAA, and that shaped what the system shows and stores, not only the code behind it.

The technical safeguards in 45 CFR 164.312 turn into design work like this [10]:

• Access control means systems allow access only to people granted it, usually implemented as role-based views, where a receptionist and a surgeon see different screens.
• Unique user identification is required, so every user gets their own login and a shared ward account is off the table.
• Automatic logoff ends a session after a set period of inactivity, so you need a fast way back in and a decision about what stays visible.
• Audit controls record activity in systems that hold health data, so design them for the compliance officer who needs to see who opened which record.

Automatic logoff is an "addressable" specification, which HHS says lets an organization decide whether the measure is reasonable and appropriate for its situation, and doesn't make it optional [11]. Notifications deserve the same care, because "Your biopsy result is ready" on a locked phone discloses far more than "You have a new message in your portal."

Third-party tracking is where design choices most often become disclosure problems. HHS OCR's guidance on online tracking technologies says tracking tools on a regulated entity's logged-in pages generally have access to PHI [12]. Tracking vendors must sign a business associate agreement (BAA) before receiving PHI. On June 20, 2024, a federal court vacated the part of the guidance about tracking on public pages that don't require a login, but the guidance on logged-in pages and mobile apps still stands.

If your app sits outside HIPAA, the FTC treats sharing health data without the user's authorization as a breach, with civil penalties of up to $53,088 per violation [3]. HHS published a proposed rule to strengthen the Security Rule in January 2025 [13], and the federal regulatory agenda now projects final action in July 2027 [14], so design to the current rule until the final text is out.

Patients often open healthcare software on their phones in a waiting room while they're unwell or worried, and many struggle with health information even on a good day. In the latest national measure, based on 2003 data published by HHS in 2008, only 12% of US adults had proficient health literacy [15]. No newer national measure of health literacy has replaced it, so it's still the best figure available, and it's a strong case for writing patient screens in plain language with one task per screen.

How patients reach your product matters as much as the screens. ASTP's Data Brief 77 found that in 2024, 65% of individuals were offered and accessed their online records or patient portal, and 57% reported using an app to access their records [16]. Encouragement mattered: 87% of people whose provider encouraged them to access their portal did so in the past year, compared with 57% of those who weren't.

The same brief found that 59% of individuals had multiple portals. In comparison, only 7% used an app to combine them [16], making the clinician-to-patient handoff a design problem, since every new account competes with the portals patients already juggle. Our guide to mobile application development services covers the build.

If your customers receive HHS funding, the answer is WCAG 2.1 Level AA, the middle of three conformance levels in the W3C's Web Content Accessibility Guidelines. When founders ask what we design to, my answer is short:

We do a standard Accessibility AA.

WCAG sets out how to make websites and apps usable by people with disabilities. Under HHS's Section 504 rule, which bars disability discrimination by organizations that receive HHS funding, those recipients must ensure their web content and mobile apps comply with WCAG 2.1 AA [17]. That includes content provided "through contractual, licensing, or other arrangements", which is why vendors now get accessibility questions in procurement.

HHS extended the compliance dates in an interim final rule effective May 7, 2026 [18], so recipients with 15 or more employees must now comply from May 11, 2027, while those with fewer than 15 employees get until May 10, 2028 [17]. Many articles still quote the original May 2026 date, so confirm your customer's date.

For older or unwell patients using small screens, a few WCAG 2.1 AA criteria do most of the work [19]:

• Text contrast of at least 4.5:1 against its background.
• Text that can be resized to 200% without losing content or function.
• Content that reflows at a 320 CSS pixel width without scrolling in two directions.

The rule names WCAG 2.1, although the W3C published WCAG 2.2 in December 2024 with nine new success criteria [20]. One of them, Accessible Authentication (Minimum), deals with login steps that rely on memory or puzzles, which matters if your patients struggle to sign in.

Testing means watching real clinicians and patients do real tasks, then measuring what happened. Track four metrics each round: the share of tasks completed, errors made, time on task, and a SUS score, which also lets you compare your product with the 45.9 SUS score physicians gave their EHRs [1].

Regulated products set a minimum number of test participants. Certified health IT must test each listed capability, such as medication ordering or drug interaction checks, with at least 10 participants, and the results must be documented in NISTIR 7742, the standard usability report format specified by ONC [4]. For medical devices, the FDA's human factors guidance, updated in August 2026, recommends validation testing with at least 15 participants from each distinct user group [5].

Everyone else gets more from small, repeated rounds with daily users. Our guide to MVP testing covers cheap early rounds.

The costliest mistake I see happens before the first build sprint:

The most expensive mistake is designing for how the product looks in a demo instead of how it's used between two other tasks. A clinician touches your tool for a few minutes around a dozen other things, so a screen that needs a second look is already too slow. Founders find that out after the build, when the redesign costs far more than the drawing did.

My one piece of advice before anyone draws a screen: put a clickable prototype in front of the person who will actually use it, not the person who will buy it, and watch where they hesitate.

The second mistake is skipping classification and finding out late that a feature, such as a dosing suggestion or a tracking pixel on a logged-in page, has changed which rules apply. Redesigning an older clinical system brings both problems at once, which our guide to legacy modernization covers.

Take these questions into your first design meeting:

• Which rules apply to this product, and has a lawyer confirmed it?
• Who are the daily users, and when can the designer watch them work?
• Which use errors could reach a patient, and which can the interface make impossible?
• What does the user see after automatic logoff, and what appears in notifications?
• Which third-party scripts run on logged-in pages, and do those vendors sign BAAs?
• Which WCAG level and version will you design to, and when is your customer's compliance date?
• Which metrics will each test round report, and how many participants does your category require?

For choosing a design partner, see our guide to UX design services, and for the build itself, our guide to web application development services.

Does HIPAA apply to my healthcare app?

It depends on who the app is for. If you handle identifiable health data for a hospital, clinic, or health plan, you're likely a business associate and HIPAA applies. Consumer apps usually fall outside HIPAA but may be covered by the FTC Health Breach Notification Rule, and HHS's app developer tool will help you check which applies before a healthcare lawyer confirms the answer.

Is my healthcare app a medical device?

It might be, if it's intended to diagnose, treat, or prevent disease, or to drive clinical decisions. The FDA's clinical decision support guidance, revised in January 2026, explains when recommendation software stays outside device rules, and one condition is that a clinician can independently review the basis for each recommendation. If you're close to that line, get regulatory advice before designing screens.

What accessibility standard applies to healthcare websites and apps?

Under the HHS Section 504 rule, organizations that receive HHS funding must ensure their websites and mobile apps meet WCAG 2.1 Level AA, effective May 11, 2027, if they have 15 or more employees, and May 10, 2028, if they're smaller. It also covers content provided under contracts, so vendors are asked about it during procurement.

How many users should I test a healthcare product with?

The right number of test participants depends on your regulatory category. ONC certification requires at least 10 participants for each listed capability, and the FDA recommends at least 15 participants from each distinct user group for human factors validation of medical devices. For unregulated products, small repeated rounds with daily users work better.

1. Melnick ER et al., "The Association Between Perceived Electronic Health Record Usability and Professional Burnout Among US Physicians," Mayo Clinic Proceedings 95(3):476-487, March 2020. Supports the 870-physician SUS score of 45.9, bottom 9%, grade F, and 3% lower odds of burnout per point. https://www.sciencedirect.com/science/article/pii/S0025619619308365
2. US Department of Health and Human Services, "Health Apps" (use scenarios and interactive tool), content last reviewed April 22, 2026. Supports when an app developer may be a business associate. https://www.hhs.gov/hipaa/for-professionals/special-topics/health-apps/index.html
3. Federal Trade Commission, "Complying with FTC's Health Breach Notification Rule," July 2024, edited January 2025. Supports coverage of non-HIPAA health apps, unauthorized sharing as a breach, and penalties of up to $53,088 per violation (unchanged for 2026). https://www.ftc.gov/business-guidance/resources/complying-ftcs-health-breach-notification-rule-0
4. ASTP/ONC, "Safety-enhanced design," 45 CFR 170.315(g)(3) certification test method, current. Supports user-centered design, at least 10 participants per capability, and NISTIR 7742 reporting. https://www.healthit.gov/test-method/safety-enhanced-design
5. US Food and Drug Administration, "Applying Human Factors and Usability Engineering to Medical Devices," final guidance issued August 3, 2026 (originally February 3, 2016). Supports the use error definition and at least 15 validation participants per distinct user population. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/applying-human-factors-and-usability-engineering-medical-devices
6. US Food and Drug Administration, "Clinical Decision Support Software," final guidance, January 2026. Supports the revised CDS guidance and the independent-review criterion. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software
7. Arndt BG et al., "Tethered to the EHR: Primary Care Physician Workload Assessment Using EHR Event Log Data and Time-Motion Observations," Annals of Family Medicine 15(5):419-426, September 2017. Supports 355 minutes (5.9 hours) of an 11.4-hour workday in the EHR, 86 minutes after hours. https://www.annfammed.org/content/15/5/419
8. Howe JL, Adams KT, Hettinger AZ, Ratwani RM, "Electronic Health Record Usability Issues and Potential Contribution to Patient Harm," JAMA 319(12):1276, March 27, 2018. Supports 1.735 million reports, 557 (0.03%) usability-related, 14% potential temporary harm. https://doi.org/10.1001/jama.2018.1171
9. AHRQ Patient Safety Network, "Human Factors Engineering" primer, September 15, 2024. Supports forcing functions and the order entry overdose example. https://psnet.ahrq.gov/primer/human-factors-engineering
10. Electronic Code of Federal Regulations, 45 CFR 164.312, "Technical safeguards," current. Supports access control, unique user identification, automatic logoff, and audit controls. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312
11. US Department of Health and Human Services, "Summary of the HIPAA Security Rule," content last reviewed August 7, 2026. Supports required versus addressable specifications. https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html
12. HHS Office for Civil Rights, "Use of Online Tracking Technologies by HIPAA Covered Entities and Business Associates," last reviewed June 26, 2024. Supports tracking on logged-in pages, BAAs with tracking vendors, and the June 20, 2024 partial vacatur. https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/hipaa-online-tracking/index.html
13. Federal Register, "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information," proposed rule, January 6, 2025. Supports the pending Security Rule update. https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information
14. McDermott Will & Schulz, "Final action on HIPAA Security Rule modifications now projected for July 2027," July 16, 2026. Supports the projected July 2027 final action date in the federal regulatory agenda. https://www.mcdermottlaw.com/insights/final-action-on-hipaa-security-rule-modifications-now-projected-for-july-2027/
15. HHS Office of Disease Prevention and Health Promotion, "America's Health Literacy: Why We Need Accessible Health Information," issue brief, 2008 (2003 NAAL data). Supports the 12% proficient health literacy figure. https://www.ahrq.gov/sites/default/files/wysiwyg/health-literacy/dhhs-2008-issue-brief.pdf
16. ASTP, Data Brief No. 77, "Individuals' Access and Use of Patient Portals and Smartphone Health Apps, 2024," July 2025. Supports 65% offered and accessed, 57% via app, 87% vs 57% with encouragement, 59% multiple portals, 7% combining apps. https://healthit.gov/data/data-briefs/individuals-access-and-use-patient-portals-and-smartphone-health-apps-2024/
17. Electronic Code of Federal Regulations, 45 CFR 84.84, "Requirements for web and mobile accessibility," current. Supports WCAG 2.1 AA, the contractual arrangements clause, and the May 11, 2027 and May 10, 2028 dates. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-A/part-84/subpart-I/section-84.84
18. Federal Register, "Extension of Compliance Dates for Nondiscrimination on the Basis of Disability; Accessibility of Web Content and Mobile Applications," interim final rule, published May 11, 2026, effective May 7, 2026. Supports the extended compliance dates. https://www.federalregister.gov/documents/2026/05/11/2026-09266/extension-of-compliance-dates-for-nondiscrimination-on-the-basis-of-disability-accessibility-of-web
19. W3C, "Web Content Accessibility Guidelines (WCAG) 2.1," W3C Recommendation, current edition May 6, 2025. Supports the 4.5:1 contrast, 200% resize, and 320 CSS pixel reflow criteria. https://www.w3.org/TR/WCAG21/
20. W3C, "Web Content Accessibility Guidelines (WCAG) 2.2," W3C Recommendation, December 12, 2024. Supports nine new success criteria, including Accessible Authentication (Minimum). https://www.w3.org/TR/WCAG22/