The Startup MDVisit Website →
← Back to blog

Build IEC 62366 Software Evidence for FDA in 90 Days

September 24, 2026
Build IEC 62366 Software Evidence for FDA in 90 Days

IEC 62366-1 requires medical device software teams to run a full usability-engineering process, not a late-stage usability check. That means building a use specification, a use-related risk analysis (URRA), formative evidence as the design evolves, and summative validation when critical tasks demand it. The output is a traceable usability engineering file that connects every user task to a hazard, a risk control, and verification evidence. FDA guidance expects this work integrated into design from day one, not bolted on before submission.

TL;DR:

  • Conduct usability engineering early in development by compiling use specifications and initial risk analyses during Sprint 0 to prevent costly redesigns.
  • Use formative evaluations with small user groups throughout development to identify hazards before interface finalization, reserving summative testing for validation of the final design.
  • Establish clear traceability linking critical tasks, hazards, risk controls, requirements, and verification results to ensure compliance and smooth review processes.
  • Integrate usability tasks into the development backlog and maintain an up-to-date, linked traceability matrix to avoid documentation gaps and review delays.
  • Recognize that FDA's new guidance requires sufficient formative and summative evidence regardless of submission category, emphasizing continuous human factors integration.
The StartupMD
thestartupmd.com
Strengthen Your Healthcare Software Strategy
The StartupMD brings healthcare and technology expertise to help healthtech teams navigate growth challenges and improve operational efficiency.
Explore The StartupMD

Table of Contents

What IEC 62366 Software Requirements Actually Cover

IEC 62366-1:2015+A1:2020, the consolidated edition, specifies a process for analyzing, specifying, developing, and evaluating the usability of a medical device as it relates to safety. The standard does not care whether "the device" is a physical instrument, an embedded controller, or a standalone app. If the software has a user interface that a clinician, patient, or caregiver touches to accomplish a task with safety consequences, IEC 62366-1 applies.

The standard comes in two parts, and confusing them is a common early mistake. Part 1 is the normative requirements document. It states what a manufacturer must do. Part 2 is a technical report that offers tutorial guidance on how to actually do it, including examples of use scenarios, task analysis techniques, and evaluation methods. Teams building their first usability file often skip Part 2 and struggle to interpret Part 1's abstract requirements. Read both.

Software-only products sit at an interesting junction of standards. For software as a medical device (SaMD) with no accompanying hardware, IEC 62366-1 and IEC 62304 are generally the most directly relevant standards, since there's no medical electrical equipment in the picture. IEC 60601-1-6 stays relevant only when your software runs on or controls medical electrical equipment, such as an infusion pump interface or a diagnostic imaging console.

Three standards work together on any software-driven device:

  • IEC 62366-1 governs the usability-engineering process itself: identifying user tasks, analyzing use-related risk, and validating that the final interface controls that risk.
  • IEC 62304 governs the software development lifecycle: architecture, unit implementation, integration, and verification activities tied to software safety classification.
  • ISO 14971 governs risk management overall, and usability risk analysis is a required input to it, not a parallel, disconnected exercise.

Teams that treat these as three separate compliance checkboxes end up duplicating work and losing traceability. Teams that treat them as one integrated evidence chain move faster and produce cleaner submissions. Our guide to design controls and IEC 62304 walks through how design control documentation and software lifecycle records reinforce each other.

The Usability Engineering Process, Step by Step for Software Teams

