
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.
Ask us Anything ... about UDI!
Your UDI questions answered
Our first “Ask us Anything” webinar last week focused on the topic of Unique Device Identification (UDI). We had so many great questions that we couldn’t answer them all during the session! We have picked the most common questions and put them together here with the answers from our expert panel.
For additional information on this topic, see the following resources:
- Quick reference guide - global medical device UDI requirements and timelines
- BUDI-DI - Basic UDI explained
- The ultimate guide to the EU MDR/IVDR unique device identifier (UDI) system
- Watch a replay of the Ask us Anything about UDI webinar!
Q: I’ve heard that the EUDAMED timeline has been pushed back. Is that true?
Yes, that is true. The European Commission recently pushed back EUDAMED deadlines by one year. It is important to note that this does not affect UDI labeling requirements and timeframes, only the mandatory entry of UDI data attributes into EUDAMED (now Q2 2026). The industry should not relax their efforts in regards to collecting and submitting UDI data. We make every effort to keep our Quick reference guide: global UDI requirements and timelines up-to-date and deadlines and regulations change.
Q: Are we expecting the FDA to be actively enforcing UDI regulations against class I manufacturers after September 2022?
Following this session, the FDA announced that they do not intend to enforce GUDID submission requirements for class I and unclassified devices, other than implantable, life-supporting, or life-sustaining devices.
Q. What governing body controls the correctness of GUDID data?
While the manufacturer is responsible for the accuracy of data they input into GUDID, the FDA is the agency that oversees the requirements.
Q: I have a UDI for a software device (SaMD) that includes features that will be included in a clinical study and features that will be part of the commercialized release version. Do I need to have separate UDIs or can I add the IDE label under a single UDI for the clinical version and keep the UDI for the market released version?
To fully answer this question, we might need a little more information. However, if the device involved in the clinical study is not released (i.e. marketed), then it would not require a UDI. If additional features are introduced during the clinical trial and a new product is released as a result, then a new UDI would be required.
Q: Can you provide insight into machine-to-machine transmission of UDI information?
Currently, the U.S. UDI database, GUDID, has the capability to accept machine-to-machine data transmission. More information can be found on the FDA website here. Most other major markets are working on providing this capability.
Q: How do I make a UDI implementation plan for the QMS process? What things need to be covered?
This is a broad question and there could be many different answers based on your product, QMS, and company structure. Generally speaking:
- UDI should be integrated within your Design Controls/Development processes, including the company product release process. You cannot market your device into a country without complying with their UDI requirements. Some countries require UDI information as part of the device registration process (e.g., EU and China).
- The company needs to establish accounts with the Issuing Agency (e.g., GS1) and with the country UDI databases (e.g., U.S. FDA GUDID)
Main things to consider:
- Labeling: Barcoding software and a process for creating the labeling
- Product UDI data attributes: All product related characteristics that are required to be recoded in the country UDI database. The specific characteristics/attributes can be found in the various country UDI guidance documents.
- Define methods for capturing, storing, controlling, transmitting data attributes (e.g., a RIM system, PLM system or both).
- Establish processes for maintaining the data including the country requirements (timeframes) for updates to the UDI data and periodic audits (reference country UDI guidance documents).
Q: How do I know what UDI information needs to be supplied to regulators?
The FDA regulations and data dictionary are mature and include information and required data fields to complete successful transmission of data. Data field details include information on whether data is required or conditional on other data, lists of standardized values, and guidance on the data that is expected for each field. EUDAMED has taken a similar approach, and also includes information that is expected for BUDI. The EUDAMED data dictionary is still in flux. We expect a similar approach from other countries.
Q: When you are implementing UDI and have a kit or system pack, do you need to have a separate UDI for the device, accessories for that device, and a separate UDI for the kit (which would have those components)?
Generally, the UDI is assigned at the lowest sellable product level. In the case of kits, procedure packs, or systems - each would be given a unique UDI as well.
Q: Is the GUDID barcode and the UDI barcode on the product label the same?
There is no GUDID barcode, but the information on the UDI barcode is contained within the GUDID database. The barcode or human-readable numbers provide high level information about the device. They act as an access key to all of the device attribute data within the GUDID database. The expected barcode on the product is the full UDI including the device identifier (DI) and the production identifier (PI). The GUDID is the FDAs regulatory database where labelers are required to submit information about the UDI DI.
Oh No! How to recover lost medical device certificates
Imagine that you have started working in a new position at a medtech company, and you’re trying to organize your current knowledge of the products, registrations, and information now under your charge. However, something feels off, and you realize that you cannot find all of your company’s current medical device certificates.
Lost medical device certificates are a more frequent occurrence in our industry. In fact, it’s my experience with the frustration of recovering lost medical device certificates that finds me writing this brief post about what it’s like to lose a medical device certificate and the strategies I’ve used to recover the lost information. We’ll even discuss what you can do to prevent having to live “The Tales of the Lost Document” in the future.
How do certificates get lost?
The most common factor in misplaced or lost certificates is human error stemming from lax filing systems with disjointed practices and team member departures. Many large medtech companies have a complex structure of emails and document storage sites (such as Sharepoint or Dropbox). These storage sites are often siloed, with different regulatory teams having varying excel spreadsheets, folder structures, and naming conventions to organize their regulatory submission workload.
In many companies, managing global medical device certificate information is a manual and burdensome process. The problem could be as simple as a file-naming mixup, or it could be a document your company hasn’t needed the certificate in so long that they simply lost track of it. Now let's talk about ways you can recover your lost certificates or information that’s missing from them.
How can you recover lost certificates?
The good news is that you can recover your lost documents in many cases, though it may take a bit of legwork. There are two primary strategies for finding lost medical device certificate information, and utilizing both is the best way to ensure you recover your lost certificates and information.
The first and often most successful pathway is to search through your internal resources.
Strategies for Searching through internal resources:
- Have you found every Sharepoint site used in the past five years?
- Have you checked previously recorded submissions of that medical device?
- Have you contacted IT to see if they can recover emails from a departed colleague? They might have sent emails with the certificate attached to them. Many regulatory professionals email a copy of the certificate to announce to the marketing teams they can begin product sales.
- Are you working with a distributor? Contact them and request knowledge on all of the current medical device certificates.
Other channels are available if you can’t find what you’re looking for in your company’s local storage.
The second strategy is to use governmental medical device registration databases. For example, if you’re registration information for a class 2 medical device, you could look it up in the FDA 510(k) database. Here are some examples of the international regulatory databases that may help in your situation:
United States - FDA
Canada - Health Canada
European Union
Australia
Belgium
Brazil - ANVISA
Singapore - Health Sciences Authority
Saudi Arabia - SFDA
If you are looking for a certificate that was approved by a notified body and not in a current database, you can contact the notified body, but you should expect to pay a fee for their services. It’s also important to note that not all countries and regulatory bodies have a database that allows companies to look up their certificates.
You may also have to accept that you can’t recover your medical device certificate or information. Not every country has a medical device database, and even those with a database often don’t contain the certificate itself. That’s why it’s critical to the efficacy of your RA operations that your team has the tools necessary to store, track, and share regulatory information and documents securely and efficiently.
How do you make sure this never happens again?
We understand that trying to find missing certificates is an administratively heavy burden. When you can’t find a certificate or its missing information, there’s no way to tell whether it’s lost forever until you’ve exhausted all possibilities and channels, which is why it’s much better to prevent losing documents altogether.
With the right tools, your RA team can store, locate, and share documents in a secure and largely automated environment. That means no more awkward conversations where you have to tell your boss you can’t find the expiring certificate for your company’s flagship medical device.
Rimsys is regulatory information management (RIM) software created by RA professionals from the medtech industry with RA professionals in mind. It empowers RA teams to store and track all certificates by product and country and even provides a portal where you can see all of your regulatory documents in a centralized view. Furthermore, you’ll receive emails when a certificate is about to expire, allowing you to act in ample time to prevent lapses in compliance and continue market access per your company’s global device strategy.
Learn more about how a RIM system can help your organization keep track of all its regulatory information in our “RIM Buyer’s Guide.”
Class III medical devices in the United States
What is a Class III medical device?
There are three classes of medical devices in the United States, all regulated by the Food and Drug Administration (FDA). Class III devices have the highest risk profile and therefore have the most significant regulatory requirements. In the United States, a Class III device is also a device that has no substantial equivalence to an existing Class I or II device. This means that if there is no device with similar intended use and indications for use, or if the device is using novel technology, it will be classified as Class III by default. To find substantially equivalent devices, use the FDA’s product classification database. Because medical device classification in the U.S. also depends on risk level, there are exceptions for novel devices with lower risk profiles (see De Novo classification process).
Examples of Class III medical devices
Class III devices “usually sustain or support life, are implanted, or present potential unreasonable risk of illness or injury.” Only 10% of medical devices marketed in the U.S. fall under this category.
Examples of Class III devices include:
- Pacemakers
- Implanted prosthetics
- Cochlear implants
- Defibrillators
- Software defined as a medical device (Software as a Medical Device or SaMD), which meets the risk profile of a Class III device. This may include diagnostic software that is using imaging to identify conditions that, if misdiagnosed, would pose a risk to the patients health or life.
FDA regulatory approval process for Class III medical devices
Almost all Class III medical devices in the United States require premarket approval (PMA) from the FDA before being marketed. Due to the high risk profile of Class III devices, the PMA process requires significant data to demonstrate the safety and efficacy of the device. Unlike Class II devices which require a 510(k) premarket notification, the PMA process requires a thorough review by the FDA that results in their approval of the product for entry into the U.S. market.
The PMA process is defined in Title 21 Code of Federal Regulations (CFR) Part 814 and a full overview of the process is included in our Beginner’s Guide to the FDA PMA Submission Process. A PMA will almost always require:
- Substantial clinical trial data.
- A fully documented quality system compliant with design controls as defined in 21CFR Part 820.
- Documented conformance to recognized consensus standards.
- Detailed descriptions of the device and all of its components.
- Product samples and/or the ability for the FDA to examine the device on-site.
Note that there are exceptions to PMA requirements, most notably the humanitarian device exemption, designed to encourage investment in devices that would serve a small population. See the FDA’s Acceptance and Filing Reviews for Premarket Approval Applications (PMAs) for more information.
Post-market compliance for Class III medical devices
Medical device manufacturers and distributors must also conform with specific requirements once a product is being sold in the market. These requirements include:
- Mandatory reporting of device issues and adverse events by manufacturers, importers, and device user facilities (such as a hospital) as detailed in the Medical Device Reporting regulation (21 CFR Part 803).
- Tracking systems to support any necessary product recalls as detailed in 21 CFR Part 821.
- Post-approval studies that are required with the approval of a PMA, Humanitarian Device Exemption (HDE), or Product Development Protocol (PDP). Post-approval studies are a condition of approval and are mandatory.
Class III medical devices in other countries
Device classification is different in each country, therefore you should not make any assumptions regarding classification in other countries based on the fact that your device is a Class III device in the United States. Each country with medical device regulations has their own classification scheme that may cause your device to be regulated in a different way. During the initial phase of planning for global commercialization of a product, it is imperative that you consider international regulations, their classification schemes, and the registrations that each country will require.
For additional information on the Class III approval process, read our Beginner’s Guide to the FDA PMA Submission Process.
BUDI-DI - Basic UDI explained
What is BUDI?
By now, you should be familiar with the terminology surrounding UDI - The Unique Device Identification System. The United States FDA, the European Commission, and other regulatory bodies around the world have developed UDI regulations for medical devices and in vitro diagnostic devices that involve both labeling and database registration requirements. In the EU, UDI regulations were introduced under Regulations (EU) MDR 2017/745 and (EU) IVDR 2017/746. There is UDI, UDI-DI, UDI-PI - so then what is a BUDI-DI?
BUDI is an abbreviation for “Basic UDI” and is commonly pronounced “Buddy.” A BUDI-DI is unique to the EU and allows devices with multiple UDI-DI’s to be grouped together. It is necessary whether you have one device group (sometimes referred to as device ‘family’) or have many different device configurations such as systems, procedure packs, or kits. The general rule is there can only be one BUDI-DI to many UDI-DI’s and never multiple BUDI-DI’s to just one UDI-DI. The only time a BUDI-DI is not required is for a custom-made device, which generally doesn’t fall into the UDI requirements of the MDR/IVDR anyway.
A BUDI-DI allows manufacturers to connect and identify device groups with the same intended purpose, risk class, essential design, and manufacturing characteristics. It is an identification number that is only used for administrative purposes. It is required in the EUDAMED database and is referenced in relevant documents such as certificates, declarations of conformity, and technical documentation. If the device requires Notified Body review, then the BUDI-DI should also be listed on the CE Certification and the Certificate of Free Sale.
A BUDI-DI is the key that unlocks the EUDAMED and provides access to all of the product information.
- It’s the primary identifier of the device group/family
- It’s the main record key in the EUDAMED
- It’s the main product identifier in the regulatory documentation
- It’s independent of packaging and labeling
UDI issuing agencies
The manufacturer is legally responsible for utilizing a human-readable BUDI-DI assigned by an approved UDI issuing agency, such as HIBCC or GS1. The format of the BUDI-DI will vary slightly depending upon which issuing agency you work with. Currently, the only approved issuing agencies in Europe are GS1, HIBBC, ICCBBA, and IFA.
Per the MDCG 2019-1 guideline, each agency must:
- Create a code format that is close to the existing UDI-DI format
- Use no more than 25 total characters
- Assign a check/digit character that was determined by an algorithm
A BUDI-DI cannot be changed. A product UDI-DI created because of a new product variation or changes to the UDI-DI data elements can report into an existing BUDI-DI.

