The first question people from outside the medical device industry usually ask is: does working under IEC 62304 and ISO 13485 standards slow you down? It’s the wrong question – but it’s understandable. The right question is: how does the regulated process change the outcome of your project?
Sections in this article:
Two standards, one team | The discovery phase | Three-phased process | Finalizing & approving the procedure | Tool validation | Implementation | What actually Changes | Practical notes for teams
Compliance with IEC 62304 and ISO 13485 is not a trade-off. In healthcare software, there is no version of “we moved fast and broke a few things”. There is only software that meets the standard and software that shouldn’t be in a medical device. What does change is the sequence and structure of development activities, the documentation that runs alongside the code, and the decisions a team can and cannot make independently.
This article describes what that looks like from inside a development team. We’ve been building IEC 62304 compliant software for 25 years. What follows is a practitioner’s account – not a summary of the standard, but a description of what it actually requires of the people writing the code.
Two standards, one team. What each one requires
IEC 62304 and ISO 13485 are often mentioned together, but they govern different things. Knowing the difference matters because it determines where a decision gets made – in the engineering team or in the QMS.
Standard | What it governs | Where you feel it |
| IEC 62304 | Medical device software and software life cycle processes – development, maintenance, risk management, configuration control, problem resolution | Daily engineering work: how code is written, reviewed, tested, and changed |
| ISO 13485 | Quality Management System – design controls, document control, traceability, CAPA processes | How documents are approved, how changes are authorized, how problems are escalated and closed |
For a software engineer, IEC 62304 defines the technical process. ISO 13485 defines the organizational framework where that process operates. They reinforce each other in practice: IEC 62304 requires you to maintain a Software Development Plan; ISO 13485 specifies how that plan must be version-controlled, approved, and referenced.
RomSoft is ISO 9001 certified and IEC 62304 and ISO 13485 compliant – we operate within IEC 62304 | ISO 13485-governed processes as part of our development partnerships, where the IEC corresponding certifications sit with our partners. Working within a certified partner’s QMS for over two decades has meant internalizing these standards not as external constraints but as the way we build software.
The IEC 62304 standard defines three risk classifications for medical device software: Class A (no injury), Class B (non-serious injury possible), and Class C (serious injury or death possible). Over the years, we’ve been working on projects bound by all types of risk classification. The higher the risk level, the more documentation and efforts to manage risks become necessary.
The discovery phase – structured freedom before the formal process begins
One of the things that surprises engineers coming from non-regulated environments is that formal development doesn’t start on day one. There is a deliberate initial period – the discovery phase – where the team explores the problem space without the full weight of the standard applied.
Why is this phase needed? The procedure that governs formal development must be written based on real understanding of the product – its architecture, its risks, its technical constraints. Writing that procedure before the team has explored the problem leads to procedures that don’t match reality. A procedure that doesn’t match reality is worse than no procedure, because it creates a false paper trail.
The discovery phase is where the team can prototype, evaluate architectural options, and identify the technical decisions that will need to be locked down in the procedure. Code written here is exploratory – it may or may not become production code, and it operates under slightly different rules than what comes later.
Team insightIn many of our projects, the discovery phase has been running for multiple months. This work adds up to the total development effort on a project spanning for a few years – a justified effort, given the architectural complexity involved. The code developed within this interval was written following the same software engineering best practices used in the rest of the project, including coding standards, code reviews, and testing activities. The objective is not rapid development without controls, but rather validation of architectural options and mitigating technical risks prior to the completion of the regulated process. The work itself is tangible: prototyping an architectural pattern, testing communication with external systems, and mapping out the data processing flow, with every key decision captured in Architecture Decision Records (ADRs). Those ADRs feed straight into the formal procedure – the software architecture, the technical risk analysis, and the development rules that govern the regulated phase – all tracing back to what was learned here. |
Three-phased process
After the discovery phase, development moves into a structured sequence of three phases. Each has a specific gate. You cannot move to the next phase until the current one is complete and approved. This sequencing is the mechanism by which the standard ensures that what gets built matches what was specified, tested, and validated.
Phase I: Finalizing and approving the procedure
The procedure defines how the software will be developed: what activities are required, in what sequence, with what outputs and what approval gates. It is based on what the team learned in the discovery phase, and it must be approved before a single line of production code is written.
The procedure is project specific. It references the applicable software safety class, defines the development of the lifecycle model, specifies required documentation for each activity, and identifies the tools that will be used. The last point is critical because those tools must be validated before development begins.
Team insightThe hardest part was creating a single process that could be consistently applied to multiple products, all developed under the same program. |
Phase II: Tool validation
Before writing production code, every tool in the development chain must be validated. The team must check that the tool performs correctly for its intended use, and that any malfunction would be detectable before affecting the final product. This covers compilers, static analysis tools, test frameworks, and version control systems. It also covers third-party libraries and frameworks.
Open-source software is generally not accepted in medical device development. The reason is traceability and support: if a defect is found in an open-source library that affects the device, the manufacturer cannot guarantee the fix, cannot control the timeline, and cannot always demonstrate the validation chain. This means teams sometimes need to write their own implementations of components that would be third-party libraries in any other context. As described in an earlier article this can be a genuine engineering challenge, but also an opportunity to build something precisely suited to the problem.
The second constraint in tool validation is version stability. Suppose a project is built on a specific version of a framework. When a new version is released, upgrading is not simply a technical decision. It potentially requires revalidation of the tool, re-running tests, and in some cases revisiting clinical trials. The cost of an upgrade in a regulated context is orders of magnitude higher than in standard software development. This creates strong pressure toward stability and means tool selection at the start of a project carries weight that it doesn’t in non-regulated work.
Phase III: Implementation
Development proceeds according to the approved procedure, using only validated tools. All the engineering decisions that feel routine in other contexts – adding a dependency, refactoring a module, changing an interface – go through a defined process: change request, impact assessment on risk and requirements, approval, implementation, verification.
Code written during the discovery phase can be brought into the production codebase, but only after it has been validated against the procedure: reviewed against requirements, assessed for risk impact, approved through the same process as any other code. The discovery codebase is treated like a source, not like a shortcut.
This is also where the interaction between IEC 62304 and ISO 13485 is most tangible. Every significant change generates a trail of documents: the change request, the impact assessment, the updated requirements if applicable, the test records, the approval. ISO 13485 governs how those documents are controlled. IEC 62304 specifies what they must contain.
Team insightTake a code refactor. In a non-regulated project, an engineer spots an inefficient function, rewrites it, and opens a pull request. Here, before touching a line of production code, the engineer opens a formal Change Request, links it to a specific Software Requirement Specification ID, and has the impact assessed – proving the change won’t introduce a new patient hazard. Only after a technical lead approves that assessment does the actual coding start. The same discipline applies across component boundaries. For example, before modifying a shared component in the platform, the engineer needs to evaluate whether the change could affect any of the applications built on top of it – checking affected requirements, risk, test coverage, and traceability, not just the code itself. |
What actually changes. And what doesn’t
The most important thing to understand about building under IEC 62304 is that the engineering decisions themselves don’t change. You still choose the architecture, write algorithms, debug performance issues, and refactor code. What changes is the governance around those decisions – how they’re made, recorded, and traced back to requirements and risk.
The analogy that resonates most with engineers who work in both regulated and non-regulated contexts: it’s not that you’re doing different work, it’s that every decision leaves a paper trail. After a while, you stop experiencing that as overhead and start experiencing it as clarity – because when a defect appears six months later, you can trace exactly what decision led to it and why it was made.
Team insightFor engineers new to medical device work, the formal process initially feels like a constraint – every change must be justified, documented, and traced back to requirements and verification. That perception usually shifts after an adjustment period, once the process starts delivering clarity: what needs to be done, who approves it, and how correctness gets demonstrated. A comparison that keeps coming up in our team is with building a race car. From the outside, it looks over-engineered, full of rules, checks, and controls. But those same mechanisms are what let it run at speed, reliably. The regulated process works the same way: it doesn’t remove engineering freedom; it creates the frame that lets technical decisions get made quickly and with confidence they’ll hold up. |
Where the process genuinely helps
There’s a reason regulated industries have lower post-release defect rates than standard software – the process catches problems earlier, when they’re cheaper to fix. In medical device software, a defect caught at the requirements review stage costs a fraction of what it costs if it reaches a clinical trial or, worse, a deployed device.
The discipline required to build medical software well – rigorous requirements, traceable risk management, formal change control – turns out to be the discipline required to build any complex software well. We bring that discipline to all our projects, not just the regulated ones.
Team insightAt one point, risk analysis surfaced a scenario the team hadn’t originally planned for: a brief network interruption occurring exactly when a clinician attempts to save a critical patient record. The feature itself would have worked against the original requirements. Luckily, the formal risk review found that a silent network drop could leave the user believing the data was saved when it actually wasn’t, potentially leading to clinical decisions being made on outdated information. That single find led to a set of risk control measures: implementing a local state cache, adding explicit sync-status indicators to the UI, and building automatic retry protocols. Therefore, requirements, tests, and verification records were updated to prove they worked. It’s a good example of the process surfacing a real risk during design, well before it could have shown up during integration or, worse, in the field. |
Where the process adds the most friction
From an engineer’s perspective, one of the most challenging aspects is that seemingly minor changes are not evaluated solely from a technical standpoint, but from many angles that will impact the way the change is approached.
Team insightThe genuinely frustrating part: a change that would ship the same day on a normal project, such as a small tweak, nothing architectural, can trigger a full impact assessment across requirements, risk, architecture, tests, and documentation once it’s in a regulated context. Some days, that really does feel like the process is slowing things down. But the pattern holds up over time: the hours spent on impact analysis up front are usually recovered later, in fewer integration surprises, fewer defects found late, and far less uncontrolled change creeping into the codebase. |
Why the stakes are different in medical software
It’s worth being direct about what compliance is ultimately protecting against. In standard desktop software, a crash is an inconvenience – you restart the application and continue. The bar for “acceptable” is set by user tolerance and competitive pressure.
In medical software, the bar is set by what happens when the software fails during a clinical procedure. The standard exists because the consequences of failure are categorically different.
Team insightA critical diagnostic report that fails to refresh on a physician’s dashboard due to an unhandled background error can delay a time-sensitive treatment. With proper risk management applied during architecture and design review, that synchronization behavior is designed with fail-safes and explicit user alerts from the start. The software doesn’t have to treat the patient directly to matter this much. It’s part of the information chain that clinical staff rely on: a bug, a freeze, or a displaced value can influence a clinical decision just as surely as a device malfunction would. That’s the difference the standards exist to protect against. |
Practical notes for teams entering regulated development
Based on two decades of working in IEC 62304-governed projects, these are the things we wish someone had told us clearly at the start:
1. Invest in the exploratory phaseThe temptation is to shorten it and move quickly to the formal process. Resisting that temptation is worth it. A well-explored inception phase produces a better procedure, and a better procedure produces fewer change requests and rework cycles downstream. |
2. Treat tool selection as an architectural decisionThe version you choose, the license model, the availability of vendor support – these have multi-year implications in a regulated context. A tool that’s fine for a six-month project becomes a liability in a product that will be maintained for years. |
3. Treat traceability as a design activityMany teams initially see traceability as something that happens after implementation. In practice, defining how requirements, risks, architecture, implementation and verification relate to each other early in the project prevents significant rework later. Good traceability is usually the result of good planning, not additional documentation effort. |
4. Design the development process around the product…not the other way around. A most common mistake is trying to force a generic process onto a product that has different architectural layers, responsibilities or development streams. The process should reflect how the software is actually built, tested and maintained. A process that matches reality creates clarity and does not encourage people to work around it. |
5. Risk management is more valuable than most teams expectTeams often approach risk management as a compliance activity. In practice, risk analysis frequently identifies missing requirements, architectural weaknesses and failure scenarios that would otherwise only be discovered during integration testing or validation. The most valuable output is often not the risk record itself, but the engineering discussions triggered by the analysis. |
6. Once the process becomes routine, it stops feeling like overheadFor teams entering regulated development, the process initially appears restrictive. Over time, the requirements, review steps, approval paths and quality gates become part of the normal workflow. The main benefit is not additional documentation, but increased predictability: decisions are easier to understand, changes are easier to assess, and defects are easier to trace back to their source. |
Closing note
Working under IEC 62304 and ISO 13485 changes the shape of development work – the sequence of phases, the governance around decisions, the constraints on tools and dependencies. What doesn’t change is the quality of engineering required to build software that does what it’s supposed to do.
If anything, the discipline the process imposes tends to surface problems earlier and in a form that’s easier to fix. The teams that work well within these standards are the ones that have internalized them as engineering practice rather than compliance overhead – where the procedure reflects how the team actually builds software, rather than describing an idealized process that exists only in documents.
We’re happy to talk about how we approach this in our development partnerships, or to compare notes with teams building their first regulated product. The learning curve is real – but it flattens faster than most people expect.
building your ownregulated software product?We’ve been developing software for certified medical device manufacturers for 25 years. We know what the process looks like from the inside – and we’re glad to talk about what it would mean for your project. |