The usability engineering process in IEC 62366-1 maps cleanly onto software development stages, but only if you start it before the interface is designed, not after.

  1. Write the use specification first. Define your intended users (their roles, training level, and any physical or cognitive limitations relevant to the task), the use environments (a hospital ICU, a patient's kitchen table, a moving ambulance), the use scenarios, and which functions carry safety consequences. A telehealth triage app used by an untrained caregiver at 2 a.m. has a radically different risk profile than the same logic embedded in a hospital EHR module used by a trained nurse.
  2. Run the use-related risk analysis (URRA). Identify hazards, the hazardous situations that could result from use error, and the specific tasks where a mistake creates harm. This is where you flag "critical tasks," the small subset of user actions where an error could cause serious injury. A dosage entry field is almost always critical. A dashboard color preference almost never is.
  3. Set acceptance criteria tied to risk controls. For each critical task, decide in advance what "acceptable performance" looks like and connect it to a specific design mitigation. This step gets skipped constantly, and it's the single biggest reason summative tests fail or produce ambiguous results.
  4. Run iterative formative evaluations. Test rough prototypes, wireframes, or early builds with representative users. Record every design change and the rationale behind it. Formative work is meant to be messy and fast. Five users and a paper prototype can surface a use error that would otherwise survive three sprints undetected.
  5. Decide when summative testing is triggered. Once the interface stabilizes and critical tasks are locked, validate the final design against your acceptance criteria under conditions that simulate actual use.

Pro Tip: Draft your use specification and initial URRA entries during Sprint 0, before a single wireframe exists. Teams that wait until the UI is "mostly done" almost always discover a critical task they never flagged, and by then it's a redesign, not a tweak.

The mistake we see most often in software teams new to this process: treating formative evaluation as informal usability testing you can skip if the roadmap is tight. FDA's own guidance frames human factors as something integrated into design and risk management, with formative and summative testing serving distinct, defined purposes, not interchangeable optional steps. Simulated use sessions during formative testing routinely surface hazards that never appear in a code review or a design walkthrough, because engineers using their own interface rarely make the mistakes real users make under real conditions.

Formative vs. Summative Testing: Choosing the Right Evaluation

Formative evaluation exists to steer the design while it's still cheap to change. Summative evaluation exists to prove the finished design controls risk adequately. Confusing the two, or running only one, is where most usability files fall apart under review.

Formative testing is iterative and largely qualitative. You're watching for confusion, hesitation, misinterpretation, and workarounds, not counting pass/fail rates. Small samples of five to eight representative users per round, run across multiple rounds as the design matures, typically surface the majority of usability issues worth fixing before the interface locks.

Summative testing is different in purpose and rigor. It validates the final, representative design against your predefined acceptance criteria, focused specifically on critical tasks. For software products, the most practical methods include:

  • Simulated use sessions where participants complete realistic scenarios on the actual (or near-final) interface, observed and recorded.
  • Moderated remote testing, increasingly common for SaMD and telehealth interfaces where representative users aren't co-located with the test team.
  • Task completion and error-rate metrics, reported against the Common Industry Format and ISO 9241-11 conventions that reviewers expect to see.

Small samples change how you interpret results. A completion rate of "100%" from a summative test with 15 participants doesn't mean the true population rate is 100%. Usability researchers have developed adjustment methods specifically for correcting small-sample completion-rate estimates, and reviewers who understand usability statistics will expect you to acknowledge that uncertainty rather than report a raw percentage as if it were definitive.

Present summative results by tying each critical task's outcome directly back to the risk control it was meant to validate, close loops, not just raw numbers. A results table that shows "Task 4: dosage adjustment, zero critical errors across N participants, validates risk control RC-07" tells a reviewer far more than a generic completion-rate summary.

Connecting Usability Work to ISO 14971 and IEC 62304

Usability findings mean little if they live in a separate document from your risk file and your software requirements. IEC 62366-1's URRA is a required input to the broader ISO 14971 risk management process, and every critical task should trace forward into a specific software requirement, a backlog item, and a verification result.

A clean traceability chain for a software team typically runs like this:

  • Critical task identified in the URRA (e.g., "enter and confirm insulin dosage").
  • Hazard and hazardous situation documented in the risk file (e.g., "decimal point misplacement leads to 10x overdose").
  • Risk control implemented in the design (e.g., "dosage field requires two-step confirmation with visual highlight above threshold").
  • Software requirement written to specify that control at the implementation level, tied to a backlog item or user story.
  • Verification evidence from both software testing (does the confirmation step function correctly?) and formative or summative usability testing (do real users actually notice and use the confirmation step correctly?).

The practical failure mode for agile teams is letting the risk file and the sprint backlog drift apart. A risk control gets implemented, ships, then gets refactored six sprints later without anyone updating the URRA or re-running the relevant usability check. Maintaining a living traceability matrix inside your version control system or backlog tool, linking each critical task to its risk control, backlog item, formative finding, and verification result, keeps that drift from happening and gives reviewers a single artifact to follow instead of five disconnected documents. Our breakdown of design controls and software lifecycle documentation covers how to structure this so IEC 62304 verification records and usability evidence reinforce, rather than duplicate, each other.

FDA Expectations for Human Factors in Software Submissions

FDA recognizes IEC 62366-1 as the process framework and expects human factors engineering woven through development, not compressed into a pre-submission testing sprint. The agency's guidance on applying human factors and usability engineering to medical devices lays out formative and summative testing expectations that reviewers use as their baseline when evaluating a submission's human factors section.

The bigger shift for 2026 comes from a new guidance document. FDA's Content of Human Factors Information in Medical Device Marketing Submissions, finalized May 29, 2026, introduces a risk-based structure for what human factors content a submission actually needs to include, along with an implementation timeline for adoption. It's worth understanding what this guidance does and does not change:

  • It restructures submission content categories, meaning how much human factors documentation you attach to a marketing submission now explicitly scales with the device's risk profile.
  • It does not lower the bar on the underlying design work. FDA town-hall materials on the guidance emphasize that the risk-based approach affects documentation packaging, not whether formative and summative evaluation need to happen in the first place.
  • A change to a user interface or labeling, even a seemingly minor one, can shift which submission category applies and what evidence a reviewer expects to see attached.

The practical takeaway: teams sometimes read a "lighter" submission content category as permission to skip rigorous design-stage evaluation. That's a misreading. Our software validation and CSA checklist covers how simulated-use evidence fits into a broader FDA-ready validation package.

A Sprint-by-Sprint Checklist for Building Compliant Evidence

Treating IEC 62366 as a document you write at the end of development guarantees rework. Treating it as a workstream that runs parallel to every sprint keeps evidence audit-ready without derailing your release schedule.

  1. Sprint 0 to 2: lay the foundation. Draft the use specification (users, environments, scenarios, safety-related functions). Start the URRA with your best current understanding of hazards and critical tasks, even if it's incomplete. Nothing here requires a finished design, just a clear picture of who uses the software and what could go wrong.
  2. Development sprints: connect backlog to usability requirements. Every backlog item touching a critical task should reference the specific usability requirement or risk control it implements. Run lightweight formative evaluations on new or changed features as they reach a testable state, five to eight users is usually enough to catch the obvious problems.
  3. Pre-release sprints: lock and validate. Finalize acceptance criteria for every critical task before freezing the UI. Execute summative validation testing where your risk analysis calls for it, using the final or near-final build under conditions that simulate real use.
  4. Release and post-market: keep the loop closed. Monitor complaints and incident reports for use-error patterns. Update the URRA and, where warranted, re-run validation evidence when a UI or labeling change touches a critical task. Usability engineering doesn't end at launch.

Pro Tip: Assign a single owner, not a committee, for the usability traceability matrix. When five people each think someone else is updating it, the matrix rots within two release cycles, and you find out during the next regulatory review, not before.

Teams that build this rhythm into their sprint cadence rarely face a scramble before submission. Teams that defer it face a compressed, expensive crunch where formative findings arrive too late to inform anything except a hurried summative test. Our walkthrough on avoiding 510(k) surprises for MDDS products covers how early use-error analysis prevents that crunch specifically for data-system and clinical decision support software.

Building the Usability Engineering File Reviewers Actually Want

The usability engineering file is the single artifact reviewers use to judge whether your process, not just your final interface, met the standard. A complete file includes:

  • The use specification, current and version controlled.
  • The URRA, showing hazards, hazardous situations, critical tasks, and linked risk controls.
  • Formative evaluation reports, documenting what changed and why, across each round.
  • The summative test protocol and report, including participant demographics, task scenarios, acceptance criteria, and results tied back to specific risk controls.
  • A traceability matrix connecting every critical task to its risk control, requirement, and verification evidence.

Structure the file so a reviewer can follow the logic without hunting across five disconnected folders. For FDA submissions using eSTAR, map your file's sections to the corresponding eSTAR human factors fields directly, rather than forcing a reviewer to translate your internal document structure on the fly.

The biggest structural mistake is treating the usability file as a static deliverable finished once and archived. Keep it living, linked directly to your backlog and version control system, so a change to a critical task's interface automatically flags which usability documents need review. A file that's three sprints out of date at submission time creates exactly the kind of traceability gap reviewers flag first.

Usability evidence traceability workflow

Where IEC 62366 Implementation Goes Wrong

Most software teams don't fail IEC 62366 because they skip steps entirely. They fail because they run the right activities in the wrong order or with the wrong rigor.

Delaying HFE until the UI is frozen is the costliest pattern. By the time the interface is "final," changing it to fix a discovered use error means revisiting requirements, architecture, verification, and risk documentation all at once, instead of adjusting a wireframe. Early, rough formative testing is far cheaper than late, comprehensive redesign.

Weak traceability between findings and risk controls shows up constantly in files we review. A formative report notes that users struggled with a screen, but nothing connects that finding to a specific risk control update or a closed-loop verification step. Reviewers read that gap as unresolved risk, whether or not the design was actually fixed.

Confusing submission category with design rigor is a newer pitfall following the 2026 FDA guidance. A device landing in a lighter documentation category still needs the underlying formative and summative work; the guidance changes what you submit, not what you're required to do.

  • Integrate usability tasks directly into the backlog so they're never a separate, deprioritized workstream.
  • Preserve design rationale for every formative-driven change, not just the change itself.
  • Define acceptance criteria before the interface stabilizes, not after.

Pro Tip: If your team can't point to the specific risk control a formative finding led to, treat that as an open risk, not a closed one, until someone can.

The StartupMD's Take: What to Prioritize First

Most healthcare SaaS founders bring in regulatory help too late in the process, after the interface is built and the deadline is close. That's backwards. Clinical and product leadership need to be in the room during use specification and URRA work, not just at the summative testing stage, because the decisions that shape critical task design happen months before any validation test runs.

A fractional Chief Medical Officer or clinical advisor earns their value here by catching use-related risks a purely technical team misses, the caregiver who's exhausted at 2 a.m., the nurse juggling three other alarms, the patient who's never used a health app before. That's clinical judgment applied to product decisions, not a compliance formality.

If your team is starting from scratch, target three milestones inside 90 days: a completed task analysis and draft use specification, a baseline URRA covering your critical tasks, and a drafted summative validation protocol ready to execute once the design stabilizes. Hitting those three gives you a defensible evidence trail well before submission pressure hits. The StartupMD's advisory and fractional CMO services exist for exactly this stage, bringing clinical judgment to product and regulatory decisions before they're locked in, not after. For teams still mapping out their broader compliance sequence, our regulatory basics guide for founders is a useful starting point, and partners like Vicedomini Softworks can help assemble the supporting technical documentation once your evidence strategy is set.

— Paul Bergeron MD, MBA

Sources

FAQ

What is the most recent version of IEC 62366?

The current edition is IEC 62366-1:2015+A1:2020, a consolidated version combining the original 2015 standard with its 2020 amendment. ISO confirmed the base 2015 edition remains current, and Part 2 continues to serve as the tutorial companion to Part 1's requirements.

Can you give an example of software as a medical device?

A standalone mobile app that analyzes skin lesion images and generates a risk score to guide a clinical decision qualifies as software as a medical device (SaMD), since it performs a medical function independent of any hardware device. A dosage calculator app for insulin that runs on a general-purpose smartphone without controlling any hardware is another common example, and both fall under IEC 62366-1 and IEC 62304 as the most directly relevant standards.

What is IEC 62366?

IEC 62366-1 is the international standard specifying the usability-engineering process manufacturers must follow to analyze, specify, develop, and evaluate a medical device's usability as it relates to safety. It applies to software interfaces the same way it applies to physical controls, covering use specifications, use-related risk analysis, and formative and summative evaluation.

What does FDA require for software in medical devices?

FDA expects human factors engineering integrated into design and risk management throughout development, following the framework in its human factors and usability engineering guidance. The 2026 content guidance adds a risk-based structure for what human factors documentation a marketing submission must include, though the underlying design and testing work doesn't change based on submission category.