Some of our most popular blog posts have involved discussions with Christian Kaestner, co-author of IEC 62304 and IEC 82304. He has brought us great insights into the underlying ideas of the people writing these standards and the standards' implications and interpretation throughout the industry.

You can tap into Mr. Kaestner's knowledge in his online course on medical device software and IEC 62304 in collaboration with Medical Device HQ

The full course is found here and a free short version is YouTube.

Once again, we have been fortunate enough to get a few minutes with Mr. Kaestner, who in this post elaborates on the current state of IEC 62304, 14 years after its initial release.

Q: With your extensive experience of both writing the standard and seeing how it has been used by the industry, how do today’s modern software companies approach and implement IEC 62304? Has IEC 62304 successfully stood the test of time? 

A: Well, both yes and no. Yes, because after almost 15 years the standard is now well known and established in the field. No, because the software environment has changed a lot since its first release in 2006. For example, the way we today use apps, cloud-based solutions, and AI, not to mention security aspects and the shift towards using Agile methods for software development! 

Q: Can we expect this to be covered by the upcoming edition 2? 

A: No, not really. I would say the main goal for edition 2 is to align better with IEC 82304-1, which is a product standard for health software (including medical device software). The scope of IEC 62304 edition 2 will be broadened from medical device software to health software.

This expansion has provided some challenges such as ISO 14971 for risk management is currently a normative reference, which means you must comply with also ISO 14971 to comply with IEC 62304. This cannot be required for general health software developers while risk management still is a vital part of a medical device software development process!          

Q: Many medical device software developers want to work Agile but find it difficult when reading IEC 62304, do you have any suggestions? 

A: It is no secret that the standard is written very sequentially and implies a classical V-model approach, but you are free to work in any way you want! If you struggle with implementing the standard, I suggest you consider the standard as a list of requirements that you have to fulfill but you can disregard the order in which they are written.

For example, there is a requirement to “Verify software requirements” but if you find it appropriate, you can do this as part of your software release. I will not say that it is formally incorrect, but I would argue it is a risky approach since late discoveries during the verification might generate a lot of re-work.

Likewise, if you use Scrum, it might be appropriate to include the activity “Verify software requirements” in for example sprint planning and verify the requirements contained in a sprint. You could even consider verifying software requirements on a story-based level!  

Figure 1: Incremental approach to verification of software requirements  

Q: The IEC 62304 Software Safety Classification seems to be the most contested part of the standard. Is the industry using the Software Safety Classification the way it was intended according to you? Are there any aspects of it that you feel should receive more attention? 

A: Interesting questions indeed… There have been many discussions over the past years about whether Software Safety Classification is needed or not. Some argue that Class C software development is the current state-of-the-art, and anything less than that is simply not acceptable these days. Still, Software Safety Classification will survive and remain in edition 2 (with some editorial changes).

Personally, I like the risk-based approach for two reasons; firstly, it increases the likelihood for low-risk software devices to enter the market which otherwise would have been too expensive and not make it to the market. Secondly, it increases the awareness of what parts of your software can be dangerous.  

Q: Can you elaborate a bit more about your second point about awareness? 

A: Early awareness of what can become harmful is a super valuable input to the architectural design because, with this information at hand, you can separate risky and non-risk functionality into different items. If this is done correctly, you can assign the appropriate classification to items and concentrate your safety efforts where it makes the most sense! And this is the essence of IEC 62304: focus your efforts on the risky parts! 

Figure 2: Items in a software system can be classified differently 

A final point on Software Safety Classification: note that the concept is based on injury, not harm as in ISO 14971. Harm is a much broader concept than injury and includes damage to property and environment which strictly speaking does not need to be considered when determining a Software Safety Classification.  

Q: The IEC 62304 Problem Resolution chapter has received some heat regarding the (at least perceived) overly cumbersome approach. Do you think there is any substance to these claims? Are there any best practices for how to best tackle the Problem Resolution requirements of the standard?  

A: Yes, the Problem Resolution is a bit strange to follow in the standard. Throughout the standard, there are requirements to use a “problem resolution process”.

However, in most cases, it does not make sense to use such a process as it is defined by clause 9 “Software problem resolution process”. For example, if a bug is discovered during a system test and the software is still not on the market, it does not make sense to “advice relevant parties”! 

