Send your request Join Sii

Releasing a medical device (MD) to a single market is difficult, but addressing multiple markets simultaneously adds more complexity. Each market has its regulations that MD manufacturers must comply with. Moreover, regulations constantly develop along with civilization, technological progress, and widespread globalization.

As a result of this phenomenon, a new FDA guideline for MD Software pre-market submission emerged last year and inspired this article. Before the new release, the FDA distinguished software classes between three “Levels of Concern,” which closely resembled the safety classes defined in IEC 62304. Now, one has to switch to the cryptic-sounding “Documentation Levels” instead.

Against the backdrop of the above modifications, the article discusses what changes in US regulations an MD software manufacturer faces and how this reflects the EU’s pre-market submission requirements. Delving into the key similarities and differences between the US and EU markets, important issues are highlighted for companies looking to sell their MD software in the two largest medical markets.

US and EU MD regulations overview

Both US and EU regulations categorize MD software as a medical device. The regulatory authority for medical devices in the United States is the Food and Drug Administration (FDA), while in the EU, it is the Medical Device Regulation (MDR) or In Vitro Diagnostic Device Regulation (IVDR). Do US and EU regulations share identical rules and classifications? Unfortunately, not. However, there are some similarities worth exploring.

MD software’s pre-market submission path appears in additional standards and guidelines. The FDA used to describe it in “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices” (issued on May 11, 2005), but it has been replaced with guidance for Industry and FDA Staff, “Content of Premarket Submissions for Device Software Functions” (issued on June 14, 2023).

IEC 62304, a standard describing the MD software life cycle process, is the basic document reflecting EU MDR or IVDR requirements for MD software pre-market activities.

FDA Level of Concern vs Documentation Level

FDA used to define three Levels of Concern to determine the amount of documentation required for submission, which were:

Levels of Concern (Source: FDA Guidance for the Content of Premarket Submission for Software Contained in Medical Devices)
Fig. 1 Levels of Concern (Source: FDA Guidance for the Content of Premarket Submission for Software Contained in Medical Devices)

The manufacturer had to choose and stick with one Level of Concern (“LoC”) to proceed.

The FDA guide provided questions to be asked to assign the appropriate LoC. If a “yes” answer was given to any of the listed major/moderate level questions, the appropriate level was awarded. A “no” to all questions meant a minor level was assigned

.

FDA Level of Concern Determining Scheme
Fig. 2  FDA Level of Concern Determining Scheme

Things changed when new FDA guidance has been issued. Instead of the LoC, one goes directly to categorizing required documentation, which is called the Documentation Level. It can be either Basic or Enhanced.

Documentation Levels (Source: Content of Premarket Submissions for Device Software Functions)
Fig. 3 Documentation Levels (Source: Content of Premarket Submissions for Device Software Functions)

What happens in the aftermath? FDA-recommended documentation must be adapted as the situation evolves. Below is an outline of these changes.

This data is presented in simplified terms to highlight the fundamental differences between documentation levels established by the FDA. To check the exact FDA recommendations, please refer to the mentioned guidelines.

FDA recommended documentation based on Level of Concern (outdated)
Tab. 1 FDA recommended documentation based on Level of Concern (outdated)
FDA recommended documentation based on Documentation Level (valid)
Tab. 2 FDA recommended documentation based on Documentation Level (valid)

*DoC – Declaration of Conformity with the FDA-recognized version of IEC 62304

What has changed compared to the previous version of the guide? Trying to present these levels together, the same or similar categories of software documentation can be combined:

FDA recommended documentation from LoC vs. Documentation Level
Tab. 3 FDA recommended documentation from LoC vs. Documentation Level

*DoC – Declaration of Conformity with the FDA-recognized version of IEC 62304.

The colors used served as a tool to highlight similarities (green/orange area) and differences (black area) between one level from LoC and another from the Documentation Level. Diving into this data, the following conclusions can be drawn:

  • The new basic/enhanced requirements resemble the old moderate and major levels: the enhanced level is only the primary level in a new edition, and the basic level, apart from minor differences (e.g., approach to SDS), can replace the content of the moderate level.
  • Not including any minor level equivalent, the FDA has significantly raised the bar for new software submissions.

IEC 62304 Software Safety Classification

The extent of documentation to be met in the EU is based on IEC 62304 Software Safety Classification. MD software can be assigned to 3 classes: A, B, or C:

Software Safety Classes (Source: IEC 62304:2006-05+AMD1:2015-06 CSV)
Fig. 4 Software Safety Classes (Source: IEC 62304:2006-05+AMD1:2015-06 CSV)

This scope of required documentation for each class is divided into individual chapters and subchapters of the standard. The higher the class assigned, the more chapters to include for the submission:

Summary of requirements by Software Safety Class (based on IEC 62304:2006-05+AMD1:2015-06 CSV)
Tab. 4 Summary of requirements by Software Safety Class (based on IEC 62304:2006-05+AMD1:2015-06 CSV)

*Listed numbers are some of the subclauses from IEC 62304, which are:

5.1.4 Software development standards, methods and tools planning

5.1.5 Software integration and integration testing planning

5.1.10 Supporting items to be controlled

5.1.11 Software configuration item control before verification

5.1.12 Identification and avoidance of common software defects

5.2.3 Include risk control measures in software requirements

5.3.5 Identify segregation necessary for risk control

5.4.2 Develop detailed design for each software unit

5.4.3 Develop detailed design for interfaces,

5.4.4 Verify detailed design

5.5.2 Establish software unit verification

5.5.3 Software unit acceptance criteria

5.5.4 Additional software unit acceptance criteria

5.5.5 Software unit verification

5.8.3 Evaluate known residual anomalies

5.8.5 Document how released software was created

5.8.6 Ensure activities and tasks are complete

7.4.2 Analyze impact of software changes on existing risk control measures

7.4.3 Perform risk management activities based on analyses

US FDA guidance vs EU IEC 62304

So, how does the FDA Documentation Level reflect the IEC 62304 Software Safety Classification? What can be expected when facing two different classification systems coming from opposite hemispheres of the Earth? Fortunately, many insights can be made – see the table below.

This table provides all information in simplified terms to underscore the core parallels and distinctions between FDA documentation levels and Software Safety Classification according to IEC 62304. Please consult the referenced documents for precise guidance on FDA and MDR recommendations.

Documentation requirements by Software Safety Class vs FDA recommended documentation from Documentation Level
Tab. 5 Documentation requirements by Software Safety Class vs FDA recommended documentation from Documentation Level

Based on that matrix, one might be tempted to agree that the Enhanced documentation level is the closest to Class C. Basic documentation, on the other hand, may resemble Class A or B, depending on the area. For example, like in Class A, SDS may be omitted for the Basic level, and the areas of Development, Configuration Management, or Maintenance can be prepared almost like for SSC Class B.

However, stopping at just a comparison of both classifications seems quite short-sighted. It is equally, if not more important, to compare the background and scope of this documentation, especially from the safety issues point of view. Looking at the comparison from a broader perspective, the following observations can emerge:

Similarities:

  • Both classifications focus on the level of risk associated with MD software
  • Both classifications are used to determine the criticality of the software from a patient safety perspective.

Differences:

  • IEC 62304 classes are more specific in determining which functions are critical to patient safety. The FDA guidance does not provide as much detail on the risks associated with particular functions.
  • In IEC 62304, it is possible to reduce the safety class using risk control measures, the application of which reduces the severity and probability of risk occurrence. The FDA also expects to implement measures to mitigate risks. However, the FDA documentation level is established before these measures are taken. Even if the risk level decreases, the required documentation remains the same.

Summary

It is impossible to assign a specific SSC class precisely to an FDA documentation level. However, some areas are similar or even overlap – as evidenced by the FDA’s direct reference to the Declaration of Conformity with the chosen requirements of IEC 62304. A careful analysis of the documents may reveal small differences between some processes.

If you are planning to apply for pre-market submission for your medical device in both the EU and US markets, you can save time and costs by utilizing the documentation that has already been prepared for one of the markets. Sii offers assistance in preparing documentation for both submissions. So, if you need any help, feel free to contact us.

***

If you are interested in the area of standards, among other things, in the Healthcare industry, be sure to also take a look at other articles by our experts.

5/5 ( votes: 3)
Rating:
5/5 ( votes: 3)
Author
Avatar
Weronika Ostrycharz

In the Medical Device Industry for over 3 years. She deals with Medical Device design, design control and compliance with relevant standards mostly in the fields of Software Validation documentation, risk analysis or Quality Management System. A lover of instrumental and film music, mountain hiking and other outdoor sports

Leave a comment

Your email address will not be published. Required fields are marked *

You might also like

More articles

Don't miss out

Subscribe to our blog and receive information about the latest posts.

Get an offer

If you have any questions or would like to learn more about our offer, feel free to contact us.

Send your request Send your request

Natalia Competency Center Director

Get an offer

Join Sii

Find the job that's right for you. Check out open positions and apply.

Apply Apply

Paweł Process Owner

Join Sii

SUBMIT

Ta treść jest dostępna tylko w jednej wersji językowej.
Nastąpi przekierowanie do strony głównej.

Czy chcesz opuścić tę stronę?