Digital transformation of notified bodies
The digital transformation of notified bodies will transform the medical device ecosystem over the next few years. This article describes
The “old” Medical Device Directive (93/42/EEC) specified the requirements for medical devices, including the so-called essential requirements. Manufacturers are legally obliged to demonstrate compliance with these requirements, through the completion of the technical documentation (also called the TD or technical file).
The Medical Device Directive (in contrast to the MDR) is somewhat ambiguous with regard to the requirements for these documents. However, it mentions that they must include the following:
All above mentioned documents must be submitted by the manufacturer during the conformity assessment procedure via the technical documentation.
The Medical Device Regulation (MDR) does not only define the requirements for the medical device (Annex I), but it also defines the requirements for the documentation itself (Annex II). This must include (see Fig. 1):
Fig. 1: The MDR specifies the requirements for the technical documentation in Annex II (click to enlarge)
Some may ask what the MDR understands by “key functional elements.”
Here, the legislator expects a rough system architecture (especially for active devices) and, thus, a description of the most essential components and their functionality. If relevant (e.g., because in contact with the human body), the compositions (“formulations”) of the devices and components should also be recognizable.
This corresponds to the perfect input for an FMEA at the first or maximum second component level. With this description, you know the components of the device (including their functionality, composition, and interaction) and can thus analyze the risks that arise if the components do not behave as specified, e.g., do not have the specified functionality.
In addition to the FMEA, the description of the “key functional elements” also provides a rough understanding of the device. This is not about trade secrets but about the fact that the TD reviewer does not have the device on the table and cannot unscrew it to understand it. This is precisely why this description is needed.
The MDR goes one step further: It includes post-market surveillance, with planning and implementation, under technical documentation. It establishes the corresponding requirements in Annex III.
The 2016 version of ISO 13485 introduced the medical device file. This file must provide similar information:
The notified bodies have also published recommendations, such as NB-MED/2.5.1. Keep in mind that these publications have no legal standing. However, their contents are regularly requested during audits and reviews of the technical documentation.
The FDA also requires detailed device documentation, comprising three distinct files:
The Canadian authorities have published a unique iteration of the structure of the technical documentation based on the STED format.
The above regulations provide a brief outline of the requirements for technical documentation, yet do not describe:
Standards such as ISO 14971, IEC 62304, IEC 60601-1 and IEC 62366-1, offer some more detailed specifications. ISO 62366-1 specifies that the documentation must include the planning of a formative evaluation. You won’t find such granular requirements in the MDD, MDR, or ISO 13485.
The following mind map provides a summary and overview of the documents that medical device manufacturers must prepare for a conformity assessment to demonstrate that their medical device meets the general requirements according to Annex I of the Medical Device Regulation.
Fig. 2: Mindmap with contents of technical documentation. You can download a translated version free of charge as part of the starter kit.
Regulatory requirements do not specify how manufacturers should structure technical documentation. One exception is the FDA, which for example provides the chapter structure including chapter numbering for premarket notifications or 510(k).
Some “associations” have drawn up proposals for the structure of technical documentation to try to achieve the following objectives:
One of the best known proposals for structuring technical documentation comes from the IMDRF (formerly the GHTF). A lot of authorities and notified bodies use the STED (Summary Technical Documentation) as a guide.
The Association of Southeast Asian Nations (ASEAN) has also published a proposal for the structure of the technical documentation, known as the Common Submission Dossier Template (CSDT).
This ASEAN CSDT is called “Guidance on Preparation of a Product Registration Submission for General Medical Devices using the ASEAN Common Submission Dossier Template”.
Fig. 3: Structure of technical documentation according to the ASEAN CSDT (click to enlarge)
The proposal of the NB team, set out in document NB-MED 2.5/1, is also relevant in practice.
Fig. 4: Structure of technical documentation proposed by the NB team.
The structure shown in Fig. 2 is particularly well suited to manufacturers of active medical devices: It is compact, easy to understand and ideal for meeting regulatory requirements.
Many, but not all, international authorities accept standardized formats, such as STED. Nevertheless, there are some country-specific differences.
To ensure that manufacturers do not lose track of these differences, we recommend using a “mapping table,” which contains all the required documents or aspects to be addressed in the respective legal system.
Fig.5 : Table comparing the documents and requirements of different legal systems
The columns, which represent the structures named above, describe where specific information can be found in each file.
Maintaining a mapping table and compiling the specific approval documents for each market is usually the responsibility of the regulatory affairs department.
Would you like support in creating or checking your technical documentation? Professor Johner and his team will be happy to help!
Manufacturers must always prepare the technical documentation for their medical device and submit it to the notified bodies (except for class I devices). There it is checked for the first time.
The technical documentation is also subject to ISO 13485 audits. Based on this documentation, the auditor will assess
Finally, the quality system must define the processes (e.g., development and risk management) used to develop and produce the medical device.
The technical documentation is not something that manufacturers compile retrospectively for the notified bodies. Instead, the technical file is a set of documents written “automatically” during the development process.
In brief, without consistent, standard-compliant, and complete technical documentation, medical device manufacturers cannot prove that their medical device meets the general requirements for approval or that their quality management system is effective. For most manufacturers, designing a functioning quality system is a prerequisite for the conformity assessment.
The Johner Institute specializes in supporting medical device manufacturers in creating technical documentation.
Do you have any questions? Do you need support? We are happy to help quickly and cost-effectively.
The digital transformation of notified bodies will transform the medical device ecosystem over the next few years. This article describes
The MDR and IVDR use the terms device category and generic device group without fully defining them. ISO 13485:2016 introduces the medical device family. Finally, the MDCG uses the term device range. The definitions of these terms determine the allocation of UDIs and the sampling of product files during certification. Therefore, it is important for…
DetailsMedical device manufacturers are obliged to observe and comply with legal retention periods for documents and records. This article provides an overview of the regulatory requirements for the retention periods for the various document classes.
DetailsThis article describes the requirements of the in vitro diagnostic medical device regulation (IVDR) for software development and documentation. The requirements apply to software that is part of an IVD (embedded software) and to software that is an IVD itself (“standalone” software). This article also compares the software requirements of the MDR and the IVDR.
Details