My approach to this is to use a scalable process and use different approaches depending on whether the problem relates to released functionality or not. Where a problem relates to a released functionality, regardless of found internally (“Internal feedback”) or externally (“Feedback”), then all parts of clause 9 apply.

For all other problems, I use selected parts of clause 9 and work with a generic software problem resolution process. 

Figure 3: An approach to manage a software problem resolution process

About Christian Kaestner 

Christian has recently released an online course about medical device software and IEC 62304 in collaboration with Medical Device HQ. The full course can be found here, and if you are interested in a free short version, you can find it here on YouTube.

Christian Kaestner is a freelance software medical device consultant who often worksin close collaboration with QAdvis AB in Sweden. He is a member ofthe project team authoring IEC 62304 and was also part of the project team developing IEC 82304-1.

When developing according to IEC 62304, you are required to document your Software Architecture. One of the best ways to do just that is to use UM or SYSML. And one of the most widely used tools to document this kind of modelling is Enterprise Architect by Sparx Systems.

Integrating these design artefacts in your Aligned Elements traceability can now be done using the interface Aligned Elements - Enterprise Architect to access all your UML diagrams from within Aligned Elements.

Benefits

This will enable you to:

• Maintain traces between Design Input, requirements, specifications, detail design and EA diagrams.
• To trace from EA diagrams to any object in Aligned Elements.
• By using Inconsistency Rules, find out which requirements, specifications or detail designs do not have an EA diagram associated with it.
• Include the Enterprise Architect Diagrams in Aligned Elements reports.
• Include the Enterprise Architect Diagrams in Aligned Elements trace tables.
• Update Microsoft Word Documents with EA Diagrams by the press of a button using the synchronize Function.
• Link multiple EA repositories to an Aligned Elements project.
• Connect to server-based Enterprise Architect Repositories as well as to file-based repositories.

Getting Started

A few technical details:

• The integration works with both the EAP and EAPX repository file formats. It can also connect to EA repositories in database servers.
• If user authentication is activated for the EA repository, a user and password must be specified for Aligned Elements. The password is stored in an encrypted format in the Aligned Elements configuration.
• The Aligned Elements Enterprise Architect Integration is restricted works with diagrams. It can not trace to individual models.
• The diagrams rendered in Aligned Elements are automatically updated from the EA repository at a configurable interval.
• Aligned Elements has read-only access to the EA repository and can not make changes to the EA artefacts from within Aligned Elements

If you are interested in adding the Enterprise Architect Integration to your Aligned Elements project, contact us at Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.

The first amendment to the IEC 62304 was released in June 2015 and contains some welcome contributions, including:

• Clarification on the scope of the standard
• Information on how to approach Legacy Software
• Increased number of clauses applicable to Class A

There were also some interesting changes made to Software Safety Classifications in section 4.3.

For those familiar with the original IEC 62304 text, the following section describes to assign a Software Safety Classification:

"The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the possible effects on the patient, operator, or other people resulting from a HAZARD (being a potential source of Harm) to which the SOFTWARE SYSTEM can contribute.

The software safety classes shall initially be assigned based on severity as follows: 

Class A: No injury or damage to health is possible

Class B: Non-SERIOUS INJURY is possible

Class C: Death or SERIOUS INJURY is possible

If the HAZARD (i.e. the potential source of harm) could arise from a failure of the SOFTWARE SYSTEM to behave as specified, the probability of such failure shall be assumed to be 100 percent."

This is essentially saying that severity alone decides the classification of your software system/item/unit. Since there is no consensus on how to determine the probability of software failure, the probability of a failure to occur is assumed to be 100%, effectively eliminating the probability factor from having any kind of influence on the software safety classification. 

Now, software in itself has never killed anyone. When harm occurs due to a software failure, there is always some other executing agent involved, e.g. some piece of hardware or a human actor. Consequentially, for harm to occur, there must exist a causal chain of events, tying the software to the harm via that external agent. A causal chain of events occurs with some probability, sometimes called probability of harm.

Probability of harm did not play any prominent part in the original release of IEC 62304 and focusing by effectually removing the probability of failure from the equation due to the difficulties of establishing it in quantitative terms sometimes lead to more or less absurd results. 

