IEC 62304 Edition 2: Important Updates Ahead

In this blog, we recap our recent webinar. Watch the entire presentation here: IEC 62304 Edition 2: What to Expect and Why It Matters.

IEC 62304 Edition 2: What to Expect and Why It Matters

IEC 62304, the international standard governing medical device software lifecycle processes, is undergoing its first major revision in nearly 20 years. While the upcoming second edition aims to clarify requirements and better reflect modern software practices, it also intentionally preserves the stability manufacturers rely on for compliance.

This webinar, co-presented with Medical Device HQ, provides a clear, practical view into the direction of IEC 62304 Edition 2, directly from someone involved in drafting the standard.

In this session, Christian Kaestner, member of IEC TC 62 / SC 62A and contributor to IEC 62304 Edition 2, joins Tom Rish, Head of GTM Strategy at Jama Software to explain what is changing, what is deliberately not changing, and what these updates mean in practice for medical device and Software as a Medical Device (SaMD) manufacturers.

Key Takeaways:

Understand why IEC 62304 is being revised and the core objectives of Edition 2
Learn how the IEC standardization process has shaped the scope and content of the revision
Discover what the draft edition says about key topics like SaMD and artificial intelligence (AI).
Hear why AI will not be a significant part of IEC 62304 — a deliberate design choice you need to understand.
Find out which proposed changes are most likely to affect your organization and get practical advice on how to prepare.

Get a grounded, standards-focused perspective on IEC 62304 Edition 2 and what it means for your software lifecycle processes.

THE VIDEO BELOW IS A PREVIEW – WATCH THE ENTIRE PRESENTATION HERE

TRANSCRIPT PREVIEW

Christian Kaestner: Thank you, Tom. So to avoid seeming too nerdy, I just want to share more of my human side, because we got a bit technical before, perhaps. I have three adult children, four cats, four beehives, 15 hens, and I love gardening. So now you know everything about me. Back to my nerd side, and what could be better than starting with a disclaimer? This is not an official IC presentation. It’s my perspective on the ongoing work, and I’m one of 73 experts on the project team. Even though I haven’t asked my 70-plus colleagues, I believe today’s presentation is a fair summary of the current status. I would say we are roughly 25 experts actively involved in the work, and it’s definitely a team effort. I just want to emphasize that it’s not my own work. Before we get going, I’m curious, what type of software do you mostly work with? So please participate in the poll and let me know what field of interests you have or what you’re working with.

Let’s see. We’ve got some poll answers. We’ll let you get some time to find the right window. So I see we have a combination, so a mix of both. It’s actually one-third each. Have you all agreed on voting like that? It’s interesting because sometimes there’s a tendency to believe that everything is sampled nowadays, but there’s still quite a big bunch of software in the medical SiMD components out there. Okay. Thanks a lot for participating. Let’s continue. While I’m presenting, perhaps you get bored, but if you do, please share your thoughts in the chat. I’m generally interested in hearing about any challenges you face with the current version of the standard, or what guidance do you seek regarding AI in medical devices? And as Tom mentioned before, please also use the dedicated Q&A box if you have any questions, and I’ll do my best at the end of this webinar to answer to your questions.

RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Medical Device & Life Sciences

Kaestner: Now, let’s get started. Before we discuss the upcoming changes in the second edition, I want to share the reasons behind these changes, because if you don’t understand what’s behind it, it might be difficult to understand why changes are implemented. I also want to provide insight into the behind-the-scenes process involved in developing standards. The first version of IEC 62304 was published in 2006 to meet regulatory requirements and expectations for standardized guidance on software development. In 2015, the standard was amended to include guidance on managing legacy software. The D, with the introduction of the legacy clause, was to help manufacturers bring products developed before the establishment of the standard into compliance. Additionally, there were minor changes to the software safety classification aimed at helping manufacturers manage the classification process more effectively, rather than consistently ending up in class C. Whether that really worked or not, that can of course be debated.

In addition, a major change is the scope shift from medical device software to health software. This adjustment is made to full align with IEC 820304-1, which is the product standard for standalone software, often called SaMD. There will also be simplification of the software safety classification by reducing the number of levels from three to two. And whether that will be simplification or not, we will get back to that, because it comes with some challenges as well. Lastly, considering that the current version is nearly 20 years old, I expect a new addition to include a level of, let’s say, modernization to reflect today’s state of the art. I haven’t seen any updated timeline for the project, but I’m guessing, or perhaps hoping, crossing my fingers, it will be finished by 2028, but you never know. And I’ll come back to why I don’t know, because there are some uncertainties on this path.

RELATED: Expert Perspectives: A Method to Assess Benefit-Risk More Objectively for Healthcare Applications

Kaestner: For those unfamiliar with the standardization process, here comes a short summary. It begins with a working drop, which is often referred to as a new work item proposal, and that’s especially when it develops the creation of new standards. It’s worth noting that there was a previous attempt to develop a second edition of IEC 62304. Unfortunately, this effort stalled due to challenges in achieving consensus among key stakeholders. However, an important outcome of that previous work was a design specification that now functions as a working draft and leads the project. The specification has guided the development of the first committee draft and will continue to inform the project moving forward. So you can see it’s kind of the rail guards for the project. Although not all national committees are happy about the design specification, it has gathered a majority acceptance, and the project team is keen not to deviate too much from the specification to avoid yet another stopped project.

Here is a summary of the key guiding principles for the project team. So as mentioned earlier, the scope will change to health software. Three levels will change to two. IEC 62304 is a process standard that relies on other standards for product-relevant requirements. This will be emphasized. So, where do you get, for instance, risk management from? And this is not all. Due to the scope change, normative references to medical device standards is not an option longer. The legacy clause has to some extent been used to cheat, unfortunately, I would say. This has resulted in suggesting moving the legacy clause to an informative annex. State of the art expects some level of architectural planning for all levels nowadays. Annexes shall be developed to cover relations to other standards and modern technologies, and also development methodologies such as agile. You will find a link to the design specification in the webinar resource section.

So if you’re interested in the details, please have a look. It’s just like, I think it’s two to three pages long, so it’s not that massive of a document. With the help of the design specification, a CD or committed draft was developed and sent out for commenting at the beginning of last year.

Together with the CD, a change rationale was provided to explain the changes being made, because some changes could seem like kind of unexpected perhaps, and that’s why the change rationale was provided as well to explain these changes. I’ve selected a few key topics addressed in the document. I will also revisit several of them shortly. So the classification of the former software safety classification will be called process rigor level, and the criteria for the determination of the level will also change. There will be new requirements for AI planning, and there will be clarification on supporting items to be controlled. Simply put, you must control whatever items are needed to recreate the software. Whether that is a compiler, test tools, or source code, it’s up to you as a manufacturer to determine what you need to control. The current version has some requirements for communicating with users and regulators. This is typically a product requirement and will be shifted towards the requirement for planning what information shall be communicated to whom and when.

THIS HAS BEEN A PREVIEW – TO WATCH THE ENTIRE WEBINAR, VISIT:
IEC 62304 Edition 2: What to Expect and Why It Matters

Author
Recent Posts

Tom Rish

Senior Product Marketing Manager at Jama Software

Tom Rish is a biomedical engineer with over 15 years of experience developing medical devices. His work has spanned the entire MedTech product lifecycle, from initial concept through market launch. He is passionate about helping others navigate the complex journey of bringing a device to market so that patients around the world can benefit from life-changing technologies. Tom is currently a member of the Product Marketing team at Jama Software.

[Webinar Recap] IEC 62304 Edition 2: What to Expect and Why It Matters