The EU provides an EU UDI Helpdesk to assist with navigating UDI requirements and answering questions device manufacturers may have.
Note that EUDAMED registrations, including BUDI-DI numbers, are currently recommended but not required. Use of the EUDAMED databases will not become required until all six databases are live, which is expected to be in Q2 of 2023, with a 24-month transition period.
Read our Quick reference guide - global medical device UDI requirements and timelines for additional information on general UDI requirements.
RIM Readiness: What your medtech company needs before implementing a regulatory information management system
Regulatory Information Management (RIM) systems provide a single platform for regulatory teams to manage submission and compliance data, reducing administrative overhead and increasing confidence in a company’s global regulatory data. RIM systems can digitize and automate a broad set of regulatory activities from new product submissions, to registration and standards management, to UDI data management. These capabilities can significantly improve RA efficiency and effectiveness - reducing workload for new releases by over 80% and maintenance time for technical files more than 90%. However, not all organizations can realize results like these immediately. When deciding to implement a RIM system, medical device companies need to consider many factors and ensure that they have the needed systems, processes, and personnel in place.
Technology requirements
RIM systems are fundamentally about data. They first and foremost provide a system to collect (either directly within the system or through integrations) and centralize regulatory information, making it easily accessible across the organization. This means that in order for a RIM system to be useful, your data needs to be accessible to the system. Medtech companies without the following in place may not be ready for a RIM system:
- Digitized documentation: It is imperative that regulatory documentation, such as technical files and design history files, are in a digital format. If you still have older product documentation on paper in locked file cabinets - it’s time to get them digitized!
- Application infrastructure: RIM systems rely on data that is often stored in other applications, such as eQMS, PLM, or ERP systems. It is rare to implement a RIM system as the first application in a medtech company’s software stack. Medtech companies should have, at a minimum an eQMS system that is compliant with 21 CFR Part 820 and/or ISO 13485 and an ERP system in place before implementing RIM.
- No competing major IT initiatives: A RIM implementation is a major project that should be given dedicated resources and the attention of the management team. Consider the timing of a RIM implementation carefully if there are other majorIT projects, such as an ERP implementation or a major system upgrade.
Corporate priorities
It’s important to understand RIM projects as a true digital transformation. While it is primarily a technology implementation, the end result is a significant change in that way that regulatory affairs teams work. This change is very beneficial, but it’s still disruptive in the short term. Teams without the right leadership support and change management plans may struggle to realize value from their RIM investment.
- Digital transformation strategy: A RIM implementation is an integral part of a larger digital transformation strategy. Medtech companies that are most successful with RIM have a digital transformation initiative in place, and an understanding that they are driving organizational process change in addition to technology adoption.
- Recognized need: RIM implementations are significant projects that require resources and the attention of the management team. RIM projects are most successful when the management team recognizes that the status quo is not sustainable and places a priority on providing resources for the regulatory team.
Timing a RIM implementation
Medical device manufacturers who can benefit the most from a RIM system are those whose regulatory teams are, or will soon be, surpassing their ability to handle submission and product market data manually. For most medtech companies, the best time to start a RIM system implementation is about a year before they expect a significant increase in the demands on the regulatory team. While a RIM implementation rarely takes a year to complete, this will give you time to put in place the data and processes in time for them to be tested and accepted before the regulatory team is overwhelmed with other priorities. Consider:
- Expanding geographic reach: Expanding from one country or region into multiple markets creates significant complexity for regulatory teams. Manually maintained spreadsheets become insufficient for handling the ever-changing regulatory requirements in multiple countries.
- Growing product portfolio: Similarly to entering new markets, new products can exponentially increase the complexity of processes and data that regulatory teams need to manage.
- Greater product complexity or risk: Regulatory teams managing lower risk products, such as Class I products in the U.S., will not have as great of a need for a RIM system as those managing more complex products with greater regulatory requirements.
- Significant upcoming changes: Pending company acquisitions, changes to legal entities, major design updates, or other changes that would trigger re-registration activities mean significant increase in activity and risk for your regulatory team.
Teams and personnel
A RIM system empowers regulatory teams, allowing them to save time on administrative tasks and spend more time making sure their company’s products are entering markets efficiently and staying in market effectively. This means that a RIM system will be of use to a seasoned (almost always overworked) regulatory team. It is rare to implement a RIM system before an internal regulatory team is in place. If your company doesn’t have the following, then you likely won’t get full use or value out of a RIM implementation:
- Dedicated regulatory personnel: One or more regulatory professionals responsible for obtaining and maintaining market clearance for your products, and interacting with government health authorities.
- Committed management team: A management and executive team that recognizes the importance of a strong regulatory system, and is willing to commit the resources necessary to make it successful.
Think your team is ready for RIM? Not sure? Download our RIM readiness checklist or talk to us today!
ISO 14971: risk management for medical device manufacturers
What is ISO 14971?
ISO 14971 is the globally accepted international risk management standard for medical devices. This article discusses the most current version of this standard, ISO 14971:2019, currently considered the state-of-the-art standard.
ISO 14971:2019, provides the processes for identifying, evaluating, and mitigating hazards associated with the use of medical devices. While not mandatory, it is the most commonly used, industry-recognized standard to demonstrate conformity to when addressing product safety requirements. This article provides an overview of the standard, but should not be used as a substitute for the actual text of the standard.
As in the case of a quality management system, a risk management system addresses the full lifecycle of a medical device; including the design, manufacture, and use of the device. Also, while ISO 14971:2019 does not, itself, require the implementation of a quality management system, risk management is most often an important part of a strong quality management system.
Compliance with ISO 14971:2019 requires that a risk management system be established and maintained throughout the product lifecycle, and that all processes and results are stored in a risk management file. The risk management system will include processes for risk analysis, evaluation, and control. It is important to note that the standard does not define acceptable levels of risk for medical devices - this is left to the manufacturer to determine as part of their risk management processes. However, the guidance document, ISO TR 24971:2020, provides significant clarity and direction in interpreting the standard and developing a risk management system consistent with ISO 14971:2019.
EN ISO 14971:2019: EU harmonized standard
In the European Union, as of May 11, 2022, the specific version of the standard which has been officially recognized as a harmonized standard with current Medical Devices Regulation (MDR) ((EU) 2017/745 ) and In vitro Diagnostic Medical Devices Regulation (IVDR) ((EU) 2017/746), is EN ISO 14971:2019 and the amendment EN ISO 14971:2019+A11:2021. The amended version includes two Annexes, Annex ZA and ZB, which demonstrate the relationship between the standard and the risk management process required in the MDR and IVDR. The technical content of the two versions are identical and does not included any content deviations, unlike EN ISO 14971:2012, the version of the standard which is harmonized with the previous EU MDD and IVDD regulations.
Risk analysis
Under ISO 14971:2019 a manufacturer is required to document risk analysis activities and the results of those activities in a risk management file. These should include:
- Intended use and “reasonably foreseeable” misuse, along with all device characteristics which impact the safety of the device.
- Hazards (a potential source of harm*), both known and foreseeable.
- Estimation of risk for each hazard, based on the probability of occurrence of the hazard and possible consequences.
*Note: ISO 14971:2019 revises the definition of harm by excluding the word “physical” injury from the ISO 14971:2007 definition. The resulting ISO 14971:2019 definition of harm is “Injury or damage to the health of people, or damage to property or the environment”
Risk evaluation
Risk evaluation involves the determination of whether a risk reduction is required for a particular hazard. Manufacturers should weigh the combination of the probability that a hazard occurs with the severity level of the hazard. A risk evaluation matrix, such as the following example, is often used to to visualize risk acceptability.
It is important to note that ISO 14971:2019 and TR 24971:2020 added significant emphasis and clarity regarding the evaluation of risk and establishment of risk acceptability criteria. Under the previous versions of the standard (both ISO 14971:2007 and EN ISO 14971:2012), there was confusion and a lack of guidance around defining acceptable risk. It was common to use a two-dimensional matrix showing severity of harm along one axis and probability of harm along the other, but with little guidance there were multiple interpretations of how to establish these criteria and these matrices were often used to define policy. The latest version of the standard and guidance, however, emphasize that the matrix should be the output of the risk management policy, which would define the criteria for risk evaluation.