In examples where a failure has severe consequences but is extremely unlikely to result in any kind of harm, the software safety class is C according to IEC 62304:2006 (if no hardware mitigations exist), regardless of how unlikely the risk of harm is.

And here is where the authors of the IEC 62304:2015 Amendment 1 have done a great job reformulating the Software Safety Classification section.

The IEC 62304:2015 Amd 1 section 4.3 point a) now reads:

"a) The MANUFACTURER shall assign to each SOFTWARE SYSTEM a software safety class (A, B, or C) according to the RISK of HARM to the patient, operator, or other people resulting from a HAZARDOUS SITUATION to which the SOFTWARE SYSTEM can contribute in a worst-case scenario as indicated in Figure 3.

The SOFTWARE SYSTEM is software safety class A if:
the SOFTWARE SYSTEM cannot contribute to a HAZARDOUS SITUATION; or
the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which does not result in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM.

The SOFTWARE SYSTEM is software safety class B if:
the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is non-SERIOUS INJURY.

The SOFTWARE SYSTEM is software safety class C if:
– the SOFTWARE SYSTEM can contribute to a HAZARDOUS SITUATION which results in unacceptable RISK after consideration of RISK CONTROL measures external to the SOFTWARE SYSTEM and the resulting possible HARM is death or SERIOUS INJURY.”

The pivotal point lies in the use of the terms "RISK of HARM" and "unacceptable risk". RISK, in this case, being a combination of severity AND probability.

Now, the probability of harm, (the probability that someone gets hurt) is different from the probability of failure (the probability that the software malfunctions).

The combination of these two probabilities becomes the probability of occurrence of harm. IEC 62304:2015 Amd 1, explains this further in section B4.3 and also includes a Figure (B.2) from ISO 14971.

This means that it makes sense to incorporate both the probability of failure and the probability of harm in our risk assessments. We will still stay true to IEC 62304:2006 by setting probability of failure to 1 (100%) (and avoid the problematic discussion of the probability of a software failure) and concentrate our efforts on correctly estimate the probability of harm.

The amendment of the standard also claims clinical knowledge might be necessary to correctly estimate that the probability of harm following a hazardous situation, in order to “distinguish between hazardous situations where clinical practice would be likely to prevent HARM, and hazardous situations that would be more likely to cause HARM.” This certainly makes sense since the casual chain of events leading from a hazardous situation to a harm typically takes place in a clinical context. 

There are also further complications. Where it previously was sufficient to map severity to the  “no injury”, “non-serious injury”, and “serious injury” categories, which is fairly straightforward, we now have the additional possibility of bringing in the risk's acceptability into the picture.

Establishing severity and probability is one thing that can be done fairly objectively, but in a rational manner argue why a particular combination of these factors is “unacceptable” or “acceptable” is subjective at best, opening the software safety classification establishing to an amount of arbitrariness. On the other hand, "unacceptable" and "acceptable" risks are terms defined in ISO 14971 and should therefore not be new territory to the average medical device manufacturer.

The software safety classification method in IEC 62304:2015 Amendment 1 has certainly become more intuitive. The price for this change lies in the extra effort of:

1. Establishing the probability of harm following a hazardous situation, with the involvement of clinical expertise if and where applicable.
2. Establish and rationalize what makes a particular risk limit acceptable or unacceptable, if not already defined in the general risk management process. 

To finalize this discussion on Software Safety Classification in IEC 62304:2015 Amd. 1, I would like to point out sections in the standard that have received some welcomed clarifications.

Segregation

The new version of the standard amends that segregation of software items does not necessarily have to be physical. In the 2006 version, the only segregation exemplified was hardware-related, which has lead to the false belief that segregation between items has to be physical. This is not the case. The 2015 Amendment makes it clear that the main concern is to assure that one item does not negatively affect another. Furthermore, the segregation applied shall make sense in the context it is used as well as clearly documented and rationalized.

Software Items implementing risk controls

A software item implementing a software risk control (i.e. not external risk controls which can have a positive effect on the classification) shall be assigned the same software safety classification as the software item containing the risk it is controlling. This idea is applicable not only on System level (as described in the 2006 version) but also Item/Unit level.

Learn more about how Aligned Elements can help you support IEC 62304

