QA/RA Consulting, Auditing & Training
Menu
QA/RA Consulting, Auditing & Training
Software developers build reliable functionality. For software as a medical device (SaMD), teams must also show that software remains acceptably safe when it fails, receives unexpected inputs, or is used under foreseeable conditions. Risk-based planning assesses potential failure impact to determine where stronger requirements, defensive design, reviews, testing, traceability, and release evidence are needed.
Risk-based planning applies more attention where failure could have greater impact. IEC 62304 describes software at system, item, and unit levels; sometimes these are referred to as modules, components, services, libraries, or functions. What matters is defining boundaries and understanding how a failure could affect the software or contribute to harm.
Match the analysis to the decision: Start with system impact, examine the item or module performing the function or control, then define unit-level behavior and testing. For a developer, this translates into familiar questions:
Rather than treating risk management as parallel documentation, use it to guide requirements, architecture, verification, validation, and effort across the product lifecycle.
Risk-based thinking begins before coding. Early choices about structure, safety-related functions, requirements, development controls, and release evidence already influence product risk.
Software planning establishes these foundations and defines how risk will guide lifecycle decisions, rather than documenting them afterward.
Build risk review into existing tools and processes: Add safety-related acceptance criteria to user stories, identify backlog items that implement or affect controls, address failure behavior in architecture reviews, and use controlled continuous-integration evidence for verification.
Developers can translate technical failure conditions into controls and testable criteria; risk-management and clinical stakeholders can connect them to potential harm and intended use.
In Agile development, risk should appear in every sprint. Use scenarios define who may be affected, conditions of use, and where information or alerts could be missed or misunderstood. Capture these details in user stories and acceptance criteria.
Use backlog refinement and sprint planning to identify work that creates or verifies risk controls. Match review and testing rigor to failure consequences and harm severity.
Example: Time-sensitive patient score. For a time-sensitive patient score, a story might require clinicians to know when data are missing or stale. Criteria could require identifying those inputs, showing the last update, blocking unsupported calculations, and recording the condition. Evidence could include code review, automated boundary and communication-failure tests, and traceability to the risk control.
Requirements are an early risk-control opportunity. By defining safety, performance, usability, reliability, and failure behavior, they show what must be implemented, verified, and validated.
Example: Incorrect clinical calculation. A SaMD score supporting treatment decisions could be wrong because of a unit-conversion defect. Controls might include explicit unit types, input-range validation, boundary testing, comparison with an independent calculation, and blocking results when inputs are invalid. This function merits more rigor than a low-impact preference screen.
Architecture converts risk decisions into design choices. How functions, interfaces, and components are organized affects complexity, reliability, maintainability, change control, and verification.
Risk-based planning prompts teams to ask not only Can this architecture work? but also How does it support effective risk control?
Example: Architecture isolates a safety-related function. Separating a high-impact calculation from reporting, analytics, and preference services can prevent noncritical failures from cascading into a safety-related function. Strict interfaces, dependency isolation, safe failure behavior, input monitoring, and segregation testing can reduce product risk and limit which components need equal rigor.
A risk-based approach does not reduce verification and validation; instead, it focuses effort on the functions, failures, and use conditions most important to patient safety, product performance, and intended use.
If an application displays data from another system, communication failure could make stale information appear current. Timestamps, stale-data detection, alerts, and interrupted or delayed communications must all be tested to prevent unsupported calculations. This makes failure behavior a requirement instead of a late integration defect.
Example: A software update changes a shared library. When upgrading a third-party library or shared component, do more than confirm that the build works – identify dependent functions, assess effects on risk controls, review release notes and known anomalies, and select regression tests from that impact analysis.
Disconnected requirements, risk records, design outputs, and test evidence weaken risk management. Linking them shows how decisions affect the product and supports change evaluation, issue investigation, and post-release assessment.
A reviewer should be able to trace an identified risk to its control, implementation, and evidence. Clear traceability explains why the control exists, how it was verified, and how evidence supports residual-risk evaluation.
Risk information becomes a practical decision tool, helping teams choose necessary requirements, architecture, testing priorities, and post-release change evaluations. Keeping requirements, architecture, verification, validation, and risk evidence connected supports sound decisions throughout the software lifecycle.
ELIQUENT Life Sciences offers training and advisory services in medical device software development, risk management, verification and validation, design controls, and quality systems. Explore its offerings to strengthen risk-based decisions across the software lifecycle. Learn more about ELIQUENT Life Sciences’ training and consulting services.
US Office Washington DC
