Featured
Rimsys Announces Rimsys AI to Eliminate Repetitive Tasks and Enhance Decision-Making for MedTech Regulatory Teams
Rimsys, the leading Regulatory Information Management (RIM) platform for the MedTech industry, today announced the launch of Rimsys AI, a suite of embedded artificial intelligence (AI) agents.
The ultimate guide to the medical device single audit program (MDSAP)
This article is an excerpt from The ultimate guide to the medical device single audit program (MDSAP) ebook.
Table of contents
- What is MDSAP?
- History of MDSAP
- Who is responsible for the MDSAP?
- How does an MDSAP audit work?
- Audit sequence
- You got a nonconformity – now what?
- What does an MDSAP audit cost?
- Why choose the MDSAP certification process?
- Potential disadvantages of the MDSAP
- Ready to participate? – Here’s how to get started
- Completing a successful MDSAP audit
The Medical Device Single Audit Program (MDSAP) was designed and developed to allow a single audit of a medical device manufacturer to be applied to all country markets whose regulatory authorities are members of the program. The MDSAP provides efficient and thorough coverage of the standard requirements for medical device manufacturer quality management systems, and requirements for regulatory purposes (ISO 13485:2016). In addition, there are specific requirements of each medical device regulatory authority participating in the MDSAP that must be met:
- Conformity Assessment Procedures of the Australian Therapeutic Goods (Medical Devices) Regulations (TG(MD)R Sch3)
- Brazilian Good Manufacturing Practices (RDC ANVISA 16)
- Medical Device Regulations of Health Canada (ISO 13485:2003)
- Japan Ordinance on Standards for Manufacturing Control and Quality Control of Medical Devices and In Vitro Diagnostic Reagents (MHLW Ministerial Ordinance No 169)
- Quality System Regulation (21 CFR Part 820), and specific requirements of medical device regulatory authorities participating in the MDSAP program.
This means that a report from a single MDSAP audit of a medical device manufacturer would be accepted as a substitute for routine inspections by all the member Regulatory Authorities (RAs) across the world. There are currently five participating Regulatory Authorities (RA) representing the following countries: Australia, Brazil, Canada, Japan and the USA.
In April, 2021, the RAs released an “Audit Approach” document (MDSAP AU P0002.006) that combines the formerly separate MDSAP Audit Model and Process Companion documents into a single guidance document. It includes guidance for assessing the conformity of each process and includes an audit sequence, instructions for auditing each specific process, and identifies links that highlight the interactions between the processes.
In March 2012 the US FDA announced that they had approved a final pilot guidance document “Guidance for Industry, Third Parties and Food and Drug Administration Staff: Medical Device ISO 13485:2003 Voluntary Audit Report Submission Pilot Program.” This allowed the owner or operator of a medical device manufacturing facility to be removed from FDA’s routine inspection work plan for 1 year upon completing a ISO 13485:2003 audit. This guidance document went into effect in June 2012, and was intended as an interim measure while a single audit program was being developed.
This pilot program was not very successful and few companies signed up because they did not see any advantage in participating. The manufacturer had to pay for a third party to inspect their facilities, generate a report, and share the inspection results back to the FDA. Many companies were reluctant to contract “someone else” to perform their inspection when they could easily wait for the FDA to conduct an inspection for free.
During its inaugural meeting in Singapore in 2012, the International Medical Device Regulators Forum (IMDRF) appointed a working group to develop a set of documents for a harmonized third-party auditor system. Hence, the “Medical Device Single Audit Program” (MDSAP) was formed. The concept was similar to the FDA’s original idea of creating a third-party auditor to help reduce their workload of performing regulatory audits of medical device manufacturers’ quality management systems. This new approach would consist of a single audit that would review regulatory QMS compliance, conducted by a third-party, who would later be called an Auditing Organization (AO).
From January 2014 to December 2016, five countries participated in a Medical Device Single Audit Program Pilot. In June 2017, a report was generated summarizing the outcomes of prospective “proof- of-concept” criteria established to confirm the success of the program. The outcomes are documented in the final MDSAP Pilot Report and recommended that the program become fully active and open to any manufacturer who requested this type of audit.
The governing body of the MDSAP is the Regulatory Authority Council (RAC), which is composed of two senior managers (and a few other staff members) from each participating RA. They are responsible for executive planning, strategic priorities, setting policy, and making decisions on behalf of the MDSAP International Consortium. The RAC also reviews and approves documents, procedures, work instructions, and more. The mission of the MDSAP International Consortium is to jointly leverage regulatory resources to manage an efficient, effective, and sustainable single audit program focused on the oversight of medical device manufacturers on a global scale.
Other international partners that are involved in the MDSAP include:
MDSAP Observers:
- European Union (EU)
- United Kingdom’s Medicines and Healthcare products Regulatory Agency (MHRA)
- The World Health Organization (WHO) Prequalification of In Vitro Diagnostics (IVDs) Program
MDSAP Affiliate Members:
- Argentina’s National Administration of Drugs, Foods and Medical Devices (ANMAT)
- Republic of Korea’s Ministry of Food and Drug Safety
- Singapore’s Health Sciences Authority (HSA)
The observers and affiliate members are not the same as the participating member RA’s. The observers simply observe and/or contribute to RAC activities. Affiliate members, on the other hand, are interested in engaging in the MDSAP program and are subject to certain rules. They are only given access to a certain level of information about the manufacturers, audit dates, and information in audit reports.
They are also invited to attend sessions that are open to members, observers, and affiliates only.
Audits can also be conducted by MDSAP participating RAs at any time and for various reasons including:
- "For Cause" due to information obtained by the regulatory authority
- as a follow up to findings from a previous audit
- to confirm the effective implementation of the MDSAP requirements
The purpose of audits conducted by the RAs is to ensure appropriate oversight of the AOs MDSAP auditing activities. The AOs are appointed by the RAs and a list of the currently approved AO’s is published on the FDA website. Most AOs offer a broad range of management system certification services, beyond just medical devices. Manufacturers should verify that prospective AOs are clearly trained and perform MDSAP audits of medical devices.
AOs have the final word as to whether a manufacturer has met the requirements for the MDSAP during the execution of the audit and generation of the associated reports summarizing the results. MSDAP RAC participating RAs have the final decision regarding all development, implementation, maintenance, and expansion activities associated with the program.
Although an unannounced visit by an AO is rare, it can happen in circumstances where high-grade nonconformities have been detected.
To continue reading this eBook including a detailed look at the MDSAP audit process and grading, pros and cons of the approach, and how to get started please register to download the full version.
The beginner's guide to the FDA 510(k)
This article is an excerpt from The beginner's guide to the 510(k) ebook.
Table of Contents
- Introduction
- 510(k) basics
- Contents of a Traditional 510(k)
- 510(k) submission and timelines
- Other 510(k) forms
Congratulations! You have successfully developed a new medical device. Now you need to take it to market. In the United States, this often means submitting a 510(k). A 510(k) is a structured package of information about your device and its performance and safety that you submit to the Food and Drug Administration (FDA) for “clearance” before you can sell your device in the U.S. In order to receive clearance from the FDA, your 510(k) will need to demonstrate that your medical device is substantially equivalent to another legally marketed device (called a predicate device). The substantial equivalence approval process is a simple equation that looks something like this:
The 510(k) is generally the most efficient route to market clearance in the U.S. because you show your device is safe and effective based on this substantial equivalence standard, instead of needing to present more extensive clinical trial data.
There are three types of 510(k): Traditional, Abbreviated, and Special. This eBook will begin with a general overview of the 510(k) process, including its purpose and benefits. Next, we will explore the Traditional 510(k) and the sections and components required in depth. Finally, we will look at the Special and Abbreviated 510(k).
FDA: background and device oversight
Before we explain what a 510(k) is let’s first talk generally about the FDA and device oversight. The FDA is the U.S. governmental agency responsible for overseeing medical devices, drugs, food, and tobacco products. When it comes to medical devices, the FDA’s mission is to “protect the public health by ensuring the safety, efficacy, and security of…medical devices.” At the same time, the FDA also has an interest in “advancing public health by helping to speed innovations.” In other words, the FDA’s goal is to make sure devices are safe and effective for public use, while also ensuring that devices have a quick and efficient path to market.
In order to achieve this balance of safety and efficiency, the FDA has three different levels of oversight depending on the risk level of the device: (1) exempt from premarket submission, (2) Premarket Notification, also known as 510(k), and (3) Premarket Approval (PMA).
When is a 510(k) required?
A 510(k) is required for medium risk devices that have a predicate on the market which can be used to demonstrate the safety and effectiveness of the new device. Meanwhile, a PMA is required for high-risk or novel devices which require a higher level of scrutiny to be confirmed safe and effective.
A 510(k) is not only required for new devices, but also for devices that have been modified in a way that could impact safety or effectiveness. This could include changes to the:
- Design
- Components
- Materials
- Chemical composition
- Energy source
- Manufacturing process
- Intended use
You must submit your 510(k) at least 90 days before marketing the device.
What Exactly is Substantial Equivalence?
Now that we know what a 510(k) is, let’s talk about the substantial equivalence standard. You’ll recall from the introduction that your 510(k) must show that the new (or modified) device is substantially equivalent to at least one other legally marketed device, called a predicate device. Substantial equivalence looks at the intended use and the technological characteristics of the two devices.
More specifically, you must show:
- that the new device has the same intended use as the predicate, and
- the differences between the two devices do not raise questions about the safety and effectiveness of the new device.
Now let’s take a closer look at intended use and technological characteristics.
Intended use
Intended use means the general purpose or function of the device. The FDA will look at your proposed labelling and your Indications of Use section of the 510(k) to determine the intended use of your device (this is covered in Chapter 2). Intended use includes:
Technological characteristics
Once the FDA has determined that a predicate device exists and that the new device and the predicate device have the same intended use, it will move on to compare the technological characteristics. Technological characteristics include:
- Materials
- Design
- Energy source
- Other device features
The two devices do not have to be identical, and in fact they almost never are. The key here is to demonstrate that any differences do not have a significant impact on safety or effectiveness. Here’s what to cover when you compare your device’s technological characteristics with that of the predicate device:
Overall description of the device design
- Engineering drawings or diagrams to explain the device and component parts.
- List of component parts and explanation of how each component contributes to the overall use and function of the device.
- Physical specifications: dimensions, weight, temperature, tolerances, etc.
Materials
- Detailed chemical formulation used in all materials of constructions (especially those that come into contact with a patient).
- Any additives, coatings, paint, or surface modifications.
- How materials have been processed and what state they’re in.
Energy Sources
- Use of batteries, electricity, etc.
Other technological features
- Software/hardware
- Features
- Density
- Porosity
- Degradation characteristics
- Nature of reagents
- Principle of the assay method
In deciding whether the differences in technological characteristics impact safety or effectiveness, the FDA will typically rely on descriptive information about the technological characteristics as well as non-clinical and clinical performance data.
Let’s look at an example: A manufacturer submits a 510(k) for a new type of contact lens. Both the new device and the predicate device are indicated for daily wear for the treatment of astigmatism. The predicate device is only available in a clear lens, but the new device comes in a line of colors, including purple tinted lenses.
Who is responsible for submitting a 510(k)?
The following four types of organizations may be responsible for submitting a 510(k):
Manufacturers
- End-of-line device manufacturers who will be placing a device on the U.S. market.
- Note: Does not apply to component part manufacturers unless components will be marketed independently.
Specification developers
- Companies that develop the specifications for a finished device which has been manufactured elsewhere
Repackers or relabelers
- Required to submit a 510(k) if they significantly alter the labeling or condition of the device, including modification of manuals, changing the intended use, deleting or adding warnings, contraindications, sterilization status.
- Note: This is rare. The manufacturer, not the repackager or labeler, is typically responsible for the 510(k) submission.
Importers
- Importers that introduce a new device to the U.S. market may need to submit a 510(k), if it hasn’t already been submitted by the manufacturer.
Now that we’ve covered the basics, let’s explore what actually goes into your 510(k).
A Traditional 510(k) should contain all the following components in the list below. In some cases, a particular section may not apply to your device. When that happens, it’s a good idea to include the section anyway and just state “This section does not apply” or “N/A” under that heading.
To continue reading this eBook including a detailed walk-through of all the Traditional 510(k) components, submission requirements and timelines, and an overview of the other 510(k) forms including the Abbreviated 510(k) and the Special 510(k), please register to download the full version
The ultimate guide to the China UDI system and database
This article is an excerpt from The ultimate guide to the China NMPA UDI system and database ebook.
Table of Contents
- Overview
- UDI basics and benefits
- UDI format requirements and issuing entities
- UDI database and submission requirements
- Implementation of UDI and the UDI database in China
The current Chinese medical device regulatory regime kicked-off in 2014 with the Regulation on Supervision and Administration of Medical Devices. This core set of registration requirements, modeled after the United States and European Union systems, established a set of device classifications (class I, II, and III) based on risk and procedures for obtaining market clearance for each type of device.
Medical devices in China are regulated by the National Medical Products Administration (NMPA). Class I devices, such as clinical laboratory equipment or non-invasive skin dressings, require only notification to the NMPA for marketing authorization, and that authorization does not expire. Class II and III devices such as implantable devices or devices with a measuring function require full registration and a formal review before market clearance can be obtained.
These initial regulations have been expanded since their introduction, adding accelerated pathways to market for certain products in certain regions, easing acceptance of clinical data from overseas, and more specific roles and responsibilities for local agents of international manufacturers. In addition, in 2019, the regulations added a provision that medical devices carry a unique device identification (UDI). China’s UDI requirements are similar to those in the US and European Union. They establish specific device ID and labeling requirements, as well as a central, state-administered database of devices.
This eBook walks through the basics of medical device UDIs, the specifics of China’s implementation, and how MedTech companies who market their devices in China can prepare for the full rollout of these regulations in the coming years.
A UDI is a unique alphanumeric code that is designed to identify medical devices sold in a particular country/region from manufacturing, through distribution, to use by a patient. Like other aspects of the medical device regulatory regime, the UDI system in China follows the approach taken by the United States FDA and European Commission, and is based on the guidance from the International Medical Device Regulators Forum (IMDRF). Generally, UDI systems are designed to improve patient safety and optimize care by:
- Increasing the traceability of medical devices, including field safety corrective actions
- Providing an unambiguous identification method for medical devices throughout distribution and use
- Making adverse event reports more accessible
- Reducing medical errors by providing detailed information related to the device
- Simplifying medical device documentation and making it more consistent
There are three components to the UDI system in China:
- UDI code: The actual UDI code can be assigned by one of three (3) issuing agencies and contains information about the product, it’s expiration date, and the manufacturing batch/lot it’s associated with.
- UDI labeling: Put simply, medical devices must carry the UDI code on them. The regulations stipulate how devices and their packaging must be labeled for compliance.
- UDI database: In addition to labeling, all device UDIs must be submitted to a central database that is administered by the NMPA.
The following sections explore each of these components in more detail.
The UDI code
The first element of the UDI system is the code itself. The UDI code is the alphanumeric identifier that is associated with a specific medical device. UDI codes have two (2) elements to them, the UDI device identifier (UDI-DI) or static portion, and the UDI production identifier (UDI-PI) or dynamic portion. You can see the two components in the UDI diagram below:
The UDI-DI contains information about the issuing entity—the organization that is authorized to assign UDI codes. In China, this can be one of three entities: GS1, an international barcode and electronic data interchange standards organization, and two domestic organizations: the Zhongguancun Industry & Information Research Institute (ZIIOT), and AliHealth. Additional details about the issuing agencies are covered in Chapter 2. In addition, the UDI-DI contains information about the manufacturer and the specific model or version of the device.
The UDI-PI contains information about the manufacturing and production of the device. This typically includes information about the lot or batch number in which the device was manufactured, the manufacturing date and expiration date for the device (if applicable), and the specific serial number for the device. Here you can see all of the components marked up using the same UDI example:
Note that each packaging permutation and level for a given device will need to be assigned its own UDI. So for example, let’s say that a company manufactures 5ml enteral (oral) syringes in two packaging options: 1 – packaged individually and 2 – packaged in a box of 5. Each packaging option would need its own UDI, despite the fact that the underlying product is the same.
Now looking at packaging levels, let’s assume that the manufacturer packages the single syringe offering into boxes of 6, and again into larger containers of 24. Each of those packaging options needs its own UDI as well.
Labeling
In addition to obtaining UDI code for each device as outlined in the previous section, medical device manufacturers are required to ensure that devices are appropriately labeled with the assigned UDI. This label is called the UDI Carrier. The UDI is represented in two forms on the UDI Carrier: a machine-readable form and a human-readable form.
The machine-readable form or automatic identification data capture (AIDC) is a barcode or some other technology that can be used to automatically capture UDI information. The NMPA regulations support 3 types of machine-readable formats: 1-dimensional barcode, 2-dimensional barcode, and radio-frequency identification (RFID).
The regulations note that “use of advanced automatic identification and data collection technologies is encouraged”—prompting manufacturers to use more modern 2D and RFID machine-readable carriers where possible. Note, however, that if a device uses RFID, the UDI Carrier must also include the UDI in barcode format.
The human-readable form or human-readable interpretation (HRI) is the numeric or alphanumeric code for the UDI that can be read and manually entered into systems.
The UDI Carrier should be included on the device and on all levels of packaging. The UDI Carrier must be clear and readable during the operation and use of devices. If there isn’t room on the device for both the human and machine-readable forms of the UDI, then manufacturers should prioritize the machine-readable form.
UDI database
The third component of the NMPA UDI system is the UDI database. This is a centralized database of UDI and product information, administered by the NMPA. Manufacturers are required to submit UDI information into the database within 60 days after a product is approved (for sale in China) and before it is commercialized. The database contains a more detailed product record than what is included in the UDI itself, and it is the responsibility of the manufacturer (and/or their in-country representative) to submit the information correctly, and ensure that it’s kept up to date.
Chapter 3 of this eBook goes into detail about the specific fields and data requirements for UDI database submissions.
To continue reading this eBook including information about UDI format requirements and issuing entities, implementation timelines, and affected device types, please register to download the full version.
Class III medical devices in the United States
What is a Class III medical device?
There are three classes of medical devices in the United States, all regulated by the Food and Drug Administration (FDA). Class III devices have the highest risk profile and therefore have the most significant regulatory requirements. In the United States, a Class III device is also a device that has no substantial equivalence to an existing Class I or II device. This means that if there is no device with similar intended use and indications for use, or if the device is using novel technology, it will be classified as Class III by default. To find substantially equivalent devices, use the FDA’s product classification database. Because medical device classification in the U.S. also depends on risk level, there are exceptions for novel devices with lower risk profiles (see De Novo classification process).
Examples of Class III medical devices
Class III devices “usually sustain or support life, are implanted, or present potential unreasonable risk of illness or injury.” Only 10% of medical devices marketed in the U.S. fall under this category.
Examples of Class III devices include:
- Pacemakers
- Implanted prosthetics
- Cochlear implants
- Defibrillators
- Software defined as a medical device (Software as a Medical Device or SaMD), which meets the risk profile of a Class III device. This may include diagnostic software that is using imaging to identify conditions that, if misdiagnosed, would pose a risk to the patients health or life.
FDA regulatory approval process for Class III medical devices
Almost all Class III medical devices in the United States require premarket approval (PMA) from the FDA before being marketed. Due to the high risk profile of Class III devices, the PMA process requires significant data to demonstrate the safety and efficacy of the device. Unlike Class II devices which require a 510(k) premarket notification, the PMA process requires a thorough review by the FDA that results in their approval of the product for entry into the U.S. market.
The PMA process is defined in Title 21 Code of Federal Regulations (CFR) Part 814 and a full overview of the process is included in our Beginner’s Guide to the FDA PMA Submission Process. A PMA will almost always require:
- Substantial clinical trial data.
- A fully documented quality system compliant with design controls as defined in 21CFR Part 820.
- Documented conformance to recognized consensus standards.
- Detailed descriptions of the device and all of its components.
- Product samples and/or the ability for the FDA to examine the device on-site.
Note that there are exceptions to PMA requirements, most notably the humanitarian device exemption, designed to encourage investment in devices that would serve a small population. See the FDA’s Acceptance and Filing Reviews for Premarket Approval Applications (PMAs) for more information.
Post-market compliance for Class III medical devices
Medical device manufacturers and distributors must also conform with specific requirements once a product is being sold in the market. These requirements include:
- Mandatory reporting of device issues and adverse events by manufacturers, importers, and device user facilities (such as a hospital) as detailed in the Medical Device Reporting regulation (21 CFR Part 803).
- Tracking systems to support any necessary product recalls as detailed in 21 CFR Part 821.
- Post-approval studies that are required with the approval of a PMA, Humanitarian Device Exemption (HDE), or Product Development Protocol (PDP). Post-approval studies are a condition of approval and are mandatory.
Class III medical devices in other countries
Device classification is different in each country, therefore you should not make any assumptions regarding classification in other countries based on the fact that your device is a Class III device in the United States. Each country with medical device regulations has their own classification scheme that may cause your device to be regulated in a different way. During the initial phase of planning for global commercialization of a product, it is imperative that you consider international regulations, their classification schemes, and the registrations that each country will require.
For additional information on the Class III approval process, read our Beginner’s Guide to the FDA PMA Submission Process.
BUDI-DI - Basic UDI explained
What is BUDI?
By now, you should be familiar with the terminology surrounding UDI - The Unique Device Identification System. The United States FDA, the European Commission, and other regulatory bodies around the world have developed UDI regulations for medical devices and in vitro diagnostic devices that involve both labeling and database registration requirements. In the EU, UDI regulations were introduced under Regulations (EU) MDR 2017/745 and (EU) IVDR 2017/746. There is UDI, UDI-DI, UDI-PI - so then what is a BUDI-DI?
BUDI is an abbreviation for “Basic UDI” and is commonly pronounced “Buddy.” A BUDI-DI is unique to the EU and allows devices with multiple UDI-DI’s to be grouped together. It is necessary whether you have one device group (sometimes referred to as device ‘family’) or have many different device configurations such as systems, procedure packs, or kits. The general rule is there can only be one BUDI-DI to many UDI-DI’s and never multiple BUDI-DI’s to just one UDI-DI. The only time a BUDI-DI is not required is for a custom-made device, which generally doesn’t fall into the UDI requirements of the MDR/IVDR anyway.
A BUDI-DI allows manufacturers to connect and identify device groups with the same intended purpose, risk class, essential design, and manufacturing characteristics. It is an identification number that is only used for administrative purposes. It is required in the EUDAMED database and is referenced in relevant documents such as certificates, declarations of conformity, and technical documentation. If the device requires Notified Body review, then the BUDI-DI should also be listed on the CE Certification and the Certificate of Free Sale.
A BUDI-DI is the key that unlocks the EUDAMED and provides access to all of the product information.
- It’s the primary identifier of the device group/family
- It’s the main record key in the EUDAMED
- It’s the main product identifier in the regulatory documentation
- It’s independent of packaging and labeling
UDI issuing agencies
The manufacturer is legally responsible for utilizing a human-readable BUDI-DI assigned by an approved UDI issuing agency, such as HIBCC or GS1. The format of the BUDI-DI will vary slightly depending upon which issuing agency you work with. Currently, the only approved issuing agencies in Europe are GS1, HIBBC, ICCBBA, and IFA.
Per the MDCG 2019-1 guideline, each agency must:
- Create a code format that is close to the existing UDI-DI format
- Use no more than 25 total characters
- Assign a check/digit character that was determined by an algorithm
A BUDI-DI cannot be changed. A product UDI-DI created because of a new product variation or changes to the UDI-DI data elements can report into an existing BUDI-DI.
The EU provides an EU UDI Helpdesk to assist with navigating UDI requirements and answering questions device manufacturers may have.
Note that EUDAMED registrations, including BUDI-DI numbers, are currently recommended but not required. Use of the EUDAMED databases will not become required until all six databases are live, which is expected to be in Q2 of 2023, with a 24-month transition period.
Read our Quick reference guide - global medical device UDI requirements and timelines for additional information on general UDI requirements.
RIM Readiness: What your medtech company needs before implementing a regulatory information management system
Regulatory Information Management (RIM) systems provide a single platform for regulatory teams to manage submission and compliance data, reducing administrative overhead and increasing confidence in a company’s global regulatory data. RIM systems can digitize and automate a broad set of regulatory activities from new product submissions, to registration and standards management, to UDI data management. These capabilities can significantly improve RA efficiency and effectiveness - reducing workload for new releases by over 80% and maintenance time for technical files more than 90%. However, not all organizations can realize results like these immediately. When deciding to implement a RIM system, medical device companies need to consider many factors and ensure that they have the needed systems, processes, and personnel in place.
Technology requirements
RIM systems are fundamentally about data. They first and foremost provide a system to collect (either directly within the system or through integrations) and centralize regulatory information, making it easily accessible across the organization. This means that in order for a RIM system to be useful, your data needs to be accessible to the system. Medtech companies without the following in place may not be ready for a RIM system:
- Digitized documentation: It is imperative that regulatory documentation, such as technical files and design history files, are in a digital format. If you still have older product documentation on paper in locked file cabinets - it’s time to get them digitized!
- Application infrastructure: RIM systems rely on data that is often stored in other applications, such as eQMS, PLM, or ERP systems. It is rare to implement a RIM system as the first application in a medtech company’s software stack. Medtech companies should have, at a minimum an eQMS system that is compliant with 21 CFR Part 820 and/or ISO 13485 and an ERP system in place before implementing RIM.
- No competing major IT initiatives: A RIM implementation is a major project that should be given dedicated resources and the attention of the management team. Consider the timing of a RIM implementation carefully if there are other majorIT projects, such as an ERP implementation or a major system upgrade.
Corporate priorities
It’s important to understand RIM projects as a true digital transformation. While it is primarily a technology implementation, the end result is a significant change in that way that regulatory affairs teams work. This change is very beneficial, but it’s still disruptive in the short term. Teams without the right leadership support and change management plans may struggle to realize value from their RIM investment.
- Digital transformation strategy: A RIM implementation is an integral part of a larger digital transformation strategy. Medtech companies that are most successful with RIM have a digital transformation initiative in place, and an understanding that they are driving organizational process change in addition to technology adoption.
- Recognized need: RIM implementations are significant projects that require resources and the attention of the management team. RIM projects are most successful when the management team recognizes that the status quo is not sustainable and places a priority on providing resources for the regulatory team.
Timing a RIM implementation
Medical device manufacturers who can benefit the most from a RIM system are those whose regulatory teams are, or will soon be, surpassing their ability to handle submission and product market data manually. For most medtech companies, the best time to start a RIM system implementation is about a year before they expect a significant increase in the demands on the regulatory team. While a RIM implementation rarely takes a year to complete, this will give you time to put in place the data and processes in time for them to be tested and accepted before the regulatory team is overwhelmed with other priorities. Consider:
- Expanding geographic reach: Expanding from one country or region into multiple markets creates significant complexity for regulatory teams. Manually maintained spreadsheets become insufficient for handling the ever-changing regulatory requirements in multiple countries.
- Growing product portfolio: Similarly to entering new markets, new products can exponentially increase the complexity of processes and data that regulatory teams need to manage.
- Greater product complexity or risk: Regulatory teams managing lower risk products, such as Class I products in the U.S., will not have as great of a need for a RIM system as those managing more complex products with greater regulatory requirements.
- Significant upcoming changes: Pending company acquisitions, changes to legal entities, major design updates, or other changes that would trigger re-registration activities mean significant increase in activity and risk for your regulatory team.
Teams and personnel
A RIM system empowers regulatory teams, allowing them to save time on administrative tasks and spend more time making sure their company’s products are entering markets efficiently and staying in market effectively. This means that a RIM system will be of use to a seasoned (almost always overworked) regulatory team. It is rare to implement a RIM system before an internal regulatory team is in place. If your company doesn’t have the following, then you likely won’t get full use or value out of a RIM implementation:
- Dedicated regulatory personnel: One or more regulatory professionals responsible for obtaining and maintaining market clearance for your products, and interacting with government health authorities.
- Committed management team: A management and executive team that recognizes the importance of a strong regulatory system, and is willing to commit the resources necessary to make it successful.
Think your team is ready for RIM? Not sure? Download our RIM readiness checklist or talk to us today!
ISO 14971: risk management for medical device manufacturers
What is ISO 14971?
ISO 14971 is the globally accepted international risk management standard for medical devices. This article discusses the most current version of this standard, ISO 14971:2019, currently considered the state-of-the-art standard.
ISO 14971:2019, provides the processes for identifying, evaluating, and mitigating hazards associated with the use of medical devices. While not mandatory, it is the most commonly used, industry-recognized standard to demonstrate conformity to when addressing product safety requirements. This article provides an overview of the standard, but should not be used as a substitute for the actual text of the standard.
As in the case of a quality management system, a risk management system addresses the full lifecycle of a medical device; including the design, manufacture, and use of the device. Also, while ISO 14971:2019 does not, itself, require the implementation of a quality management system, risk management is most often an important part of a strong quality management system.
Compliance with ISO 14971:2019 requires that a risk management system be established and maintained throughout the product lifecycle, and that all processes and results are stored in a risk management file. The risk management system will include processes for risk analysis, evaluation, and control. It is important to note that the standard does not define acceptable levels of risk for medical devices - this is left to the manufacturer to determine as part of their risk management processes. However, the guidance document, ISO TR 24971:2020, provides significant clarity and direction in interpreting the standard and developing a risk management system consistent with ISO 14971:2019.
EN ISO 14971:2019: EU harmonized standard
In the European Union, as of May 11, 2022, the specific version of the standard which has been officially recognized as a harmonized standard with current Medical Devices Regulation (MDR) ((EU) 2017/745 ) and In vitro Diagnostic Medical Devices Regulation (IVDR) ((EU) 2017/746), is EN ISO 14971:2019 and the amendment EN ISO 14971:2019+A11:2021. The amended version includes two Annexes, Annex ZA and ZB, which demonstrate the relationship between the standard and the risk management process required in the MDR and IVDR. The technical content of the two versions are identical and does not included any content deviations, unlike EN ISO 14971:2012, the version of the standard which is harmonized with the previous EU MDD and IVDD regulations.
Risk analysis
Under ISO 14971:2019 a manufacturer is required to document risk analysis activities and the results of those activities in a risk management file. These should include:
- Intended use and “reasonably foreseeable” misuse, along with all device characteristics which impact the safety of the device.
- Hazards (a potential source of harm*), both known and foreseeable.
- Estimation of risk for each hazard, based on the probability of occurrence of the hazard and possible consequences.
*Note: ISO 14971:2019 revises the definition of harm by excluding the word “physical” injury from the ISO 14971:2007 definition. The resulting ISO 14971:2019 definition of harm is “Injury or damage to the health of people, or damage to property or the environment”
Risk evaluation
Risk evaluation involves the determination of whether a risk reduction is required for a particular hazard. Manufacturers should weigh the combination of the probability that a hazard occurs with the severity level of the hazard. A risk evaluation matrix, such as the following example, is often used to to visualize risk acceptability.
It is important to note that ISO 14971:2019 and TR 24971:2020 added significant emphasis and clarity regarding the evaluation of risk and establishment of risk acceptability criteria. Under the previous versions of the standard (both ISO 14971:2007 and EN ISO 14971:2012), there was confusion and a lack of guidance around defining acceptable risk. It was common to use a two-dimensional matrix showing severity of harm along one axis and probability of harm along the other, but with little guidance there were multiple interpretations of how to establish these criteria and these matrices were often used to define policy. The latest version of the standard and guidance, however, emphasize that the matrix should be the output of the risk management policy, which would define the criteria for risk evaluation.
Risk control
When a hazard is found to have an unacceptable risk level, risk control activities are put in place to mitigate the risk. ISO 14971:2019 requires that “state-of-the-art” best practices that are used for similar devices be employed. State-of-the-art does not necessarily mean the most advanced processes and technical features, but rather those that are generally accepted in the industry. Risk control options should include, in order of importance:
- Inherent safety by design and manufacture
- Protective measures built into the device or into the manufacturing process
- Provided safety information, and where appropriate, training to users
Risk/benefit analysis should be performed and where benefit is determined to outweigh risk, the manufacturer will need to decide what safety information is necessary to disclose.
Relevant standards should be applied as part of the risk control process whenever applicable. Some of the standards which reference ISO 14971:2019 include ISO 13485 (quality management systems), IEC 60601-1 (electrical safety), IEC/EN 62366 (usability of medical devices), and IEC 62304 (medical device software). This makes ISO 14971:2019 essential for manufacturers seeking market approval for a medical device in the U.S., European Union, Japan, Australia and many other major markets.
Production and post-production information
A substantial change in ISO 14971:2019 standard is the expansion of requirements for production and post-production activities. The manufacturer will need to perform a full review of the risk management process prior to commercial distribution. The review should ensure that the risk management plan has been appropriately implemented, the overall risk is acceptable, and that procedures are in place to gather and maintain risk data during production and post-production of the medical device. ISO 14971:2019 aligns closely with the ISO 13485:2016 section 8 requirements for feedback, analysis of data and CAPA. Information collected and reported should include any newly identified hazards, changes that affect risk analysis calculations, and results of regular reviews of the risk management file.
Management responsibilities
Medical device manufacturers who wish to demonstrate compliance with ISO 14971:2019 must have a management team that is dedicated to and supportive of the risk management system. This includes ensuring that adequate resources are assigned to support the system and that the personnel assigned are qualified for their respective responsibilities. In addition to enabling the implementation and maintenance of the risk management system, management is responsible for reviewing the system periodically to ensure continued effectiveness.
For more information about technical documentation/compliance for medical devices, check out our comprehensive ebook, The ultimate guide to EU MDR and IVDR general safety and performance requirements (GSPR).
Why we developed Rimsys from the ground up
Rimsys has had quite a year already! In early December, we closed on $16 million in Series A financing and since then we have been carefully growing the company to better serve our customers and the regulatory affairs community. We have almost doubled our employee count and redesigned the Rimsys system to deliver deeper functionality that is even easier to use. We had our first in-person employee meeting here in Pittsburgh at the end of April where we introduced our new mission statement, and we are all excited to be doing our part to improve global health!
All of these changes made us think back to the founding of Rimsys and how far we have come. So - I sat down with Rimsys Founder and CEO, James Gianoutsos, to talk about the genesis of the company and how he knew that a new type of system designed for medtech regulatory affairs professionals was needed, and needed to be built from the ground up.
Q: What was the biggest challenge you faced as a regulatory professional that led you to form Rimsys?
James: The biggest challenge I saw while working at Philips for many years was completely understanding the complexity and the nuances around everything regulatory from a product standpoint. This really came to light whenever we acquired products. Just seeing firsthand how inefficient and out of compliance these manufacturers really were, and how hard it was from an administrative standpoint just to get into compliance and then to stay compliant, was striking.
I was working with a smaller medical device company which had acquired products from Philips. Philips provided the company with a list (a color-coded Excel spreadsheet) of all of their products that the company had acquired along with the registration status of those products globally. After digging into the spreadsheet for several months, we found that about 50% of it was wrong, incomplete, or just completely missing. The company was trying to keep track of registration information, but the available tools were making it nearly impossible. I realized that this was the challenge, and that there really wasn’t a solution on the market that could solve that problem in an easy manner and in a medtech regulatory-focused way.
Q: There were solutions on the market that were geared more towards the pharmaceutical industry, correct?
James: Yes. So I did what every other regulatory professional did, which was to Google “regulatory software,” and I saw that there just really wasn’t anything on the market that fit our needs. The solutions on the market really were pharma-specific, even those that said they worked with medical devices. The workflows and regulatory requirements for medtech are very specific for each market, depending on the product type and risk class and so many other factors. To use a pharma system that was already on the market just wasn’t even an option because it was like comparing apples to oranges. It is completely different from the regulatory and workflow side of things.
Q: There are existing tools used by the regulatory community, such as quality management and document management systems. Did you envision the new RIM system integrating with existing tools, replacing them, or a little of both?
James: I never set out to replace those types of systems, no. In fact, I knew that existing system architecture and infrastructure couldn’t handle the specific medtech regulatory workflows but needed to connect to those systems. There have always been PLM (Product Lifecycle Management) systems that contain a company’s product master data, but those systems were never meant to be workflow-driven based on regulatory requirements. At the same time, they are critical for organizing and maintaining product-specific metadata. Then there are ERP systems, which are really about making sure companies have sales flags (i.e. regulatory blocks) in place, appropriate shipping codes, or selling status linked to product registration status. Regulatory professionals are concerned about answering two questions for ERP users; one, “does the product have a valid and current registration within the country or market,” and two, “if it is registered, are we selling and shipping into that market.” Lastly, quality/document management systems house critical documentation and records needed for registrations. The problem with these systems is that there are no regulatory workflows and no way to compile technical documentation, leaving the documents and records siloed from the regulatory filings.
To do the things that a regulatory affairs professional, in a critical regulatory department, does for their company, the system really had to be built from the ground up with all of these systems in mind. It had to be product-centric. It had to integrate with all these other sources of information, because there really wasn’t a common connection point between your products, your documentation, and the records that you needed to compile and how that relates to getting products on the market. We had no way to communicate to our other systems that a product is actually available for sale in that market or that it confidently can, or more importantly cannot, ship to that market.
Q: What was the most difficult piece of functionality to implement in Rimsys?
James: Well, at the time it kind of all seemed difficult! No, really the most difficult part was thinking thoughtfully and strategically about how data was going to be mapped and used in conjunction with other data elements, in order to make the system most helpful from a user perspective. We wanted to single-source information to enhance and streamline regulatory workflows, but then also make sure that it was as user friendly as possible. There are a lot of stakeholders that need information or have input into regulatory workflows. Quality assurance, marketing operations, R&D, engineering, sales - all of those specific stakeholders need to view information in a way that is understandable to them.
We worked hard to bring all that information, streamline complex regulatory workflows, and all of those internal and external data sources together in an understandable and user-friendly way.
Q: How important has the technology itself been in the creation of Rimsys?
James: Technology has been a huge advantage for us from day one. Our team had quality and regulatory backgrounds, so we knew what companies would expect from us. We knew we had to be 21 CFR Part 11 compliant. We knew we had to be ISO 27001 certified. We knew we had to have SOC2 Type 2 reports. We knew we had to integrate with a company’s existing IT infrastructure. We really had to build this thing from the ground up on a GxP compliant platform that we could build upon and expand, without having to go back and reinvent the wheel every time we added new functionality.
It’s continued to pay dividends for us because it was something that we thought about from the beginning and that gave us a lot of flexibility. We already had the system and infrastructure in place that we could then expand upon a lot more quickly than we would have been able to otherwise. It’s like the difference between building a house today and trying to remodel a house that was built in the year 1900. If you break down a wall in the older house, there might be so many hidden issues behind that wall - load bearing issues, knob and tube wiring, asbestos, etc. With new modern infrastructure, it is just night and day in terms of adapting quickly with changing regulations and a fast-paced market.
Q: Was there any specific technology you can talk about that became important to the development of Rimsys?
James: Our choice of technology was driven by our desire to build a system that was user friendly and built on a modern infrastructure that felt familiar to our users. So, we took a lot of the Google framework to build an application that didn’t look like enterprise software, but looked and felt more like a consumer product that is inviting, not overwhelming.
The other thing is that we built the system from day one to integrate because we knew we had to connect with a lot of different sources of information. We strategically built the system with API’s in mind.
Q: What is Rimsys doing differently than other software companies in the regulatory space?
James: We are creating a holistic solution, which is different from what is out there now. We know that registration management is just one key aspect of what regulatory affairs teams need. In order to create a proper regulatory system, we had to take into account all of the data and dependencies and build a system specifically for medtech regulatory teams and other key consumers of regulatory data. There has to be a single source of truth for this data, because otherwise it becomes a nightmare at the end of the day. Existing software solutions were siloed and purpose-built for other industry needs, such as eQMS, PLM and ERP. None of those systems can do what a holistic RIM platform can do. Because of the complex workflows, the regulatory needs are far too broad and interdependent, that data infrastructure is completely different, data sources are too numerous, and the systems offer limited support to bring everyone and everything together into a cohesive, streamlined, compliant and medtech-specific solution.
Another key component of what we are doing is to institutionalize regulatory knowledge and resources into Rimsys—this is at the heart of who we are and what we do. Having the only purpose-built, holistic RIM platform built by and for regulatory professionals specific for the medtech industry really couldn’t be done without internalizing that experience within our own team.
Q: What are you most proud of when it comes to Rimsys?
James: I think there are two things that immediately come to mind. Having our Rimsys 5 platform launch is really exciting. This is the fifth iteration of our platform, and we did it by listening to our customers and iterating over and over again to get it right. We had to go back to the drawing board a couple of times, not because what we had written wasn’t working, but because our customers that were using the system every day gave us better ways to do things. Rimsys 5 is a really proud moment because this is the platform that we are taking into the future, that will let us get to the next level where we are truly empowering regulatory professionals to make critical decisions and do the job that they are meant to do.
The ability for us to listen to our customers, take that feedback and move fast is the second thing I’d mention here. We know that this has to be a validated system, but we are able to make changes and add features in a way that is thoughtful and gets our customers what they need right away. Regulatory professionals are very particular. I know since I am one, and making sure they are comfortable using Rimsys from day 1 is critically important. Being a customer-centric company really makes our experience as a team extremely rewarding.
Q: Where is Rimsys going next? What are you most excited about?
I think I am most excited about Rimsys being an advocate for the medtech regulatory community and helping them wherever we can. Regulatory has a seat at the table now and it is a great feeling to see that we’re able to help these companies to streamline their workflows, accelerate time to delivery for life-saving products and maintain that compliance to keep those products on the market. Regulatory affairs is a mission critical department that the medtech industry cannot underestimate. It’s empowering because while we are helping our customers, they are helping us and every single one of our other customers through the journey of regulatory uncertainty that everyone is going through right now. It feels like a real partnership between us, our customers, and the industry as a whole and I am excited to see where that will take us.
I am also really excited about where we are going with regulatory intelligence. We are just scratching the surface of this now, but you will see regulatory intelligence data built into Rimsys and providing RA professionals with tools that can really provide a competitive advantage for their company. The release of Rimsys 5 platform (“Phase 1”) provides us that platform that will take us into “Phase 2” of Rimsys, with embedded intelligence that will further empower regulatory professionals to make decisive, correct and confident decisions for their products and their company.
The ultimate guide to the EU MDR and IVDR general safety and performance requirements (GSPR)
This article is an excerpt from The ultimate guide to the EU MDR and IVDR general safety and performance requirements (GSPR) ebook.
Table of contents
- Overview
- Terminology
- EU MDR/IVDR Annex I
- EU MDR/IVDR Annex II
- Proactive Monitoring & Maintenance
- Comparison Table: EU MDR/IVDR Annex I GSPRs vs EU MDD/IVDD Annex I Essential Principles
With the initial rollout of the European Medical Device Regulation (MDR) complete, medical device companies are shifting focus to the sister In Vitro Diagnostic Regulation (IVDR) which has rolling effective dates starting in May 2022. Like the MDR, the IVDR also includes new General Safety and Performance Requirements (GSPR). The expanded 2nd edition of this ebook includes a detailed summary of the IVDR GSPR regulations in addition to those of the MDR. It provides you with practical guidance on how to meet the GSPR requirements for all types of medical technology products. This ebook, however, should not take the place of reviewing the actual regulations and consulting regulatory experts when needed
Timeline
The EU MDR submission became mandatory from the previous MDD directive on May 26, 2021, and the EU IVDR effective date is quickly approaching. In fact, all submissions for new devices under the new EU IVDR must be implemented no later than May 25, 2022. Below is a high-level overview of key dates for both regulations.
*Note that the timeline for compliance was extended in 2021. Class D (high-risk) devices have until 2025 to comply with IVDR, while Class C devices have until 2026. Class B and Class A sterile devices have until 2027 to comply with IVDR.
What’s the difference between Essential Requirements, General Safety and Performance Requirements (GSPR), and Essential Principles. In order to have a meaningful dialogue, let’s first discuss the three (3) main terms used in the industry.
#1 Essential requirements
The ‘Essential Requirements’ is the backbone for establishing conformity with the Medical Device Directive (MDD 93/42/EEC) and the Active Implantable Medical Device Directive (AIMDD 90/385/EEC). Detailed within Annex I of the MDD and AIMDD, the ‘Essential Requirements’ laid out the requirements that devices must meet in order to state compliance to the directives. With the implementation of the new EU Medical Device Regulation (MDR 2017/745), the ‘Essential Requirements’ will become superseded by the new EU MDR General Safety and Performance Requirements (GSPRs).
#2 Essential principles
The IMDRF laid out Essential Principles requirements in a document entitled Essential Principles of Safety and Performance of Medical Devices and IVD Medical Devices. From a high-level perspective, three basic tenets make up these ‘Essential Principles’:
- A device must be designed to be safe and perform effectively throughout its lifecycle.
- Device manufacturers must maintain all design characteristics.
- Devices must be used in a way that is consistent with how it was designed.
Many countries use the term ‘Essential Principles’ when compiling the documentation required to determine compliance to the law. For instance, the Australian Therapeutic Goods Administration (TGA) uses the term ‘Essential Principles Checklist’. Regardless of the term used, Essential Principles are of similar nature and overlap many of the Essential Requirements and new GSPRs.
#3 General safety and performance requirements (GSPR)
As of May 26, 2021, medical device manufacturers must start to comply with Annex I – General Safety and Performance Requirements (GSPRs) of the new EU Medical Device Regulation (MDR 2017/745). GSPRs are specific to the European MDR and IVDR. If you hear any other term (i.e. Essential Principles), it most likely means it is not referencing the European market.
Annex I of the EU MDR and IVDR details the specific requirements of the General Safety and Performance Requirements (GSPRs). The GSPRs are broken down into three (3) chapters in Annex I, MDR 2017/745 and IVDR 2017/746:
- Chapter 1 - General requirements
- Chapter 2 - Requirements regarding design and manufacture
- Chapter 3 - Requirements regarding the information supplied with the device
Chapter 1 - General requirements
Both the EU MDR and the EU IVDR outline General Safety and Performance Requirements (GSPRs) in great detail for medical device designers and manufacturers. The general requirements for each are almost identical and consist of the following:
- Devices must perform in a way that aligns with the intended design.
- They must not compromise the health or safety of a patient, user, or any other person associated with the device.
- Risks must be reduced as much as possible, but not so much that they negatively affect the risk-benefit ratio.
- Device manufacturers must implement and maintain a thorough, well-documented, and evaluative risk management system that continues to be updated throughout the life cycle of a device.
- Manufacturers and designers must include any necessary measures for protecting users in cases where risks cannot be completely eliminated.
- Manufacturers must provide users with information about any potential risks that remain. This information must be clear, easy to understand, and considerate of the users’ technical knowledge level, use environment, and any applicable medical conditions.
- Devices must withstand the stresses of normal use for the duration of their lifecycle. Devices must be designed, manufactured, and packaged in a way that protects them from damage during transport and storage.
- When it comes to risks and negative side effects that are known and foreseeable, designers and manufacturers must make every effort to minimize negative outcomes. They must also ensure that potential risks are acceptable when compared to the potential benefits of a device to its users.
Chapter 2 - Requirements regarding design and manufacture
The GSPRs also provide key details regarding specific information about the performance, design and manufacture of medical devices. As it relates to design inputs, the MDR and IVDR GSPRs provide highly detailed requirements relating to a device’s technical information. Further detail can be found in the comparison tables in Appendix A and Appendix B, where we have compared MDR to MDD and IVDR to IVDD.
Chapter 3 - Requirements regarding the information supplied with the device
The final key area of governance within the GSPRs relates to specific information a manufacturer must supply with a device. The general requirements for this information states that, “Each device shall be accompanied by the information needed to identify the device and its manufacturer, and by any safety and performance information relevant to the user, or any other person, as appropriate.” The requirements provide further detail as far as location - specific information that must be provided on the following:
- The device label includes its UDI.
- The user instructions.
- The packaging of a device that is intended to maintain its sterile condition.
Medical devices are subject to significant regulations and a full understanding of EU MDR and/or IVDR labeling as defined in Annex 1 Chapter 3.
In addition to the specific requirements identified within Annex I of the EU MDR and IVDR, Annex II, Technical Documentation, identifies additional requirements. Specifically, in both EU MDR and IVDR’s Section 4 – General Safety and Performance Requirements it states:
“the documentation shall contain information for the demonstration of conformity with the general safety and performance requirements set out in Annex I that are applicable to the device taking into account its intended purpose, and shall include a justification, validation and verification of the solutions adopted to meet those requirements. The demonstration of conformity shall include:
(a) the general safety and performance requirements that apply to the device and an explanation as to why others do not apply;
(b) the method or methods used to demonstrate conformity with each applicable general safety and performance requirement;
(c) the harmonised standards, CS or other solutions applied; and
(d) the precise identity of the controlled documents offering evidence of conformity with each harmonised standard, CS or other method applied to demonstrate conformity with the general safety and performance requirements. The information referred to under this point shall incorporate a cross reference to the location of such evidence within the full technical documentation and, if applicable, the summary technical documentation.”
Let’s break this down into each part.
Requirement
(a) the general safety and performance requirements that apply to the device and an explanation as to why others do not apply;
What needs to be documented for the requirements that apply or the requirements that do not apply?
Each and every section of the EU MDR GSPR or EU IVDR should be assessed in its own right as it pertains to your medical device. When a requirement applies, a simple statement may be made that this requirement applies to the device. In practice this is often achieved using a checklist or table, with a column for applicability and a Yes/No answer against each requirement. When a requirement applies, you can move on to the other parts of demonstrating conformity regarding methods used and standards applied.
When a requirement is not applicable, a statement must be made to that effect, i.e. a ‘No’ in the applicability column. Additionally, it must be fully and properly justified. Such a justification may be something like ‘The device is not powered and is therefore not an active device. This requirement does not apply.' The justification should clearly state why the requirement has been deemed not to apply so that your notified body can understand your reasoning
Requirement
(b) the method or methods used to demonstrate conformity with each applicable general safety and performance requirement;
What is meant by “method or methods used”?
This relates to the way you complied with that GSPR requirement, historically it would be listed as a standard or other documentation reference that you have applied to demonstrate compliance, however, the question of ‘method or methods used’ is new to the MDR and it is expected that a verbal description be provided such as:
i. Risk analysis weighed against clinical evaluation benefit
ii. Performance intended demonstrated by design requirements, verification and validation
Requirement
(c) the harmonized standards, common standards (CS) or other solutions applied;
What are harmonized standards, common specifications (CS), and “other solutions”?
Harmonized standards
These are standards that have been specifically developed and assessed for compliance to a regulation or directive. They are published in the Official Journal of the European Union (sometimes just referred to as ‘the OJ’) and if you comply with these standards then there is a ‘presumption of conformity’ with that directive or regulation to which they have been harmonized. These harmonized standards can only be created by a recognized European Standard Organization (such as CEN or CENELEC). When a standard is harmonized, an annex is added that describes how the standard conforms to the directive or regulation. When using harmonized standards, you should make sure that you understand how the standard conforms so that you do not claim compliance when the standard either does not meet that requirement or only partially meets that requirement.
If a standard does not meet a certain requirement of the directive or regulation, or indeed only partially meets it, then you must employ additional mechanisms for compliance. If a harmonized standard meets part of a directive or regulation, then by complying with that standard you also fully meet the corresponding requirement(s) The list of harmonized standards continues to grow - refer to the “Healthcare Engineering” section of the European Commission’s Harmonized Standards page for current information. In this case, using an MDD harmonized standard and documenting a justification for doing so (i.e. how you believe the standard demonstrates compliance with the GSPRs), should provide sufficient evidence
Common specifications
Common Specifications (CS) are a new concept in the MDR. They allow the European Union to add additional requirements that must be met in order to claim compliance where harmonized standards do not exist or where relevant standards are considered insufficient. The definition of a Common Specification is:
‘A set of technical and/or clinical requirements, other than a standard, that provides a means of complying with the legal obligations applicable to a device, process or system.’
Requirement
(d) the precise identity of the controlled documents offering evidence of conformity with each harmonized standard, CS or other method applied to demonstrate conformity with the general safety and performance requirements. The information referred to under this point shall incorporate a cross- reference to the location of such evidence within the full technical documentation and, if applicable, the summary technical documentation;
What is the expectation for incorporating a "cross-reference to the location of such evidence within the full technical documentation"?
This means that someone looking at the document should be able to identify exactly where in the technical documentation that the compliance evidence can be found. For example, this may refer to test reports and their exact location, or it could even reference locations within a large document, depending on the GSPR and your particular documentation. (i.e. if you have included usability risks as part of a larger risk assessment, you may need to say ‘See Technical File XXX, Section XX, Doc RMF001 rev 3 lines 65-78’). In other cases it could just mean the whole document reference, i.e. Have you done risk management? – then yes, it is RMF001 rev 3. What the specific reference actually is depends on how you have managed your technical documentation and how defined it is (i.e. separate reports or one big one). There should be no ambiguity as to where the document is located
An example of a completed GSPR checklist could look something like this (applicable and nonapplicable examples are shown):
Specification developers and manufacturers must continually maintain their technical documentation to stay compliant. Part of this process is to ensure that they take into account the "generally acknowledged state of the art".
Proactive monitoring
'State of the art'
There is no formal definition of ‘state of the art’ within the EU MDR or IVDR, although it is mentioned many times. ‘State of the art’ is an ongoing debate; however, it generally means that it embodies what is currently and generally accepted as good practice in the medtech industry. The ‘state of the art’ does not necessarily imply the most technologically advanced solution.
One consensus on state of the art is being up to date and compliant with the current and in effect standards that are applicable to your device. This means that if a standard is updated that your medical device is compliant with, you must evaluate that update to ensure that it would meet the EU MDR or EU IVDR ‘state of the art’ requirement. This is not a new requirement from the EU MDD but it is spelled out more clearly in the EU MDR.
The specification developer or manufacturer is ultimately responsible for determining if the updated standard applies or does not apply to their device(s). Either way, the justification should be documented within a gap analysis.
Monitoring for changes
Of course, 'state of the art' only applies if you actually know if something changed. This is why you need to develop a process for monitoring the standards that compliance is claimed. Every single standard that is associated with your technical documentation must be actively monitored, reviewed, and reported on.
If you have a product on the market and need a better way to monitor and maintain your General Safety and Performance Requirements (GSPR) or Essential Principles, Rimsys can help. Rimsys digitizes and automates GSPR and Essential Requirements so you can dynamically update and proactively monitor changing standards and evidence files.
When a standard or evidence file changes, you will automatically be notified and can update one GSPR or all of your GSPRs as applicable with a single click of a button. If additional information is needed, such as testing, it’s also invaluable to ensure that all devices are identified. What used to take weeks of manual, error-prone administrative tasks is now done in seconds within a fully validated, secure, maintenance-free, cloud-based solution
Maintenance
Maintaining and updating your technical documentation is generally the hardest part of staying compliant. Robust processes must be established to ensure nothing slips through the cracks and show up as nonconformances during regulatory audits.
Gap analysis
In addition to meeting the ‘state of the art’ requirements and the continuous proactive monitoring of standards, once a change has been detected that affects the technical documentation, a proper and thorough gap analysis must be completed.
The gap analysis between the old versions and the new versions, or an evaluation of a brand new standard, must occur and be properly documented. The gap analysis should detail what is applicable and what is not applicable, with your supporting justification.
If something within the new or revised standard was applicable to your device, additional engineering testing, documentation, justification, and, in some instances design changes, may be needed to ensure compliance
GSPR updates
Once the gap analysis has been properly documented, specification developers and manufacturers must update their GSPRs.
These updates include finding the withdrawn or superseded standard or evidence file throughout each row within your GSPR table, for every single device on the market on which this change is applicable. This could be one table or dozens of tables depending on the complexity of the products and your product mix.
Without a holistic RIM system to help you, this is an error-prone process as is it tedious, administrative, and extremely easy to miss an inappropriate referenced standard or evidence file.
Extreme diligence on the regulatory or engineering team must occur to ensure these critical updates to the GSPRs are not missed and a gap analysis must be properly referenced throughout. Any justification for including or excluding a new standard or evidence file will be scrutinized by regulatory auditors, and without proper maintenance, may lead to additional review time.
To continue reading this eBook including Comparison Table of the EU MDR Annex I GSPR vs. the EU MDD Annex I Essential Requirements, please register to download the full version.