Request a live demo and let us show you how Aligned Elements can help you to comply to IEC 62304

If you develop software for a medical device then you have hopefully aligned your processes with IEC 62304 - Medical Device Software.

In an auditing situation, you might be required to demonstrate how you comply to this standard.

We give you a fast and trackable way to do just that!

Our IEC 62304 Checklist is integrated in Aligned Elements and lets you perform the assessment inside AE, taking advantage of inconsistency rules, tracing to existing project documents as objective evidence and simple export to word once completed.

The checklist includes 93 prepared audit questions based on the requirements in IEC 62304.

This is a simple and efficient way to demonstrate your company and software's compliance with the standard.

Download it here.

Sometimes when I ask development teams about their Software Unit verification, they fire up Nunit (or MSUnit or some other unit test tool) and say “Look here, we have more than 1800 unit tests with a test coverage way over 70%! Regarding Software Unit tests, we are certainly well covered!”

It is obvious to readers that the guys who wrote IEC 62304 explicitly tried to stay away from established software notions. You don’t see any “components”, “classes”, “modules”, “diagrams”, “dlls” or “objects” in the text (at least not in the English version). The authors did this on purpose in order to stay out of the nitty-gritty details of software development, to not make any technical prescriptions, and avoid a minefield of interpretations of concepts existing for decades. 

That’s why the norm speaks of software development in tech- and methodology-neutral terms. We have “architecture”, “items”, “interfaces” and “versions”. And, unfortunately, “units”.

This is just about the only notion where there seems to be confusion. Maybe not about units per se, but certainly about “Software Units verification”, which in some companies is translated to “Unit Testing”.

What is a “Unit”?

Unit testing was popularized by the practice of Test Driven Design and extreme programming in the late ’90s. JUnit was the first xUnit testing framework getting widely used and the concept was reused for other development stacks. The xUnit testing frameworks have since then evolved and are today widely used for automated testing in many industries, including the medical device industry. Over time, the frameworks have become increasingly versatile and are today used far beyond the original scope of classical unit testing. 

IEC 62304 defines the Software Unit as a Software item “not subdivided into other items”. According to the standard, it is up to the manufacturer to decide the granularity of items and therefore also the criterion for divisibility, making the definition somewhat arbitrary. Members of the medical device community have through lengthy discussions tried to agree on a practical interpretation of what a "Software Unit" is. Suggestions include:

• Class
• File
• Package
• Namespace
• Module

Unfortunately, there seems not to be a commonly accepted definition. This leaves us, the implementers of the standard, with much freedom and little support. 

Regardless of the manufacturers' definition of the “Software Unit”, the standard does require the unit to be “Verified”. Again, the IEC 62304 leaves it up to the manufacturer to define according to which acceptance criteria and through which means the verification shall be conducted.

Note that the verification of a Software Unit does not necessarily have to be a test (depending on the software safety classification). The verification strategy can be a walkthrough, inspection, review, results from static testing tools, or anything else that is valid and appropriate for the Software safety classification of the unit. Furthermore, the verification strategy, methods, and acceptance criteria are permitted to vary from Unit to Unit as long as this is appropriately documented.

Let’s now move the focus from the definition of a “Software Unit” in IEC 62304 to the definition of a “Unit” in classical "Unit Testing". Wikipedia suggests several definitions (which are all variants of the word “small”) but concludes that at the business end of unit testing, we find a piece of code that can be tested in isolation. This is in general a much finer level of granularity than "Software Units" in IEC 62304. Whereas a “Software Unit” in IEC 62304 is an architectural building block, a “Unit” in Unit Testing is simply something that can be tested in isolation with no explicit relation to the software architecture.    

Thus, summary so far:

1. A “Unit” as in Unit Testing is not the same thing as a “Software Unit” in IEC 62304.
2. A Test being executed in a xUnit Testing Framework does not automatically make it: 
   1. a classical Unit Test
   2. a Software Unit Verification.
3. A Software Unit can be verified by other means than tests (depending on the software safety classification).

 “But I really want to use my xUnit Tests for Software Unit Verification! What do I need to do?”

It is of course entirely possible to use unit tests run by an xUnit Testing Framework (or manually if preferred) as a verification method for Software Unit. However, the tests themselves are only a part of the required deliverables. Be careful to:

