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.
SaaS 101 for medtech regulatory professionals
What is Software as a Service (SaaS)?
SaaS, or Software as a Service, is a software delivery model in which applications are hosted by software vendors and provided to users via the internet. The use of SaaS software has skyrocketed in recent years, with an estimated 70% of business software being used falling into the SaaS category 2022.
Also known as a “cloud” delivery model, SaaS solution providers either host the application and related data using their own servers and computing resources or use a cloud service provider, such as Amazon Web Services (AWS) or Microsoft Azure, to host the application in the provider's data center. The hosted application is then accessible to any device with a network connection and is usually accessed via a web browser.
Many SaaS software systems use a multi-tenant architecture in which a single instance of the software serves many subscribers, or users. Customer data, while stored centrally, is logically separated to ensure security and prevent co-mingling of data. However, for software systems that require validation, such as regulatory information management systems, a single-tenant system can offer greater data security along with the flexibility for teams to fully validate software releases before adopting them.
What are the benefits of Saas?
- Reduced hardware costs – SaaS removes the need to install and maintain software locally, which reduces the cost of servers and related infrastructure.
- Subscription payments – SaaS software is typically billed on a monthly or annual subscription basis. Not only does this allow companies to spread out the cost of the system, but a subscription model also allows for shorter commitment periods vs. a large up-front capital expenditure (CapEx vs OpEx). The SaaS model also holds software providers more accountable than other models given that the user has the option to cancel or not renew a SaaS subscription, leading to higher levels of service and support.
- Scalable usage – SaaS service providers automatically scale the resources needed to support users and can provide additional services or features on demand.
- Seamless software maintenance – SaaS software can be automatically updated with new features and, when necessary, patched with bug fixes. While this simplifies software maintenance from the user’s end, users in the medtech industry should expect to be able to test and validate software updates before they are installed on their system.
- Accessibility – Accessed via the Internet, SaaS solutions are available from almost any device in any location.
- Reliability – Because SaaS solution providers have extensive resources, beyond what any individual company would normally have, SaaS software typically has very high reliability and availability in comparison to in-house systems.
- Security – SaaS solution providers deliver state-of-the-art security and privacy at a level that is difficult for individual companies to maintain.
As a regulatory professional, what questions should I ask a SaaS vendor?
How are software updates managed?
SaaS software providers generally install new features, bug fixes, and other updates automatically. However, medical device regulations, such as the FDA’s 21CFR Part 11 and EU’s MDR, require medtech companies to validate any software that they are using that is integral to their quality system or otherwise might affect the safety or efficacy of the devices which they manufacture.
Therefore, a SaaS company providing solutions to the medtech industry should offer the ability for subscribers to review and validate software updates before they are installed. This is often done by providing a transition period during which the software vendor allows access to the new version of the software and the existing version. In addition, many software providers, such as Rimsys, will turn off new features by default and allow the user to enable the new feature if and when they want to begin using it. Be sure to understand what, if any, updates will be installed without this review period. Some software vendors will push small bug fixes and minor features automatically.
Clients should be notified of any updates in a timely manner and, ideally, have access to a non-production version of the software for testing purposes. Be sure to understand how often updates will become available and how often those updates are expected to trigger a re-validation of the system. While every medtech organization will have their own specific policies on this matter, Rimsys communicates the expected impact on software validation of each new release, and the reasoning behind whether an update will or will not require a new validation.
Do you assist with software validation?
While software validation is ultimately the responsibility of the medtech company using the software, there is a lot that a software vendor can do to assist with this process. The software vendor should be able to provide documentation concerning the design, development, and testing of the systems that they are providing. In addition, some vendors will provide test cases that can be used by your own team to test and validate the software. These test cases significantly reduce the burden on the in-house validation team.
SaaS vendors should also be able to provide medtech companies with their Computer Software Assurance (CSA) plan. In most cases, the FDA and similar regulatory agencies are looking for compliance with a CSA plan in lieu of the more onerous Computer System Validation (CSV) process that was traditionally followed in the past.
How do you handle data security?
This should be an easy question for any SaaS provider to answer. Whether the data is being hosted by a cloud service provider, such as AWS, or by the vendor themselves, there should be a documented data security plan. As part of that plan, the software vendor should be able to demonstrate how data is protected through physical and logical separation within the system and the application of robust encryption to the data both at rest and in transit. Additionally, the vendor should have a well-documented information security management system (ISMS), which can be further evaluated by third parties for adherence to SOC 2 Type 2 and ISO 27001.
What is your uptime SLA?
SaaS providers should provide uptime guarantees in writing, typically within a Service Level Agreement (SLA). The majority of SaaS business software providers will offer uptime guarantees between 95% and 99%. For mission-critical solutions, such as RIM systems, expect guarantees at, or close to, 99%.
What happens to our data if we leave?
Because you are not storing your data locally, be sure to understand what will happen to your data if you choose to terminate your contract with a SaaS solution provider. You should be able to access your data after termination, download data prior to termination, or both. Ask if you will be charged for this.
Can I access and report on all of my data, all of the time?
It is important to know that you will be able to access all of your data at any point in time, especially during an audit or inspection. Can you create reports that reference any and all data fields in the system? Will older data be archived automatically at any point? Are there API’s available to allow other systems to access the data?
What are your fees based on?
SaaS companies can base their fees on a variety of factors, including data usage, number of users, and features used. Be sure to understand all of the factors that may affect your subscription fees now and in the future.
SaaS terms to know
- SLA: An SLA is a “Service Level Agreement,” which serves as the contract defining what the SaaS vendor is providing and what the customer expects to receive. Among other things, the SLA will define uptime guarantees, what counts as downtime, the procedures followed in the case of a data breach, and how termination of the contract is handled.
- Uptime: Uptime is the percentage of time during which the SaaS software is operational and available to subscribers. The specifics of how uptime is measured should be part of the SLA. Downtime is the converse of uptime.
- API: API, or Application Programming Interface, is a set of definitions and protocols provided by software applications to allow data sharing and integration between applications.
- Module: A part of the software platform that is dedicated to a specific function and outcome. SaaS pricing is often organized around the purchase of one or multiple modules.
- Feature: Specific functionality in the software that comes together to achieve an outcome.
Want to learn more about SaaS solutions for regulatory information management? Contact us to schedule a custom demonstration.
Global strategy for Unique Device Identifier (UDI) data
The International Medical Device Regulators Forum (IMDRF) developed a UDI framework for a globally harmonized system for the identification of medical devices. Adopted in principle by regulatory authorities in many countries, the implementation of UDI regulations and supporting databases is at varying stages of implementation across the globe.
UDI Components
Establishing a UDI strategy involves understanding requirements for both labeling and regulatory database reporting in each country in which your devices will be marketed.
UDI labeling
The UDI is typically presented as a barcode label on device packaging or the device itself (depending on specific requirements). The UDI consists of two major components:
- UDI-DI - This is the static portion of the UDI which identifies the manufacturer along with the specific device version. The UDI-DI (device identifier) is assigned by an approved organization, such as GS1, and contains a company prefix and the manufacturer's internal product code. The UDI-DI is the primary identifier to be used in looking up device attributes in country-specific databases and is assigned prior to placing a product on the market.
As GS1 is widely recognized as an issuing agency across global regulators and industry, the UDI-DI is often referred to in the GS1 nomenclature of Global Trade Item Number (GTIN). - UDI-PI - This is the dynamic portion of the UDI which is assigned by the manufacturer and identifies a manufacturer’s lot number, serial number, manufacturing date, expiration date, or other data as required. The UDI-PI actual values do not appear in country-specific UDI databases, but these databases often require information about the type of data that the UDI-PI represents on the device label.
UDI regulatory database requirements
Many countries have established, or are in the process of establishing, databases to store UDI data. In the United States, use of the Global Unique Device Identification Database (GUDID) is mandated for medical devices. In the EU, EUDAMED consists of multiple modules with one specifically established for UDI. The UDI module is currently available for voluntary use, with mandated compliance scaled in transitional periods through 2026.
Currently, the US GUDID database provides for machine-to-machine (M2M) transmission of data, allowing manufacturers to upload product UDI data directly into the database. The EU has established requirements for M2M transmission as well, but these requirements are not finalized. Most other countries do not have M2M capabilities at this time.
Universal UDI ®
While each country defines specific UDI data requirements, there is a core set of data that is consistent across many markets. At Rimsys, we refer to this data as the Universal UDI® data. Storing Universal UDI® data separately from any country-specific UDI data is an important data management strategy. This ensures that data is single-sourced and consistently applied across submissions to regulatory UDI databases and in other locations in the manufacturers’ quality management system where the data may be needed.
When storing UDI data locally, consider that the same information may be required in different formats in different country regulatory databases. Currently, Rimsys supports the specific data requirements of the US, EU, Saudi Arabia, China, South Korea, and Singapore. Additional countries, which are expected to have similar IMDRF style requirements, will be added as those databases are established by regulators and brought to the industry. Some examples of these countries are Australia, Switzerland, UK, Brazil, and India.
Note that outside of the US’s GUDID, UDI databases are in flux in most countries. This means that having a central RIM system to track known and well-established UDI data is increasingly important.
Machine to machine transmission of UDI data
Machine to machine (M2M) transmission is the process in which data is transmitted from a company’s internal database, typically a RIM or PIM/PLM system, to the regulatory UDI database. Currently, the GUDID database in the US is the only database for which machine to machine (M2M) transmission has been fully developed and is fully supported. Rimsys offers M2M data transmission for GUDID and is currently working to establish M2M transmission with EUDAMED.
Synchronizing UDI data
It is important to note that there are really no requirements for a medical device manufacturer to keep a quality record of the UDI data submitted to regulatory databases (the official data of record is the data that has been reported to and is retrievable from the regulatory database). This means that it is up to the manufacturer to declare the actual source of data for the quality system and to ensure that data is in sync where required.
One of the strategies that can be used when implementing a new RIM system, such as Rimsys, is to export data from GUDID, EUDAMED, and other regulatory UDI databases. That data then forms the basis for the UDI data that is input into the RIM system, ensuring consistency in the application of data across other countries’ UDI databases.
Maintaining and updating submitted UDI data
It is important to implement procedures to ensure data in a product’s UDI record is consistently applied throughout your internal systems as well as with the various regulatory databases. While a single data point should be stored in as few places as possible, everything should be done to minimize the chances that data will get out of sync.
Any product data changes must be evaluated for, among other things, the effect on existing UDI data submissions to regulators. The data changes must be evaluated to determine if the UDI-relevant data can be updated in impacted regulatory databases or if an entirely new UDI-DI and record must be reported. In some cases, such as a change to the product’s catalog number or contact phone number, an existing UDI record may simply need an update. In other cases, such as a change to the sterilization requirements, a new UDI-DI and a new record may be required.
EUDAMED considerations
The EUDAMED database and M2M requirements for UDI are still not finalized, but they are much more static than they were even a month or two ago. We believe that it is beneficial for medical device manufacturers to establish and organize the data needed to submit their products to EUDAMED as soon as possible.
Legacy devices are those medical devices and In Vitro Diagnostic (IVD) devices that are compliant to previous directives (MDD, AIMDD, IVDD) that are being placed on the EU market under the allowed transitional period. With the compulsory application of EUDAMED identified in the 2026 timeframe and the expiry of the transitional period in 2024, there was no need for manufacturers to register legacy devices in the EUDAMED system. Today, with the extension of the transitional period for the certification of devices under MDR and IVDR through 2027, legacy devices may now again be subject to submission of UDI data in EUDAMED.
There will be a 24-month transition period for manufacturers to apply UDI data to EUDAMED once all modules go live. However, if you have any type of action requiring interaction with the Vigilance module of EUDAMED, the required UDI information for those devices must be present in EUDAMED prior to that interaction. The Vigilance module is intended to manage all types of vigilance reports, including Manufacturer’s Incident Reports (MIR) and Field Safety Corrective Action (FSCA) reporting. This also includes and requires post market surveillance reporting submission to the Vigilance module such as Periodic Safety Update Reports (PSUR) and Post Market Surveillance Reports (PMSR).
Manufacturers may be surprised with a shortened transitional period for compliance to EUDAMED’s UDI module due to this requirement and should place priority on higher-risk devices due to the increased likelihood of an interaction with EUDAMED’s Vigilance Module.
For additional resources, watch a replay of our webinar, Why UDI is a regulatory concern, not just an operation process - or read our eBooks, The Ultimate Guide to EU MDR/IVDR UDI and The China NMPA UDI System.
Educational resources for medtech regulatory affairs professionals
Staying on top of changing regulations and expectations is challenging for MedTech regulatory professionals around the world. The following list is some of the educational resources that are most used by RA teams to stay current. With the exception of RAPS, we focused primarily on resources provided by regulatory agencies directly. Rimsys does not endorse or validate information on these sites.
Professional Organizations
Regulatory professional organizations provide a combination of free and paid training courses and certifications.
RAPS
The Regulatory Affairs Professionals Society (RAPS) is the first stop for most regulatory professionals looking for education and certification:
- Courses (open to non-members) - includes RAC exam prep, online courses, webinar replays, and training bundles
- Learning portal (RAPS members only)
- Connect RAPS (RAPS members only forum)
TOPRA
TOPRA is a professional membership organization for individuals working in healthcare regulatory affairs. TOPRA was founded in the United Kingdom and is active in Europe.
Regulatory Agencies
United States (FDA)
The FDA offers a variety of free educational resources, including live and on-demand webinars, along with written documentation:
- Training and Continuous Education home page
- Continuing education programs
- CDRH Learn
- Guidance Webinars
EU Medical Devices Sector
- Event list (including educational webinars)
- Publications (including step-by-step guides)
- EUDAMED information center
Canada
- e-Learning courses on how medical devices are regulated in Canada
Singapore
While these are not training modules, the following free “tools” are available from the Singapore Health Sciences Authority:
- Is it a medical device?
Answer a series of questions to determine if your device is considered a medical device in Singapore. - Risk classification tool
Answer a series of questions to determine the risk classification of your medical device. - Registration and licensing requirements
Answer a series of questions to determine the correct registration route. - Medical device grouping tool
Answer a series of questions to determine if you can group your medical devices together for registration.
Additional third-party resources
Some sites that we find particularly useful. Note that Rimsys has no business relationship with these sites.
Paid Resources
Notified Bodies and other large consulting firms can provide detailed training options, but these organizations are in the business of providing expert consulting and education, so these options are not free. Those listed here provide individual, self-service, training courses that are charged per-session:
If you have any additional resources that you think we should include here, please connect with us on LinkedIn or Twitter!
FDA predicate devices
Medical device manufacturers seeking to place a new device in the U.S. market through a 510(k) submission are required to identify a legally marketed device that is substantially equivalent to the new device – i.e.: the predicate device. Selecting the correct predicate device is extremely important in ensuring the success of your 510(k) submission. New devices without a predicate are automatically classified as Class III devices requiring a premarket authorization (PMA) submission (although those with a lower risk profile can apply for reclassification through a De Novo request).
Predicate device requirements
A predicate device is used in a 510(k) submission to demonstrate that the new device to be marketed is safe and effective. This is done through establishing substantial equivalence between the predicate device and the new device. The predicate device must be a legally marketed device approved through a 510(k) submission, to which equivalence can be demonstrated. In identifying a predicate device, preference should be given to devices which are currently marketed in the U.S. and which have received 510(k) clearance relatively recently.
Predicate devices may be:
- Postamendments devices – devices marketed after May 28, 1976. The majority of 510(k) submissions claim substantial equivalence to a postamendment device.
- Preamendments devices – devices which were legally marketed in the U.S. before May 28, 1976 and which have NOT been significantly modified and for which a regulation requiring a PMA application has not been published by the FDA.
- Either postamendment or preamendment devices which are no longer marketed in the U.S. In this case, the predicate device cannot be a device that is, or was, in violation of the FD&C act.
Substantial equivalence
A medical device is considered substantially equivalent to an identified predicate device if the devices share an intended use and meet either one of the following:
- Shared technological characteristics, OR
- Different technological characteristics that do not raise different questions of safety and effectiveness and the safety and effectiveness of the device is demonstrated by information submitted to the FDA.
It is also important that the predicate device selected does not use outdated or superseded technology, which means that newer devices tend to be used as predicate devices. Note that while substantial equivalence needs to be demonstrated, the devices do not need to be identical. However, if the FDA finds that substantial equivalence has not been demonstrated with the identified predicate device, the applicant may:
- Resubmit the 510(k) with new data
- Request a Class I or Class II designation through the De Novo classification process
- File a reclassification petition
- Submit a premarket approval application (PMA)
How to find a predicate device
The FDA provides a 510(k) database containing all devices cleared through the 510(k) process. This database is updated monthly and can be filtered by device class, product code, applicant name, and other information.
Before searching the 510(k) database, the device and product classifications should be determined. The best way to find the correct classification of a new device is to use the Product Classification database, which can be filtered by device name and review panel, along with submission type, product code, device class and more. Searching the 510(k) database with the correct 3-letter product code is typically the most effective way of finding potential predicate devices.
Using a reference device in a 510(k) submission
The identification of a “reference device,” in addition to a primary predicate device, can be used to “support scientific methodology or standard reference values.” A reference device cannot be used in lieu of a primary predicate device and the FDA will evaluate the appropriateness of the reference device.
Note that prior to a 2014 guidance, the FDA allowed for “split predicates,” or the use of one predicate device to demonstrate equivalence in intended use, and another to demonstrate equivalence in technological characteristics. The current guidance finds the use of split predicates "inconsistent with the 510(k) regulatory standard.”
The importance of selecting the right predicate device
Selecting the right predicate device is critical to ensuring that your device can be brought to market through the 510(k) pathway. Selecting the wrong device will result in delays to the regulatory approval process. If an applicable device with current technology cannot be identified, other pathways, including De Novo request and PMA submissions, should be considered. For additional information, read The Beginner's Guide to the FDA 510(k).
Medical device audits - preparation and responses
The word “audit” can strike panic in poorly prepared medtech companies. However, audits serve an important purpose in ensuring a compliant and effective quality system and production of safe and effective medical devices. And organizations can limit the stress and risk around audits through proper preparation.
The key to a positive audit is to ensure that your organization’s focus is on building and implementing quality processes and procedures that cover the entire product life cycle and are continuously evaluated and improved upon. Not only is it the right thing to do, but focusing too closely on simply passing an inspection or audit may leave gaps in your processes and present a false sense of compliance. This article covers audit basics, how to prepare for them, and what to do when you receive an audit finding.
What is an audit?
Per ISO 19011 an audit is a systematic documented and independent process for obtaining objective evidence and evaluating it objectively to determine the extent to which the audit criteria are fulfilled. Audits can be internally conducted, externally conducted by interested parties (i.e., customers/ suppliers), and externally conducted by government agencies and notified bodies to ensure that product design, manufacturing, safety, and documentation requirements are being met. Audits will verify compliance with regulatory and quality system/GxP (Good Manufacturing Practices, Good Distribution Practices, etc.) requirements. GxP standards are dictated by the US FDA, European Medicines Agency (EMA), the UK Medicines and Healthcare Products Regulatory Agency (MHRA), and other regulatory bodies which rely on country-specific regulations as well as standards developed by the International Organization for Standardization (ISO).
Audits are required regardless of device class, but audit requirements in the EU and US, along with most other markets, can be dependent on the device classification. For most medium to high-risk devices in the US and EU, the following audits take place:
- Audits by EU Notified Bodies: Audits by EU Notified Bodies focus on compliance with MDR 2017/745 or IVDR 2017/746. Notified Bodies are also responsible for certifying quality management systems (QSR) against the requirements of ISO 13485:2016. Periodic “surveillance audits” will also be performed, based on the classification of the medical device(s).
- FDA Inspections: The FDA will conduct inspections to ensure compliance with the quality system regulation, 21 CFR 820, and to confirm that a facility is capable of manufacturing the medical device. The FDA will conduct pre-approval inspections to verify data included in a market submission, along with periodic routine inspections, following the Quality System Inspection Technique (QSIT) as required by regulation (currently every two years for Class II and Class III USA-based device manufacturers and every five years for international device manufacturers).
- Unannounced and “for cause” inspections: Manufacturers in the US and EU, and many other markets, are subject to different types of inspections triggered by consumer complaints, reported non-conformities, or other issues. These “for cause” inspections may be scheduled or unannounced.
How to prepare for an inspection
Audit preparation is a continuous process that should be built into your quality system and regulatory processes. Some items to consider:
Internal Quality audits
The best way to prepare for an upcoming audit or inspection is to use the internal audit program to your benefit. The FDA QSR, FDA 21 CFR 820, calls for medical device manufacturers to perform regular internal audits of their systems and to provide evidence of these audits and their effectiveness. When possible, conduct internal audits as if you’re the regulatory body and take them seriously. Internal audits should find the issues before the regulators do. Issue nonconformances and address them in a timely manner.
Performing “mock” audits is another great way to prepare for external inspections/audits from the FDA, notified bodies, and other regulatory authorities. Mock audits are a rehearsal for your team to prepare them for the real thing. They can act as try-outs to determine who is equipped to handle being audited and those that are too nervous or offer too much information when asked a question, requiring additional training. Mock audits are typically separate from the internal audit program since they are conducted based on different objectives and for training purposes.
It’s common to contract an independent third party to perform mock audits. Consider conducting unannounced mock audits to get the truest picture of your company’s preparedness. In short, the tougher medical device manufacturers are on themselves while preparing for the audit, then the less stressful the actual audit will be.
Self-identify issues as they appear and do not wait for the internal audit. If an issue is identified during the audit preparation or mock audit, implement corrective and preventive actions (CAPA) to address the issue. This is vital to demonstrate that you are aware of an issue and have begun remediation or corrective actions if and when those issues are uncovered during the real inspection or audit.
Choose the right audit host
When you have an upcoming audit or inspection, you must choose the right company representative to host the auditor(s). The person you choose will represent your company, so be deliberate about selecting those who know the company, its quality management system, and its products well. It should also be someone you’re confident can perform well under pressure and remain mission-focused in managing the audit and not necessarily answering every question immediately. The audit host can significantly impact the audit for the better or worse, so be certain that you have the right person in place who will be able to represent the organization’s values and facilitate an efficient audit.
While the person or people working directly with the auditor(s) are often from your quality team, they will need to be supported by subject matter experts (SMEs) from other functions for the duration of the audit – this will include the regulatory, engineering, operations, and marketing teams – who can answer specific questions and gather requested documents. These SMEs must be pre-identified along with alternates as part of the audit preparation. They should be comfortable facing an auditor and answering the auditor’s questions.
Gather all the necessary documents
As part of the audit process, the auditor(s) will expect access to information that they need to determine your organization’s compliance with all quality system and regulatory requirements. Based on the requirements, audit guidance, and previous audits, commonly requested documents should be known. This documentation should be pre-identified, compliant, and available before the start of an audit. This can be in the form of hard copies or electronically through files or links. The goal is to have documents readily available to avoid audit delays.
"If it takes too long to get documents to the auditor when they ask for them, you’re not making a good overall impression that everything is under control, making things more difficult for the auditor(s). Auditors have schedules to meet and follow certain audit trails. The last thing you want is your auditor getting agitated because they are spending a lot of time waiting for information." - Bruce McKean, Rimsys Director of Regulatory Affairs
It is critical that all regulatory information related to your products is readily available during an audit, such as registration status, certificates, regulatory impact assessments, and essential principles, along with submission content and post-market data. A central RIM system that stores all regulatory data and links to (or references) the current versions of records from other systems, such as PLM, eQMS, and ERP systems, can smooth the audit process significantly.
During an audit
As an organization, you will want to manage as much of the audit process as possible. Your audit host will greet the auditor(s) and give them a brief overview or presentation of your company, and most likely conduct a facility tour. After this, while the auditor(s) will direct the process, the more your host can assist and guide them, the better.
In the case of unannounced inspections/audits, there must be a procedure in place that defines how to receive and handle these types of audits. This will include who is the primary contact during such an inspection (often a Quality Management team member or representative), as well as Executive Management, and alternates when those people are not available.
Ideally, you should have more than one company representative with the auditor(s) during the audit and auditors should not be left alone at any point. Most companies have a team in the “front room” with the auditor(s) led by the audit host. The main job of this team is to transcribe every question, answer, and activity that occurs during the audit. The “front room” team will communicate with other team members in the “back room” in real-time (often via instant messaging), relaying to them any open questions, requested documents, or queuing up SMEs the auditor(s) need to speak with.
Best practices for sharing information with auditors
During an audit, employees should be cooperative and helpful, but should only share information that is specifically requested by the auditor. If information is requested that seems outside the scope of the audit, such as corporate strategic or financial documents, employees should notify the appropriate executive before providing such information.
Auditor(s) should be given access to requested information through photocopies or limited computer system access. Original documents can be presented if requested, but should never be kept by the auditor(s). All information provided should be prepared, verified, and recorded in the “back room” and then passed through to the audit host so that it can be controlled. The “back room” should mark the copies “Confidential” or “Proprietary,” as appropriate. They should also make an extra copy for the audit file, so the exact documentation given to the auditor(s) is known for future reference.
Addressing missing or incorrect information
Ideally, any potential issues with the existing quality system and related procedures are identified before an audit and corrective actions are identified and put in place. Even in cases where an issue has not been fully resolved, being able to point to awareness and appropriate actions is important.
Some findings may be able to be corrected during the audit. These findings are typically isolated issues (one-offs) that do not pose significant risks. For instance, a missing revision number, missing signature, or outdated reference. If corrected during the audit, it may negate a finding, but the auditor may want to understand why the issue occurred and what actions you have or will be, taking to ensure that it does not recur.
In cases where you are unable to produce the information requested by an auditor, or when there are questions about the validity or accuracy of the information, your internal team should acknowledge the issue but should not immediately speculate on the cause or the effect of the missing or inaccurate information. A discussion of appropriate actions under the existing quality system may be appropriate.
What to do in case of a finding
Be prepared to receive findings from any inspection. Ideally, the auditors should be working to ensure that you are compliant with regulatory requirements and that your records accurately state what you do. However, “By the nature of the beast,” says Bruce McKean, “they’re there to find instances of noncompliance.” This means that auditors will be focused on documentation that can prove or disprove adherence to your stated procedures and policies.
All findings should be disclosed before the audit closing meeting. There should be no surprises. Ensure that the findings are understood by both parties. If they are not clear, perhaps the auditor misunderstood or did not see specific objective evidence and you should discuss or review the issue with the auditor as this may negate a finding. Be sure to debrief upper management before the closing meeting. At the audit closing meeting, there should be no debate over findings. Any finding, whether major or minor, should be addressed diligently.
Audit findings or observations will result in the regulatory body in charge of the audit issuing a document that lists those findings. In most cases, you will have limited time to respond with a satisfactory plan for correcting and preventing the recurrence of the identified issues.
In the case of the FDA, multiple enforcement actions are available to the agency, ranging from warning letters to criminal prosecution. Note that many regulatory agencies will not respond further to your actions if they agree with the actions you prescribe for addressing audit observations. However, additional actions may be triggered if your response is not found to be satisfactory.
Rimsys is a holistic regulatory information management system designed for and by regulatory affairs professionals. Rimsys makes it easier to create and track submissions, keep up with product registrations and certificates, and even share pertinent data across ERP, PLM, and eQMS software platforms to ensure data integrity. Learn more about how Rimsys can help you face audits with the confidence that you have all of your regulatory ducks in a row.
Australian Essential Principles
The Therapeutic Goods Administration (TGA), under the Australian Department of Health and Aged Care, is responsible for evaluating, assessing, and monitoring products that are defined as therapeutic goods. They regulate medicines, medical devices, and biologicals to help Australians stay healthy and safe.
Manufacturers are responsible for generating, collating, assessing, and maintaining scientific and engineering evidence that shows that their devices comply with the Essential Principles. The evidence must be relevant to the device's intended purpose and must be objective, sufficient, and robust. Manufacturers manage this by having a solid, quality management system (QMS).
An ‘Essential Principle’ is fulfilled during the design and manufacturing of medical devices and IVD medical devices, to ensure that they are safe and perform as intended. A global adoption of a common set of fundamental ‘essential’ design and manufacturing requirements for medical devices provides significant benefits to, among others, manufacturers, users, patients/consumers, and to regulatory authorities. From a high-level perspective, three basic points make up ‘Essential Principles’:
- A device must be designed to be safe and perform effectively throughout its lifecycle.
- Device manufacturers must maintain all design characteristics.
- A device must be used in a way that is consistent with how it was designed.
Many countries use the term ‘Essential Principles’ (EP's) in regulations and guidance documents. ‘Essential Requirements’ is the terminology used in the EU MDD 93/42/EEC and AIMD 90/385/EEC. With the release of the MDR/IVDR, they are now referred to as GSPR's (general safety and performance requirements). Regardless of the terms used, Essential Principles are of similar nature and overlap many of the Essential Requirements in the new GSPRs.
Demonstrating Compliance
It is the manufacturer’s responsibility to demonstrate that their medical device is compliant. The TGA’s regulatory process does not necessarily dictate “how” a manufacturer must demonstrate compliance with the Essential Principles. However, there is a range of data points that are suggested to be used as objective evidence to show that your device complies with the Essential Principles. Listed below are some examples of the data you would want to track and list in your Essential Principles documentation, commonly referred to as The Essential Principles Checklist or GSPR’s.
Details of design and construction:
- a general description of the medical device and its intended purpose
- specifications, protocols, procedures, and details of design and development methods, and technologies used for manufacturing, packaging, storage, handling and distribution
- procedures for measuring and monitoring the safety, performance, and quality of your device
- procedures for servicing (if appropriate)
- procedures for assuring your medical device is sterile (if appropriate)
Risk management reports:
- risk analysis
- risk evaluation
- identification of residual risks
- controls of known and foreseeable risks
Demonstrate compliance with relevant, generally acknowledged state-of-the-art and best-practices:
- technical standards, guidelines, or other validated methods
- codes of practice
- monographs
Characterization studies:
- Verification and validation activities, including protocols, testing and analysis.
- Records of qualitative or quantitative information obtained through observations, measurements, and tests.
Clinical evidence:
- literature reviews that include information about the hazards and associated risks from the use and potential misuse of the device.
- information about the performance of the devices you are manufacturing, including a description of the techniques used to examine whether devices of that kind achieve their intended purpose or not.
- Collation and analysis of post-market data including complaints, adverse-event reports, vigilance reports, registry data and recalls/field corrections/advisory notices.
Additional information:
- Copies of labels, packaging, patient information, and instructions for use.
- Critical evaluation written report, by an expert in the relevant field, of data (including outcomes from literature reviews) about your device.
Essential Principles checklist
The checklist is a form template that the TGA created for medical device manufacturers. It lists all the necessary requirements that must be met, as part of the technical file, to demonstrate regulatory compliance. It’s structured in a table format with each general principle clearly stated with instructions on how to complete the form (Fig 1).
The TGA follows the guidelines of the International Medical Device Regulators Forum (IMDRF). They were one of the founding members to take part in the IMDRF that was established in 2011, building off the groundwork of the Global Harmonization Task Force (GHTF). Today there are 11 countries that participate in accelerating international medical device regulatory harmonization. This group of regulators provide input to policies, offer guidance on strategies, create clear directions - all in an effort to help build a strong foundation for the safety of the medical device industry.
For additional information on Australian medical device regulations and links to resources, see our Australia Regulatory Market Profile. For information on the use of essential principles in the EU, see The ultimate guide to the EU MDR and IVDR general safety and performance requirements (GSPR).
