Why everyone gets ISO 13485 and IEC 62304 wrong
Most teams treat software lifecycle documentation as a checklist exercise. They create artifacts to satisfy auditors rather than to actually manage risk across the product. The result is paperwork that looks good on a shelf but falls apart the moment a single line of code changes in month fourteen of a three-year project. Let me be direct about what this topic actually covers. Medical Device Software Software Life Cycle Processes refers to the systematic framework governing how software is planned, designed, implemented, tested, and maintained throughout the lifespan of a medical device. The two primary standards you will encounter are ISO 13485 for quality management systems and IEC 62304 for the software side specifically. They overlap, they complement each other, and they both demand evidence that you knew what you were doing at every stage.
Medical Device Software Software Life Cycle Processes in Practice
The lifecycle breaks into three phases: pre-operation, operation, and post-operation. Pre-operation covers planning, requirements definition, and architectural design. Operation handles detailed design, unit implementation, integration, and verification. Post-operation includes maintenance, corrective actions, and configuration management. Here is where people stumble. They start writing software before they finish the software development plan. Or they write the plan after the software exists and then try to retroactively justify it. Both approaches create gaps that auditors will find within minutes. I had a client once who started implementing a patient monitoring algorithm without a finalized safety classification. They classified the software as Class B partway through development because their initial assessment was ambiguous. This forced a complete rewrite of test cases and added approximately six weeks to the timeline. The workaround was straightforward once we identified the issue early: we pulled the regulatory lead, the clinical evaluator, and the lead software engineer into a room for three hours and mapped every software function against the relevant hazard analysis. That exercise locked the classification down before a single line of production code was written. Safety classification is the single most consequential decision in the entire process. Misclassifying a module as Class B when it should be Class C means your verification and validation effort is insufficient. Misclassifying it as Class C when it is actually Class B means you are spending unnecessary time and money on documentation and testing that an auditor would have flagged anyway as excessive. The sweet spot is accurate classification based on documented hazard analysis, not convenience.
I also want to address something that basic guides usually skip. Configuration management is where most teams lose control. Software versioning in your source repository does not equal configuration management. A configuration item in a medical device context means every piece of software that makes up the device, its documentation, its build environment, and its test artifacts must be traceable from requirement to release. When I audited a team that maintained software on GitHub with proper branching but no formal baseline process, they could not demonstrate which version of a library had been used in a specific build. The fix was implementing tagged releases with a change log that linked each tag to a specific requirements traceability matrix entry. This took about forty-five minutes to set up and eliminated an entire audit finding. Requirements traceability deserves the same level of seriousness. I have seen requirements matrices that were either too granular — individual variables and UI strings treated as separate requirements — or too vague — single lines describing entire subsystems. Both extremes cause problems. The former makes the matrix unmanageable and slows down change impact analysis. The latter makes verification impossible because you cannot map a test case to a specific verifiable statement. A balanced approach treats each requirement as a single, testable statement that describes what the software must do, not how it must do it. If you can write "the system shall perform X" and there is exactly one way to prove whether X happened, you have a good requirement. If proving it requires interpretation, it is too vague. If proving it requires checking thirty different conditions, it is probably too granular.
Get the Full Details
The verification and validation distinction is another area where beginners consistently fail. Verification asks whether you built the software right. Validation asks whether you built the right software. These are not interchangeable terms. In practice, verification involves code reviews, unit tests, integration tests, and static analysis. Validation involves clinical evaluation, user testing, and risk-benefit analysis against the intended use. Teams that conflate the two tend to produce software that works correctly but does not address the actual clinical need. I saw one project where the team spent nine months perfecting a data export feature that clinicians never actually used. The validation step should have caught this much earlier. There is a practical method that works well for keeping verification and validation separate. Map every requirement to both a verification test and a validation scenario. If a requirement has a verification test but no corresponding validation scenario, flag it. If a validation scenario has no traceable requirement behind it, that is scope creep and should be reviewed. This mapping exercise typically takes one to two days for a moderate-complexity device and pays for itself by preventing rework during clinical evaluation. Now let me talk about what this process does not do well. It assumes a level of organizational maturity that many startups and small teams simply do not have. The documentation burden scales with software complexity and device risk class. For a Class C device with a large codebase, you are looking at hundreds or thousands of traceability links, dozens of test protocols, and multiple review cycles. This can consume significant engineering time. In my experience, a well-run team spends roughly twenty to thirty percent of total development time on lifecycle documentation and process activities for Class C devices. For smaller projects this percentage is misleadingly high because the overhead does not scale down proportionally.
If your team is under twenty people and working on a Class A or low-complexity Class B device, consider whether you need the full IEC 62304 framework or whether a simplified approach aligned with ISO 13485 clause 7 would be more efficient. You still need documentation, but the depth can be proportionate to the risk. Regulators generally accept this principle of proportionality if you can justify your decisions on paper. Anthrers tools you might encounter include Polarion, Jama Connect, and DOORS for requirements management. For simpler setups, a well-structured spreadsheet linked to a version-controlled repository can work adequately for lower-risk devices. The tool matters less than the discipline behind it. I have seen poorly maintained Polarion installations that were worse than nothing because the tool created a false sense of completeness. I have also seen simple but rigorous Excel-based traceability matrices that passed audits without issue. The one area where tool choice truly matters is automated traceability. Manual link-maintenance between requirements, design artifacts, test cases, and risk documentation becomes unsustainable past a certain project size. If your team is managing more than five hundred requirements manually, you are already behind. Automation tools that integrate with your test management and source control systems can reduce update time from hours to minutes and catch broken links that a human reviewer would miss.
Finally, here is something most guides will not tell you about post-market surveillance and maintenance. The software lifecycle does not end at release. Any change to deployed software triggers a new review of the relevant lifecycle artifacts. This includes patches, updates, and even bug fixes that modify behavior. Many teams treat post-market changes as minor and skip the full impact analysis. This is a common root cause of audit observations and, in rare cases, regulatory action. The fix is establishing a change control board with clear escalation criteria before you ship the product. Define thresholds — what constitutes a minor change versus a significant change — and document them. When something happens, you already know which path to follow. The hardest part of medical device software lifecycle processes is not the documentation itself. It is maintaining consistency between what you planned, what you built, and what you proved across a timeline that often spans multiple years and multiple personnel. The frameworks exist to force that consistency. The value comes from treating them as living processes rather than archival exercises.