• Document the test strategies, the test methods, and the procedures used.
• Evaluate the procedures for adequacy and document the results.
• Establish and document acceptance criteria (more rigid for class C than A and B, see IEC 62304)
• Perform the tests and document the result.
• Explicitly evaluate if (and document that) the results fulfill the acceptance criteria.

Learn more about how Aligned Elements can help you support IEC 62304

Request a live demo and let us show you how Aligned Elements can help you to comply to IEC 62304

Documenting the design controls for a medical device is a mandatory exercise in our industry. Regulations describe what the documentation must show. Standards describe harmonized ways in which regulations can be fulfilled. Your quality management system should, in the best case, describe which process you need to follow in order to satisfy the standards and regulations, and finally, your company templates are what you use to finally pen it down.

However, regardless of the multitude of support systems, at the end of the day some of us given the task to provide a document, will sit down in front of the computer and think: 

But what exactly should I write?

Here is where we can help. The Aligned Elements Extension section contains more than 50 importable plug-and-play content packages that can help you accelerate the documentation process by leaning on collected experiences and best practices. Our extensions exemplify how Aligned Elements can be used to solve ubiquitous medical device documentation problems.

These extensions contain things like:

• Example Design Controls such as 21 CFR Part 11 Requirements, ISO 14971 Harms, etc.
• Ready-made configuration packages for e.g. IEC 62304 and IEC 62366
• Regulatory Wizards, such as finding out if your software is a medical device
• Queries
• XSLT - transformations to transform Aligned Elements into the desired output format

To make this even better: all extensions on our website are free to our customers.

Today, we added a new package of 120 Infusion Pump requirements exemplifying the Design Input for an Infusion Pump device. Let us help you. If you have questions about our extensions, please Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein. for more information.

Are you developing software for a medical device?

Then you probably know about IEC 62304 -“Medical device software – Software life cycle processes”. This standard describes what is expected of you when building software for your medical device. As it covers the entire device life-cycle, it specifies not only the development requirements but also covers maintenance, risk management, configuration, and problem resolution activities necessary for compliance.

This article will not analyze the IEC 62304 activities in detail (should you be looking for a more general overview of software development according to IEC 62304, I can highly recommend this presentation.).

Instead, we shall focus on a specific situation: you have an existing piece of software. It was not developed according to IEC 62304, but you want to use it in a device.

What are your options? Can you use that software at all? Is complete re-development the best, or even the only option?

Before answering these questions, it is necessary to step back and consider why this software was not developed according to the IEC 62304.

Is it a SOUP?

Let’s say the software was developed by a 3rd party, commercially or as open source. If so, this case is covered by treating the software as SOUP (Software of Unknown Provenance) according to IEC 62304.

“Unknown” in this context is not about the identity of the maker, but rather the lack of knowledge about the procedures used to develop the SOUP. As a consequence, there is an issue of trust regarding the software’s quality, its level of safety, and its potential risk of failure.

How does IEC 62304 let you get to grips with this lack of trust?

Start out by documenting all the functional/technical requirements that your use of the software results in. This gives you a good basis for writing the corresponding test cases that verifies correct functionality. It also serves as a starting point for identifying and assessing the risks associated with the functions of the SOUP.

After having analyzed the functional risks, you should proceed with identifying and assessing any risks from the integration of the software into your device. As a further risk identification source, you should, if available, get hold of a list of all the known bugs of the SOUP.

For all the identified and assessed risks, derived from the requirements, the integration, and the list of known animalities, you need to reduce the risks by applying appropriate measures.

Now, this might get a bit tricky. In many cases, modifying the SOUP itself might not be a viable option.

One known way forward is to provide dedicated error-handling and comprehensive, over-arching software risk mitigations in the software that uses the SOUP, which itself must be developed according to IEC 62304.

If you can foresee the reuse of this SOUP in other devices, you should consider designing an “insulation layer” around the SOUP. As a result, you get a wrapped SOUP which, in the context of your products, is safe to use.

However, note that all risk analysis activities described above to create a valid, safe SOUP, are conducted with a particular device's particular intended use and a particular risk acceptance profile in mind.