Risk control
When a hazard is found to have an unacceptable risk level, risk control activities are put in place to mitigate the risk. ISO 14971:2019 requires that “state-of-the-art” best practices that are used for similar devices be employed. State-of-the-art does not necessarily mean the most advanced processes and technical features, but rather those that are generally accepted in the industry. Risk control options should include, in order of importance:
- Inherent safety by design and manufacture
- Protective measures built into the device or into the manufacturing process
- Provided safety information, and where appropriate, training to users
Risk/benefit analysis should be performed and where benefit is determined to outweigh risk, the manufacturer will need to decide what safety information is necessary to disclose.
Relevant standards should be applied as part of the risk control process whenever applicable. Some of the standards which reference ISO 14971:2019 include ISO 13485 (quality management systems), IEC 60601-1 (electrical safety), IEC/EN 62366 (usability of medical devices), and IEC 62304 (medical device software). This makes ISO 14971:2019 essential for manufacturers seeking market approval for a medical device in the U.S., European Union, Japan, Australia and many other major markets.
Production and post-production information
A substantial change in ISO 14971:2019 standard is the expansion of requirements for production and post-production activities. The manufacturer will need to perform a full review of the risk management process prior to commercial distribution. The review should ensure that the risk management plan has been appropriately implemented, the overall risk is acceptable, and that procedures are in place to gather and maintain risk data during production and post-production of the medical device. ISO 14971:2019 aligns closely with the ISO 13485:2016 section 8 requirements for feedback, analysis of data and CAPA. Information collected and reported should include any newly identified hazards, changes that affect risk analysis calculations, and results of regular reviews of the risk management file.
Management responsibilities
Medical device manufacturers who wish to demonstrate compliance with ISO 14971:2019 must have a management team that is dedicated to and supportive of the risk management system. This includes ensuring that adequate resources are assigned to support the system and that the personnel assigned are qualified for their respective responsibilities. In addition to enabling the implementation and maintenance of the risk management system, management is responsible for reviewing the system periodically to ensure continued effectiveness.
For more information about technical documentation/compliance for medical devices, check out our comprehensive ebook, The ultimate guide to EU MDR and IVDR general safety and performance requirements (GSPR).
