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 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.
The beginner's guide to the FDA PMA submission process
This article is an excerpt from The beginner's guide to the FDA PMA submission process ebook.
Table of Contents
- Introduction
- PMA basics
- FDA interactions
- Contents of a traditional PMA submission
- PMA supplements and amendments
- PMA Quality Management System (QMS)
- Review process and timeline
If your organization is planning to market a new medical device in the United States, you first need to determine which regulatory class the device falls under. The vast majority of medical devices regulated by the FDA are either Class I or Class II medical devices, requiring a 510(k) premarket notification or a simple registration if exempt from 510(k) requirements. However, if your device sustains or supports life, is implanted, or presents a “potential unreasonable risk of illness or injury,” your device is likely a Class III device which will require Premarket Approval (PMA) from the FDA before it can be marketed in the United States. Novel devices, for which there are no existing substantially equivalent devices, are automatically classified as Class III as well. Novel devices with a lower risk profile, however, may qualify for the De Novo process instead of the PMA. Just 10% of devices regulated by the FDA are Class III devices.
This ebook provides an overview of the PMA process and its requirements, but it is not designed to be the only resource used in compiling a PMA submission. The FDA provides significant documentation on this process, starting with the regulation governing premarket approval that is located in Title 21 Code of Federal Regulations (CFR) Part 814.
FDA: Background and device oversight
Before we explain what a PMA is, let’s first talk generally about the Food and Drug Administration (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 notification, (2) Premarket Notification, also known as 510(k), and (3) Premarket Approval (PMA).
When is a PMA required?
The PMA process is the most stringent regulatory process for medical device approval under the FDA and applies to almost all Class III devices. To determine whether your device requires a PMA, you must first Classify your device by searching the Product Classification Database. The database will provide you with similar devices; their name, classification, and link to the Code of Federal Regulations (CFR) if applicable.
- If a substantial equivalent is found in the Product Classification Database with a submission type of 510(k), you should submit a 510(k), not a PMA.
- If the product classification database identifies your device as Class III and/or requiring a PMA - you should submit a PMA.
- If your device involves a new concept and does not have a classification regulation in the CFR, the database will list only the device type name and product code. In this case, the three-letter product code can be used to search the PMA database and the 510(k).
- If your device cannot be found in the product classification database because it is a new type of device and should be classified as a Class III device because of the level of risk it presents*.
Class III devices support or sustain human life, are of substantial importance in preventing impairment of human health, or present a potential and unreasonable risk of illness or injury.
Note that if your device is a new concept without a substantial equivalent, but does not present the level of risk of a class III device, it may be eligible for the De Novo process as a class I or class II device.
PMA vs 510(k)
Not only are PMA and 510(k) processes applicable to different types of devices, they have different purposes.
510(k): A 510(k) is intended to demonstrate that the device for which approval is being sought is as safe and effective as a currently marketed device that does not require a PMA.
PMA: A PMA is intended to prove that a new device is safe and effective for the end user. A PMA is much more detailed and in-depth than a 510(k). Device manufacturers are typically required to present human clinical trial data, in addition to laboratory testing data.
The difference in complexity between a PMA and 510(k) also affects the time needed to process the submissions. The FDA typically accepts or rejects a 510(k) submission within 30-90 days, at which point the device is posted to the FDA’s 510(k) database. A PMA submission can take up to 180 days to be processed, at which point the FDA can approve or deny the application. The FDA may also issue an “approvable” or “not approvable” letter, which the applicant can choose to respond to, thereby adding time to the submission process.
PMA application methods
There are a number of types of PMA application methods. While most devices which require a PMA will follow the traditional process, be sure to verify that you are using the correct application process to maximize your chances for success and avoid unnecessary delays:
Traditional PMA
The most common method for attaining FDA clearance for Class III devices, the traditional PMA is the appropriate option for most devices that have completed clinical testing.
Modular PMA
The modular PMA is the appropriate application method for devices that have not yet completed clinical testing. Applicants complete individual “modules,” with final confirmation granted once all sections are completed. For additional information on specific requirements of a modular PMA, read the FDA’s Premarket Approval Application Modular Review.
Product Development Protocol
Use the Product Development Protocol (PDP) with medical devices that are based on well-established technology. The PDP process for gaining market approval merges the clinical evaluation and development of information, and involves an agreement between the manufacturer and the FDA. The process provides the advantage of early predictability for the manufacturer and allows early interaction that can identifyFDA concerns as soon as possible in the development process. Because the PDP identifies the agreed upon design and development details, a completed PDP is considered to have an approved PMA. For additional information, read more about the FDA’s PMA Application Methods.
Humanitarian Device Exemption
A Humanitarian Use Device (HUD) is specifically defined as a device intended to benefit patients that are affected by a disease or condition that affects less than 8,000 individuals in the U.S. per year. TheHumanitarian Device Exemption (HDE) approval process is designed to encourage clinical activity around rare conditions, and does have certain restrictions, including:
- After receiving HDE approval, a HUD is eligible to be sold for profit only if the device is intended to address a disease or condition that occurs primarily in pediatric patients, or occurs in pediatric patients in small numbers.
- If an HDE is approved to be sold for profit, the FDA will determine an annual distribution number(ADN). Any devices sold beyond the ADN limit are required to be sold for no profit.
For more information see the FDA’s explanation of the Humanitarian Device Exemption.
CBER Submissions
There are two centers within the FDA responsible for evaluating medical devices. While the majority of devices will go through the Center for Devices and Radiological Health (CDRH), some will be managed by The Center for Biologics Evaluation and Research (CBER). CBER regulates medical devices related to blood and cellular products, including blood collection and processing procedures as well as cellular therapies. This ebook focuses on submissions made through the CDRH, but you can view CBER Regulatory Submissions – Electronic and Paper for more information on the CBER process.
To continue reading this eBook, including a walk through of the different types of required and optional FDA meetings and communications, a detailed list of the contents of a traditional PMA submission, and an overview of quality management system requirements, please register to download the full version.
An overview of 21 CFR Part 11 regulations for medical device companies
What is 21 CFR Part 11?
21 CFR Part 11 refers to the federal regulation that address electronic records and electronic signatures associated with FDA requirements. This single, relatively small, part of the Code of Federal Regulations is extremely significant for companies with FDA-regulated products because it impacts every document signature, electronic file, and FDA submission. Codified in 1997, interpretations of this FDA-issued regulation continue to be debated and re-evaluated as the technology supporting electronic records and signatures changes. In this article, we’ll discuss the regulation and generally accepted interpretations.
Note that discussions and statements in this document are our observations only and should not be taken as fact. You can refer directly to the regulation here.
Part 11: General Provisions
The General Provisions section of 21CFR11 addresses the scope of the regulation, when and how it should be implemented, and defines some of the key terms used. It states that the purpose of Part 11 is to define the criteria under which electronic records, electronic signatures, and handwritten signatures attached to electronic records are equivalent to, and as reliable as, handwritten signatures on paper documents.
Fundamentally, any record that is maintained, used, or submitted under any FDA records regulation is subject to Part 11, and the FDA will accept electronic records in lieu of paper records if an organization can prove that their records and systems meet the Part 11 requirements.
The General Provisions subpart also sets forth a number of definitions, and we’ve listed the ones that are most significant to our discussion here:
- Closed System: A computer system or software whose access is controlled by the same people who are responsible for the information stored in the system. Because the opposite of a closed system, and “open system,” is subject to additional scrutiny be sure that you are able to thoroughly explain and provide documentation for a decision to classify your system as a “closed system.”
- Open System: A computer system or software whose access is not controlled by the same people who are responsible for the information stored in the system.
- Digital Signature: An electronic signature created in a manner that can be verified, ensures the identity of the signer, and maintains the integrity of the document and signature. This often involves the use of cryptography and/or biometric data.
- Electronic Signature: Symbols that represent a legally binding equivalent to an individual’s handwritten signature (as adopted and authorized by the signer).
Part 11: Electronic Records
The Electronic Records section sets forth the requirements for administration of closed and open electronic record-keeping systems, then discusses signature manifestations and requirements for establishing a link between signatures and records.
Part 11 defines a “closed system” as any computer system in which the users controlling access to the system are the same people who are responsible for the data in the system. Today, most systems can be classified as closed systems, but take special care to document control procedures around software that is hosted offsite or classified as a SaaS solution.
This section of the regulation deals with the controls that need to be in place for all applicable electronic record systems by defining:
- Procedures to ensure that all electronic records are authentic, have integrity, and can ensure confidentiality (where that is appropriate).
- Validation requirements for systems that maintain electronic records to ensure that all records are accurate, reliable, and that the system performs consistently according to regulatory requirements.
- Audit trail requirements for all regulated records to ensure a complete history of all changes to records are maintained.
- Controls around system access and document signatures.
Part 11: Electronic Signatures
The Electronic Signatures section defines the components of electronic signatures and the required controls and procedures necessary for using them.
In general, an organization must be able to demonstrate that electronic signatures:
- Are unique to each individual, and that the individual assigned an electronic signature has had their identity and level of authorization verified.
- Must be based either on biometric data (such as fingerprints) or made up of two distinct pieces (ie: a User ID and password)
- Require appropriate controls to ensure that they are verified periodically, cannot be used by someone other than the intended user, and are immediately deactivated if compromised in any way.
Practical application of 21CFR Part 11 for regulatory affairs professionals
21 CFR Part 11 is a critical regulation, and one that can be open to interpretation. Below, we cover some of the key areas that should be of concern for RA professionals. This is an overview of key areas only, and should not be taken as complete instruction or guidance for 21CFR part 11 compliance.
System compliance and validation
Any system that you are using to store electronic records that fall under FDA regulations needs to be compliant with Part 11. This includes everything from spreadsheets to full-featured RIM and document management systems.
Software vendors will often document how their systems are developed to be compliant, and may even support system validation during implementation - but it is ultimately the responsibility of the user organization to ensure that their systems and processes are compliant with Part 11. System validation is the process of documenting that your system meets all of the Part 11 requirements. Software vendors can support this process by ensuring that their systems are built on a highly secured infrastructure that can be demonstrated and proven.
The Rimsys system was built from the ground up to meet the stringent requirements of not only 21 CFR Part 11, but other industry standards and good practices guidelines (GxP). We have put in place a rigorous validation program, built by industry experts and supported by a secure and well-documented infrastructure. For more information, visit the Rimsys Security and Privacy page.
Audit trails
Audit trails are the required system logs that track the who, when, and what of every change made to data that falls under Part 11. Audit trails should be generated and time-stamped by the system, with no ability for users to change that information. Audit trails serve two purposes under 21 CFR Part 11:
- To demonstrate that documented policies and procedures are being followed, including that only users with the appropriate authority are managing data.
- To prove that data retention policies are being adhered to (see below).
At any time, you should be able to view the history of any record, from a Design History File to a submission document, in order to determine what changes have been made, when they were made, and by whom.
Record retention
21 CFR Part 11 specifies that electronic records must be protected and readily available throughout the defined record retention period. Additionally, 21 CFR Part 820 specifies that records related to the quality, manufacturer, regulatory submissions, or any other data that falls under FDA regulation, should be maintained for the life of the medical device and for a minimum of two years from the date of first commercial distribution. This is often referred to as “cradle to grave” tracking.
This means that regulatory professionals need to not only be aware of their company’s record retention policy, but need to ensure that any system being used to track regulatory submissions or other data subject to audit meets Part 11 and Part 820 requirements. Note that record retention requirements apply also to paper records where they are the source document.
Electronic and digital signatures
An important piece of 21 CFR Part 11 is its definition of electronic and digital signatures. “Electronic signature” is used to define any set of symbols that are used in place of a handwritten signature, whereas a “digital signature” is an electronic signature based on methods that ensure the identity of the signer where the integrity of the data can be verified. A digital signature can be based on biometric data (such as fingerprints) or secure user IDs and passwords that are controlled to ensure only one authorized user can use the signature.
As a regulatory affairs professional, you should ensure that:
- Everyone on your team who needs to sign documents has their own unique digital signature and understands the importance of protecting it. Sharing of electronic credentials is a common FDA audit observation. Also ensure that users who are not required to sign documents have appropriate access to data to discourage other users from sharing login credentials with them.
- You are following your company’s policies concerning electronic signature audits so that passwords remain updated and strong and signatures are revoked when a user leaves or changes positions.
- You immediately report any possible loss, theft, or sharing of user credentials or devices that generate identification codes.
While 21 CFR Part 11 is usually considered more of a “quality regulation,” it is important that regulatory teams within medical device organizations fully understand this regulation and its compliance implications. To learn more about the regulations, click below to read our regulatory brief.
IEC 62304: Standard for medical device software
What is IEC 62304?
IEC 62304:2006 / AMD 1:2015 is the current version of the international standard that defines the software lifecycle processes for software used in medical devices. IEC 62304:2006 is considered a harmonized standard, meaning that it is recognized by the FDA and other regulatory agencies around the world.
Note that this standard applies both to Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD).
How is IEC 62304:2006 organized?
There are 9 chapters in IEC 62304. The first 4 chapters define the scope of the standard as well as references, terms, and general requirements. The following 5 chapters are as follows:
- Chapter 5 – Software Development Process. This chapter is the most important to fully understand because it defines the software development planning process, including requirements analysis, design, testing, and release processes.
- Chapter 6 – Software Maintenance. This chapter defines the need for a software maintenance plan, including implementation of a maintenance plan and issue analysis procedures.
- Chapter 7 – Software Risk Management. Identification of hazardous situations, risk control, verification, and risk management procedures assume that an organization-level risk management plan is in place following the ISO 14971 standard.
- Chapter 8 – Software Configuration Management. This includes change control and configuration status tracking.
- Chapter 9 – Software Problem Resolution. This chapter addresses investigating and reporting on problems, change control processes, trend analysis, and resolution testing and verification.
IEC 62304:2006 software risk categories
IEC 62304:2006 defines three classes of risk for medical device software based on the risk of harm from a hazardous situation which the software could cause or to which it could contribute. As with risk management systems for other medical devices, the procedures, controls, and processes for medical device software should be appropriate for the level of risk posed by the software.
- Class A – No injury or damage to health is possible.
- Class B – Injury is possible, but not serious.
- Class C – Death or serious injury is possible.
Software development and maintenance processes in IEC 62304
The software development process, as defined in Chapter 5 of this standard, lays out 8 process steps.
- Software development planning (5.1)
- Software requirements analysis (5.2)
- Software architectural design (5.3)
- Software detailed design (5.4)
- Software unit implementation and verification (5.5)
- Software integration and integration testing (5.6)
- Software system testing (5.7)
- Software release (5.8)
IEC 62304 recommended documentation
In general, the following list of deliverables is typically needed to establish conformance with IEC 62304:2006:
- Software development plan - Define processes, deliverables, and development activities. The plan should include the Life Cycle Activities, Risk Management Plan, Documentation Plan, Configuration Management Plan, Change Control process, and Problem Resolution process.
- Software verification plan - Describe the software test plan. Include all verification activities, such as code review, unit test and integration test plans, and the final system software verification test plan.
- Software classification – Classify the software based on risk level as Class A, B, or C per definitions in the standard. Classification should also be established per market-specific requirements (ie: FDA Class I, II, or III).
- Software description – High-level description of the software function, intended use, and technology used.
- Software requirement specifications - Include specifications for all requirements, including functional, performance, interface, and safety requirements.
- Software architecture - Include diagrams of subsystems, major components, and the interfaces between them. This can provide segregation of software entities for risk control.
- Software hazards analysis - The hazard analysis should identify potential hazards and the software components that could cause them. Include mitigations that feed back into the requirements. Be sure to include OTS and wireless QoS hazard analysis where applicable.
- Cybersecurity plan - Document cybersecurity controls and features, threat model, hazard analysis, and penetration testing.
- Detailed design descriptions - Include specifications detailing how the software is implemented.
- Off-the-shelf software list – Identify any OTS software used, including detailed information regarding source, version, and licensing.
- Code unit verification - Document the unit test and code review as performed to plan.
- Integration tests - Document the integration, regression, and OTS software testing performed per the plan.
- System software verification protocols - Document test protocols for final device software. Include requirements tracing and show coverage of requirements (using pass/fail criteria).
- Summary test report - Create a summary of all software verification per the verification and validation plan.
- Trace matrix - Link system requirements to software requirements to associated design specifications and test protocols in one document (typically a spreadsheet). Include software hazards with software mitigations.
- Revision level history - Document major revisions and releases made during development, including descriptions of each.
- Unresolved anomalies - Document any anomalies still present and their associated risk. Include justification for release.
- Software problem resolution process - Describe how reported problems are evaluated and investigated, including how change requests and any necessary regression testing will be handled.
Complying with IEC 62304
More than most other standards, IEC 62304 requires an understanding of multiple disciplines to ensure compliance. Be sure to include team members with expertise in software development, risk management, and regulatory affairs when defining processes related to this standard.
Complying with IEC 62304 is only part of what is required for market clearance for software as a medical device. In the U.S., a 510(k) submission is typically required. Read our 510(k) guide here.
RIM vs PLM software for medical device manufacturers
Regulatory affairs professionals at large medical device companies must manage heavy submission workloads, registrations for products currently on the market, and ever-changing regulatory requirements. Many RA teams are still relying on paper documents, spreadsheets, and other outdated tools and methods to complete this work, while others have taken steps toward digitization and automation of key processes.
Regulatory teams often struggle to find software tools designed specifically for them. Because the processes they manage are typically product-focused, RA teams may attempt to use software built for product design and engineering teams, including product lifecycle management (PLM) systems.
What is PLM software?
Product lifecycle management (PLM) applications provide a central system for managing everything from the design of a new product to testing and ongoing maintenance. PLM systems are typically used by multiple teams, including product design and engineering teams, to coordinate product-related processes. The core elements of a PLM system include:
- Document management of design files and process documents
- Product structure management (source of truth for bills of material)
- Product component detail tracking and approvals (attribute management)
- Workflow and project/task management for product-related processes
- Product version control
- Secure management and approval processes for engineering and product changes (ECNs, ECOs, etc.)
- Integration with CAD and PDM (product data management) tools
PLM software can be considered both a data warehouse and a secure project system. PLM systems are used for storing and retrieving all product design-related information; including version-specific manufacturing (CAD) drawings, specifications, and supplier requirements. These systems also manage the workflows associated with each stage of a product’s lifecycle, from the design process to product maintenance to end of life activities. For medical device manufacturers, the PLM system is typically where design history files and device master records are maintained.
What are RIM systems?
Regulatory information management (RIM) systems have been around for years in the pharmaceutical industry but are relatively new in the medical device industry. Holistic RIM systems enable users to create a single source of truth for all data associated with regulatory submissions and registration management. RA teams are able to focus on critical tasks by using RIM systems to digitize data and automate key processes.
RIM system functions are designed to support a range of regulatory activities across a product’s lifecycle. In addition to centralizing core regulatory data and managing regulatory registrations and certificates, RIM systems can also support:
- Submission planning, authoring, and assembly
- Market entrance requirements and pre-built submission templates
- Collaborative content authoring and project management
- UDI management
- Standards management
- Essential principles/GSPR management, including bulk updating
RIM systems also tend to be product-centric, structuring data around individual regulated products, but are focused on saleable products, components, and packages where PLM systems are focused on the manufactured items. This means that RIM systems can track product-specific data, such as sales status by country, and link standards with individual products to easily identify products affected by standards updates and assess their impact.
Integrating PLM and RIM systems
PLM systems will often be integrated with ERP systems to ensure the correct bills of material and other product details for the current version of the product are being used by the manufacturing system. PLM systems can also be integrated with eQMS (quality management systems) and RIM systems to ensure coordination of risk management activities, product updates, and quality data between the regulatory, quality, and product teams. Ideally, your regulatory team should be notified as early as possible of any planned updates or changes to a product that is in-market or pending market approval.
RIM for regulatory projects and processes
Digitization and automation of regulatory data are more critical as global regulations continue to change and become more complex. Getting a medical device to market is a difficult process, but RIM software cuts the time and costs associated with product registrations while providing tools essential for ensuring ongoing compliance. PLM systems are critical as well, but their focus on product design and other product details simply does not provide the functionality needed by regulatory teams. Integrate a strong PLM system with a holistic RIM system to give both your engineering and regulatory teams the tools they need to bring your products to market successfully and to maintain compliance. To get your regulatory ducks in a row, only a RIM system will do!
To learn more about the Rimsys RIM system, talk to one of our experts today.
The state of regulatory performance in 2023
Today at Rimsys, we unveiled the 2023 MedTech Regulatory Performance Report, a new set of insights into the state of medtech regulatory affairs. Compiled based on interviews with 200 regulatory professionals and executives, the study provides a detailed look into how regulatory teams are staffed, their processes, the tools they use, and ultimately how they perform.
Why did we create this study? There were two driving factors behind the research. The first was a common theme that we heard from a number of our customers: Regulatory leaders don’t have clear data and benchmarks. They don’t necessarily know how long a new market submission should take, and how to plan for or assess the work of their teams. While other studies look at the medtech industry broadly or the state of the regulatory profession, this study tries to build a comprehensive resource for regulatory (and company) leaders.
The second factor was really for ourselves and the team at Rimsys. As a company building solutions specifically for medtech regulatory affairs, we wanted more insight into where companies were successful, where they struggled, and where we can add value.
What did we find? Regulatory teams perform a lot of hero work and rate themselves highly for their accomplishments. At the same time there is a lot of opportunity for process improvements, and companies that invest in digital transformation for regulatory affairs see better performance.
Regulatory professionals are superheroes
Regulatory teams are generally pretty small. Most companies have less than 10 full-time regulatory professionals. These small teams complete an enormous amount of work. Last year on average, RA teams completed 50 license renewals, 50 license updates, and 10 new market submissions. This is impressive output.
Digging a bit under the covers, we found that this output relied heavily on the support of external consultants. 90% of companies use consultants to keep pace with their regulatory workload. Front-line employees also struggle with burnout. They were much more likely to report feeling under-resourced than regulatory leaders.
But process problems persist
A lot of regulatory work remains extremely manual. 70% of regulatory teams spend half their time or more on repetitive administrative tasks. All of this manual work increases the frequency of errors and required rework. 61% of companies reported a major non-compliance incident in the past 2 years.
Manual work also makes it difficult to complete regulatory projects in a timely fashion. Teams completed a lot of projects, but each took a long time. Over half of all companies spend 4 months or more on license renewals, license updates, and new market submissions.
Moving regulatory affairs forward
As regulatory requirements become more complex, there’s a natural question about how teams will work moving forward. MDR & IVDR in Europe have significantly increased the regulatory workload required to bring and keep products on the market. Will organizations be able to keep pace with the same resources, tools, and processes?
No, and the performance report shows that medtech companies are investing to improve their regulatory capabilities. The majority of companies are planning to increase the sizes of their RA teams in 2023, and 40% expect to increase their investments in regulatory software. Companies are increasingly adopting specialized software to better support regulatory processes.
Dig into the survey results
The full survey results provide insights into more aspects of regulatory performance. They show that companies need to take a deeper look into their processes and how regulatory resources are allocated. There are two ways to learn more:
- Visit the survey page to see the full results (the survey whitepaper can be downloaded at no cost)
- Watch the recording of our webinar with PA Consulting. We discuss the survey results in more detail and share our regulatory predictions for 2023
RIM vs eQMS software for medical device manufacturers
Regulatory affairs professionals at large medical device companies must manage heavy submission workloads, registrations for products currently on the market, and ever-changing regulatory requirements. Many RA teams are still relying on paper documents, spreadsheets, and other outdated tools and methods to complete this work, while others have taken steps toward digitization and automation of key processes.
Regulatory teams often struggle to find software tools designed specifically to help manage their regulatory projects. As a result, some RA teams attempt to repurpose software developed for other functions, such as electronic quality management systems (eQMS). While eQMS systems can provide some functionality that RA teams need, regulatory information management (RIM) software delivers a holistic platform designed to reduce administrative work and manage global compliance activities. In this post, we’ll compare eQMS and RIM software as they relate to regulatory compliance.
What is eQMS software?
Electronic quality management systems (eQMS) are software programs that help quality teams centrally store, monitor, and manage quality and compliance processes. These platforms are usually provided via cloud technology as software-as-a-service (SaaS) solutions. They aim to provide digitization and automation of critical tasks that quality teams traditionally handle manually, such as quality, compliance, and design processes. For medical device companies, these requirements are defined by multiple standards, most notably ISO 13485:2016, FDA 21 CFR Part 820, and the EU MDR.
Digitization and automation are growing trends in most industries, including regulatory affairs and quality management. As you know, medical device manufacturers, especially their quality and RA teams, must manage a large volume of data, of which accuracy and consistency are of the utmost importance. eQMS systems typically handle data and processes in support of the following:
- Document management
- Non-conformance tracking
- Audit management
- Risk management
- Corrective and preventive action (CAPA) management
- Training management
This means that while eQMS software provides some functions and certainly have information that RA teams can use, they are designed around the processes that quality teams are responsible for. RIM software, on the other hand, is designed specifically to help regulatory specialists work more effectively and efficiently.
What are RIM systems, and what do they do?
Regulatory information management (RIM) systems have been around for years in the pharmaceutical industry, but are relatively new in the medical device industry. Comprehensive RIM systems enable users to create a single source of truth for all data associated with regulatory submissions and registration management. These systems lighten the burden on RA teams by digitizing data and automating key processes.
RIM system functions are designed to support a range of regulatory activities across a product’s lifecycle. In addition to centralizing core regulatory data and managing regulatory registrations and certificates, RIM systems can also support:
- Submission planning, authoring, and assembly
- Market entrance requirements and pre-built submission templates
- Collaborative content authoring and project management
- UDI management
- Standards management
- Essential principles/GSPR management, including bulk updating
RIM systems also tend to be product-centric, structuring data around individual regulated products, as opposed to the process-centric approach taken by most eQMS systems. This means that RIM systems can track product-specific data, such as sales status by country, and link standards with individual products to easily identify products affected by standards updates and assess their impact.
Integrating eQMS and RIM systems
While processes in an eQMS system are designed to support quality and risk management requirements, they contain a lot of information that is relevant to regulatory affairs teams. RIM systems such as Rimsys are designed to integrate to eQMS, PLM, and ERP systems in order to coordinate processes and synchronize data. In the case of RIM and eQMS integrations, the systems can synchronize product master data to ensure smoother regulatory submissions and identify the impact of changing documentation on global product registrations and submissions. And Performance and testing data can be linked to digital essential principles tables.
RIM for regulatory projects and processes
Digitization and automation of regulatory data are more critical as global regulations continue to change and become more complex. Getting a medical device to market is a difficult process, but RIM software cuts the time and costs associated with product registrations while providing tools essential for ensuring ongoing compliance. Quality systems are critical as well, but their focus on risk management and corrective and preventative activities simply does not provide the functionality needed by regulatory teams. Integrate a strong eQMS system with a holistic RIM system to give both your quality and regulatory teams the tools they need to bring your products to market successfully and to maintain compliance. To get your regulatory ducks in a row, only a RIM system will do!
To learn more about the Rimsys RIM system, talk to one of our experts today.
6 reasons medtech companies shouldn't delay MDR certification
The latest announcement from the European Commission (EC) recommending an extension to the MDR transition period has led to sighs of relief throughout the healthcare community in the EU, where providers and patients have been concerned about the ongoing availability of life-saving medical devices. Medical device manufacturers, however, have no time to waste in moving forward with MDR certifications for their devices.
On January 6th, the EC adopted the proposal recommended a month earlier to delay the full implementation of the Medical Device Regulation (MDR). The EU’s parliament and council now needs to issue final approval for the proposal, which will be processed through an “accelerated co-decision procedure.” While the proposed changes give medical device manufacturers some breathing room in recertifying existing devices, the changes do not apply to all devices or all situations and are not designed to allow manufacturers to delay the entire process of becoming compliant with MDR requirements.
Yes, if the proposal is approved by the European Commission as it is written today, your MDD-certified device may be able to remain in the EU market longer – the end of 2027 for high-risk devices and 2028 for medium- and low-risk devices. So, why do regulatory teams need to push forward as quickly as possible with MDR certification projects?
1. No extension for IVD devices
The proposed extensions to the transition periods apply only to medical devices covered under the MDR. The original deadlines for IVD devices as defined by the IVDR remain in place:
- May 26, 2025 - Class D IVD devices
- May 26, 2026 - Class C IVD devices
- May 26, 2027 - Class A sterile IVD devices and Class B IVD devices.
2. Lack of Notified Body resources
In April, 2022, a survey of MedTech Europe members revealed that MDR certificates had not yet been issued for more than 85% of the 500,000+ medical devices certified under MDD or AIMDD. Currently, certifications for lower classifications of devices take approximately 10 to 18 months; and for more complex products, the certification timeline can be two years or more. The number of Notified Bodies certified to review MDR applications remains low, and even if Notified Bodies are able to add resources in the coming years, review timelines will only become longer as companies rush to certify the hundreds of thousands of devices expected to remain on the market. The challenges will be even greater for smaller manufacturers and others that do not already have an established relationship with a Notified Body.
What does this mean for medical device manufacturers today? For those with higher-risk class devices, assume a 2-year certification period – which means starting the process with a Notified Body as early as possible, given the unknown availability of NB resources in the near future. At the latest, manufacturers need to have signed with a Notified Body by September 26, 2024 (Per Annex VII, Section 4.3 of the MDR). And prior to starting that process, of course, all required data, processes, and documentation should be in place. This means that any manufacturer who has not started this process needs to do so now.
3. Inability to update devices
The postponed MDR deadlines only apply to devices that do not present any unacceptable risk to health and safety and have not undergone significant changes in design or intended purpose. Any medical device certified under the MDD to which significant changes are made will need to recertify under the MDR before the updated device is placed on the market.
4. EUDAMED and UDI compliance deadlines remain the same
While the exact deadlines for EUDAMED compliance are based on the actual (future) release dates of all modules, The European Commission expects requirements around vigilance, clinical investigation and performance studies, and market surveillance modules to become mandatory by the end of 2024. The Commission is proposing a longer transition period for UDI/device registration and the notified body certificate modules, with a mandatory compliance date around the 2nd quarter of 2026.
Note that the expected EUDAMED compliance dates are prior to the extended MDR compliance deadlines. This means that information not previously tracked under MDD requirements will be mandatory within the next few years. This includes UDI and device information, including Basic UDI-DI (BUDI-DI). Post-market surveillance (PMS) and periodic safety update reports (PSUR), requirements of the vigilance and market surveillance module, also become required upon EDUAMED implementation.
5. MDR certification may affect registrations in non-EU countries
An increasing number of countries outside of the EU will accept CE certification as a path to accelerated market approval. In some countries, such as China, proof of certification in the device’s country of origin is required. It is unclear how these requirements will change in recognition of MDR requirements and deadlines. If your current regulatory strategy requires country of origin for the European Union, you may experience a more burdensome application process in other markets.
6. Opportunity to create a competitive advantage
Instead of looking at MDR as an obstacle to overcome, medical devices manufacturers would be well advised to take this as an opportunity to create a competitive advantage. Companies without the necessary resources to re-certify all existing devices are expected to remove products from the EU market in the coming years. In addition, those companies who wait will likely experience higher costs and longer delays in obtaining certification – creating additional opportunities for their competitors.
And don’t forget that the transition period extensions apply only to legacy devices - any new products entering the EU market will require certification under MDR before being placed on the market!
If your data and processes aren’t yet fully ready for MDR, implementing a Regulatory Information Management (RIM) system as part of the process can create additional advantages beyond streamlining the MDR submission process. RIM systems digitize, automate, and simplify the submission and tracking of regulatory documents. The use of a RIM system not only speeds time to market, but provides regulatory teams tools for ensuring continued compliance for all products in all markets.
Doing nothing now is not an option
It is important to note that the extensions apply only to manufacturers that already have MDR compliance activities underway and have made an effort to become compliant, including the implementation of a compliant quality management system. Per Annex VII, Section 4.3 of the MDR, manufacturers must submit a formal application for a conformity assessment by May 26, 2024. In addition, the manufacturer and Notified Body must have signed a written agreement no later than September 26, 2024. The intent of the extended transition period is primarily to allow manufacturers to access Notified Body resources, and the Commission appears to be making an effort to limit any incentives for manufacturers to delay MDR certification.
We expect to see leaders in the medical device industry embracing MDR compliance not only as a way to keep revenue-generating devices in market, but as a way to gain a competitive advantage and market share in the coming years.
Want to learn more? Watch a replay of our recent webinar - Impact of the MDR transition period extension.
ISO 10993: Standards for the biologic evaluation of medical devices
The International Organization for Standardization (ISO) is the largest body in the world publishing standards. In fact, it is a conglomeration of standards bodies from over 160 countries working together to harmonize standards. As such, ISO 10993 is the international standard that is practically used globally for testing and determining the biocompatibility of medical devices. So it’s critical for medical device manufacturers to understand all 23 parts of ISO 10993 for the success of 510(k), pre-market authorization (PMA), and other device submission projects for regulatory authorities worldwide. As an example, the FDA has issued guidance on the Use of International Standard ISO 10993-1.
What is biocompatibility?
According to ISO 10993-1:2018, the current version of part 1 of the standard, biocompatibility is the ability of a medical device or material to perform with an appropriate host response in a specific application. Any device that comes into direct or indirect contact with the skin must be tested for biocompatibility. A medical device that makes indirect contact with the skin is one that encounters a liquid, gas, or another medium, that makes direct contact with the patient or user.
Categorizations for medical devices according to ISO 10993
When testing the biocompatibility of a device, it is broken down into two categories; one based on its type of contact with humans, and the other based on the duration of contact.
The categorizations for types of contact are:
- Non-contacting medical devices: These are medical devices that do not make direct or indirect contact with patients. Examples include in-vitro diagnostics devices, blood collection tubes, and petri dishes.
- Surface-contacting devices: Surface-contacting medical devices are ones that touch the skin, in-tact mucous membranes, and breached or compromised surfaces. Examples of these devices are catheters, contact lenses, and bronchoscopes.
- Externally communicating devices: Externally communicating devices are those that are partially or wholly external and come into contact with bodily fluids. These devices are usually intended to deliver or draw fluids to or from the body and are attached to an external delivery or withdrawal system. Examples include dialyzers and dialysis tubing accessories, transfer and transfusion sets, and arthroscopes.
- Implantable devices: Implantable devices are the riskiest type for medical devices because they are embedded within human tissue. Pacemakers, artificial larynxes, and heart valves are all implantable devices.
The categorizations for times of duration are:
- Limited exposure – Medical devices whose cumulative sum of single, multiple, or repeated duration of contact is up to 24 hours.
- Prolonged exposure – Medical devices whose cumulative sum of single, multiple, or repeated contact time is likely to exceed 24 hours but does not exceed 30 days.
- Long-term exposure – Medical devices whose cumulative sum of single, multiple, or repeated contact time exceeds 30 days.
Determining biocompatibility
Medical devices are most commonly made of metals, plastics, and fabrics, which are composed of chemicals with varying properties. Manufacturers must gather physical and chemical information about the device, which is vital to its biological and material evaluation and characterization.
For devices with components that are made of or utilize novel chemicals or materials, or those known to cause adverse effects, ISO 10993 requires rigorous risk assessment and management according to the standards of ISO 14971. Furthermore, there are prescribed data endpoints that set the foundation for determining the biocompatibility of medical devices and their intended uses and components.
The main things manufacturers must consider when determining the biocompatibility of medical devices and their components are listed below:
- Complete chemical characterization – ISO 10993 requires manufacturers to describe the chemical and material makeup of the medical device and its components, as well as the use of chemicals in the manufacturing of the device. Sometimes, a test of extractable and leachable chemicals is required to determine the safety of the medical device.
- Toxicological assessment – Toxicological assessment serves to determine and mitigate the risk of medical devices when they come into contact with patients and users. There are four pillars of toxicology assessment: hazard identification, hazard characterization, exposure assessment, and risk characterization.
- Biocompatibility testing – Biocompatibility testing is the process of testing the local and systemic effects of a medical device on the tissues it comes into contact with. Oftentimes a favorable toxicological assessment by a qualified individual, based on the facts of the thorough chemical characterization, can rule out the possibility of adverse effects and the need for biocompatibility testing.
ISO 10993 compliance
Biocompatibility assessment is a vital part of risk management according to ISO 14971. Ensuring compliance with risk management and biocompatibility assessment standards requires buy-in from all departments, from marketing and design to quality assurance and regulatory affairs.
It is vital that you begin considering ISO 10993-1:2018 in the early stages of product design. Part 1 of the standard will refer to additional parts, as listed in the following section. Completing your complete chemical characterization and toxicology assessment early in the process will help ensure the biocompatibility of your medical device during the design phase and expedite your device registration and time to market.
Also, it’s important to note that many regulatory authorities around the world have their own variation of ISO 10993. While these varying standards have the same foundation and are similar in many ways, you must understand their nuances if you plan to offer your medical device internationally.
ISO 10993 sections
ISO 10993 is made up of 23 different sections or parts, each of which is maintained and updated separately. Previews of the standard can be viewed on the ISO website, but full versions of the standard need to be purchased.
- ISO 10993-1:2018 – Evaluation and testing within a risk management system
- ISO 10993-2:2022 – Animal welfare requirements
- ISO 10993-3:2014 – Tests for genotoxicity, carcinogenicity, and reproductive toxicity
- ISO 10993-4:2017 – Selection of tests for interactions with blood
- ISO 10993-5:2009 – Tests for in vitro cytotoxicity
- ISO 10993-6:2016 – Tests for local effects after implantation
- ISO 10993-7:2008 – Ethylene oxide sterilization residuals
- ISO 10993-8: - Withdrawn (Selection of reference materials for biologic tests)
- ISO 10993-9:2019 – Framework for identification and quantification of potential degradation products
- ISO 10993-10:2021 – Tests for skin sensitization
- ISO 10993-11:2017 – Tests for systemic toxicity
- ISO 10993-12:2021 – Sample preparation and reference materials
- ISO 10993-13:2010 – Identification and quantification of degradation products from polymeric medical devices
- ISO 10993-14:2001 – Identification and quantification of degradation products from ceramics
- ISO 10993-15:2019 – Identification and quantification of degradation products from metals and alloys
- ISO 10993-16:2017 – Toxicokinetic study design for degradation products and leachables
- ISO 10993-17:2002 – Establishment of allowable limits for leachable substances
- ISO 10993-18:2020 – Chemical characterization of medical device materials within a risk management process
- ISO 10993-19:2020 – Physico-chemical, morphological, and topographical characterization of materials
- ISO 10993-20:2006 – Principles and methods for immunotoxicology testing of medical devices
- ISO 10993-22:2017 – Guidance on nanomaterials
- ISO 10993-23:2021 – Tests for irritation
How can we help?
Many manufacturers endure longer and more costly paths to market than necessary because they do not have systems and tools designed specifically for their regulatory teams. Furthermore, a lack of visibility and collaboration from departments that see regulatory teams traditionally as the “department of saying no” leaves ample room for human error in regulatory, quality management, and even marketing processes and activities. Read more about why we believe regulatory teams need to be considered revenue functions, not cost centers.
The resulting inefficiencies lead to problems such as marketing products with expired certificates, missing certificates, inaccurate and/or incomplete submissions, and even non-compliance with current regulatory requirements. Having a holistic RIM system is central to staying in compliance with standards, regulations, and guidance in the many markets around the world. Rimsys is the only RIM system of its kind built specifically for the medtech industry.
To learn how Rimsys can help your company get its regulatory ducks in a row, click here to schedule a demo.