Thus, re-use of the SOUP, leveraging the SOUP documentation described above, is only valid if the target devices have similar intended uses and near-identical risk acceptance profiles. Using the SOUP in an HIV detecting device (Class C) requires a different risk assessment than when used in an allergy detecting device (Class A).

Is it Legacy Software?

Another scenario is that the software was developed in-house and put on the market before IEC 62304 was released.

If you now want to modify the software or use it in a different context, say with updated hardware, you can consider the software as “legacy software”. Amendment I to IEC 62304, released in 2015, describes the necessary steps.

Start out with a risk assessment. As the software is already on the market, you will have Post Market Data to include. Leverage this data as best you can. If your identified risks do not show up in years of carefully collected Post Market Data, you have a strong case for declaring your identified risks as acceptable! Truly a nice shortcut!

On the other hand, if you find reported risks that are not sufficiently addressed, you need to perform the necessary risk mitigation process steps described in 4.4.3 of the standard.

If you plan to modify the software before the next release, the changes must be part of the risk analysis. These modifications need to be made according to your IEC 62304 maintenance process, described in chapter 6 of the IEC 62304.

Amendment I to IEC 62304 can be your friend, especially if your risk assessment concludes that the risks originating from the use of this software are acceptable.

Is it a Prototype?

The most common scenario for having to bring an existing software into the folds of IEC 62304 is this: you developed a software prototype and, let’s be honest, you cut some quality corners during the rapid proof of concept phase.

Now it turns out that management loves your work! They are truly impressed by its dazzling features and, moreover, how fast you were able to achieve such great results! Just quickly make it IEC 62304 compliant and get it to the market!

Do you really have to start all over again? If your prototype is really just a prototype, then you should. But what if it turns out to have a clean architecture, modules separated by interfaces, and even have some unit tests in place? Wouldn’t that be good enough for IEC 62304?

No, not strictly speaking. IEC 62304 is a process standard. It is concerned with _how_ you develop your software, not the software itself. Since it is not possible to alter the past, “retrofitting the software into IEC 62304 compliance”, is formally not a way forward.

BUT. Let’s be a bit more pragmatic here.

It is rarely the case that software development is performed in the exact prescribed order defined by a software development process. Therefore, more often than not, there will be a set of remaining development and documentation tasks to finalize after your software is up and running. It could be those additional tests to write, a code review to add, or updating that detailed design document.

This is not specific to the IEC 62304 but applies to any software development or more general software lifecycle process. At times, the actual development and the process are simply slightly out of synch. As long as everything runs well in the end, all tests are passed, the process is largely followed and the documentation is complete and consistent, there is a good case for claiming compliance.

It would therefore be possible to argue that a prototype “catching up” with IEC 62304 is just an extreme case of this “getting back in synch” scenario.

Are there any downsides with this “catching up” approach?

Yes, potentially. IEC 62304 recognizes that the standard requires an extensive testing and documentation effort by the developers. It also recognizes that some parts of the software are less risky than others. As a result. IEC 62304 provides an opportunity to do a little less testing and documentation for the lower-risk parts, as long as you are rigorous about the high-risk parts. If this separation can be made, a lot of work can be avoided.

Why is this a problem for existing software? Can’t I just do a risk analysis on existing parts and then divide them into “safe” and “risky” ones?

Well, not quite. You will discover that a software architecture being efficient and easy to maintain, which is what most software developer intuitively implement and strive for, is not the same as an architecture which separates high and low-risk parts from a patient safety perspective.

If grouping of safety-relevant functionality into dedicated parts is not done from the start, the riskiness tends to spread out and “contaminate” all parts of the software. An architecture with many high-risk software items (parts) and very few low-risk items will ensue.

You can of course accept this situation and do the additional required steps. The IEC 62304 will allow it. But it is a foregone opportunity compared to designing your software with the IEC 62304 in mind from the very start.

Conclusion

Bottom line, is using an existing software not developed according to IEC 62304 worth the trouble?

As described above, depending on the situation, there are definitely options. It all boils down to comparing the inherited risks of the software to the benefit of using it. A very complex software, being hard to rewrite, but does not introduce significant risk is a good candidate for re-use.

However if the number of inherited risks are high and the offered functionality could also be realized by developing and documenting a new software according to an IEC 62304 compliant process, you should strongly consider doing just that.