Insights & Intelligence for Regulatory Leaders

Rimsys has had quite a year already! In early December, we closed on $16 million in Series A financing and since then we have been carefully growing the company to better serve our customers and the regulatory affairs community. We have almost doubled our employee count and redesigned the Rimsys system to deliver deeper functionality that is even easier to use. We had our first in-person employee meeting here in Pittsburgh at the end of April where we introduced our new mission statement, and we are all excited to be doing our part to improve global health!

All of these changes made us think back to the founding of Rimsys and how far we have come. So - I sat down with Rimsys Founder and CEO, James Gianoutsos, to talk about the genesis of the company and how he knew that a new type of system designed for medtech regulatory affairs professionals was needed, and needed to be built from the ground up.

Q: What was the biggest challenge you faced as a regulatory professional that led you to form Rimsys?

James: The biggest challenge I saw while working at Philips for many years was completely understanding the complexity and the nuances around everything regulatory from a product standpoint. This really came to light whenever we acquired products. Just seeing firsthand how inefficient and out of compliance these manufacturers really were, and how hard it was from an administrative standpoint just to get into compliance and then to stay compliant, was striking. 

I was working with a smaller medical device company which had acquired products from Philips. Philips provided the company with a list (a color-coded Excel spreadsheet)  of all of their products that the company had acquired along with the registration status of those products globally. After digging into the spreadsheet for several months, we found that about 50% of it was wrong, incomplete, or just completely missing. The company was trying to keep track of registration information, but the available tools were making it nearly impossible. I realized that this was the challenge, and that there really wasn’t a solution on the market that could solve that problem in an easy manner and in a medtech regulatory-focused way.

‍Q: There were solutions on the market that were geared more towards the pharmaceutical industry, correct?

‍James: Yes. So I did what every other regulatory professional did, which was to Google “regulatory software,” and I saw that there just really wasn’t anything on the market that fit our needs. The solutions on the market really were pharma-specific, even those that said they worked with medical devices. The workflows and regulatory requirements for medtech are very specific for each market, depending on the product type and risk class and so many other factors. To use a pharma system that was already on the market  just wasn’t even an option because it was like comparing apples to oranges. It is completely different from the regulatory and workflow side of things.

‍Q: There are existing tools used by the regulatory community, such as quality management and document management systems. Did you envision the new RIM system integrating with existing tools, replacing them, or a little of both?  

‍James: I never set out to replace those types of systems, no. In fact, I knew that existing system architecture and infrastructure couldn’t handle the specific medtech regulatory workflows but needed to connect to those systems. There have always been PLM (Product Lifecycle Management) systems that contain a company’s product master data, but those systems were never meant to be workflow-driven based on regulatory requirements. At the same time, they are critical for organizing and maintaining product-specific metadata. Then there are ERP systems, which are really about making sure companies have sales flags (i.e. regulatory blocks) in place, appropriate shipping codes, or selling status linked to product registration status. Regulatory professionals are concerned about answering two questions for ERP users; one, “does the product have a valid and current registration within the country or market,” and two, “if it is registered, are we selling and shipping into that market.”  Lastly, quality/document management systems house critical documentation and records needed for registrations. The problem with these systems is that there are no regulatory workflows and no way to compile technical documentation, leaving the documents and records siloed from the regulatory filings.

To do the things that a regulatory affairs professional, in a critical regulatory department, does for their company, the system really had to be built from the ground up with all of these systems in mind. It had to be product-centric. It had to integrate with all these other sources of information, because there really wasn’t a common connection point between your products, your documentation, and the records that you needed to compile and how that relates to getting products on the market. We had no way to communicate to our other systems that a product is actually available for sale in that market or that it confidently can, or more importantly cannot, ship to that market.

‍Q: What was the most difficult piece of functionality to implement in Rimsys?  

James: Well, at the time it kind of all seemed difficult! No, really the most difficult part was thinking thoughtfully and strategically about how data was going to be mapped and used in conjunction with other data elements, in order to make the system most helpful from a user perspective. We wanted to single-source information to enhance and streamline regulatory workflows, but then also make sure that it was as user friendly as possible. There are a lot of stakeholders that need information or have input into regulatory workflows. Quality assurance, marketing operations, R&D, engineering, sales - all of those specific stakeholders need to view information in a way that is understandable to them.

We worked hard to bring all that information, streamline complex regulatory workflows, and all of those internal and external data sources together in an understandable and user-friendly way.

Q: How important has the technology itself been in the creation of Rimsys?

James: Technology has been a huge advantage for us from day one. Our team had quality and regulatory backgrounds, so we knew what companies would expect from us. We knew we had to be 21 CFR Part 11 compliant. We knew we had to be ISO 27001 certified. We knew we had to have SOC2 Type 2 reports. We knew we had to integrate with a company’s existing IT infrastructure. We really had to build this thing from the ground up on a GxP compliant platform that we could build upon and expand, without having to go back and reinvent the wheel every time we added new functionality. 

It’s continued to pay dividends for us because it was something that we thought about from the beginning and that gave us a lot of flexibility. We already had the system and infrastructure in place that we could then expand upon a lot more quickly than we would have been able to otherwise. It’s like the difference between building a house today and trying to remodel a house that was built in the year 1900. If you break down a wall in the older house, there might be so many hidden issues behind that wall - load bearing issues, knob and tube wiring, asbestos, etc. With new modern infrastructure, it is just night and day in terms of adapting quickly with changing regulations and a fast-paced market.

Q: Was there any specific technology you can talk about that became important to the development of Rimsys?

James: Our choice of technology was driven by our desire to build a system that was user friendly and built on a modern infrastructure that felt familiar to our users. So, we took a lot of the Google framework to build an application that didn’t look like enterprise software, but looked and felt more like a consumer product that is inviting, not overwhelming. 

The other thing is that we built the system from day one to integrate because we knew we had to connect with a lot of different sources of information. We strategically built the system with API’s in mind.

Q: What is Rimsys doing differently than other software companies in the regulatory space?

James: We are creating a holistic solution, which is different from what is out there now. We know that registration management is just one key aspect of what regulatory affairs teams need. In order to create a proper regulatory system, we had to take into account all of the data and dependencies and build a system specifically for medtech regulatory teams and other key consumers of regulatory data. There has to be a single source of truth for this data, because otherwise it becomes a nightmare at the end of the day. Existing software solutions were siloed and purpose-built for other industry needs, such as eQMS, PLM and ERP. None of those systems can do what a holistic RIM platform can do. Because of the complex workflows, the regulatory needs are far too broad and interdependent, that data infrastructure is completely different, data sources are too numerous, and the systems offer limited support to bring everyone and everything together into a cohesive, streamlined, compliant and medtech-specific solution.

Another key component of what we are doing is to institutionalize regulatory knowledge and resources into Rimsys—this is at the heart of who we are and what we do. Having the only purpose-built, holistic RIM platform built by and for regulatory professionals specific for the medtech industry really couldn’t be done without internalizing that experience within our own team.

Q: What are you most proud of when it comes to Rimsys? 

James: I think there are two things that immediately come to mind. Having our Rimsys 5 platform launch is really exciting. This is the fifth iteration of our platform, and we did it by listening to our customers and iterating over and over again to get it right. We had to go back to the drawing board a couple of times, not because what we had written wasn’t working, but because our customers that were using the system every day gave us better ways to do things. Rimsys 5 is a really proud moment because this is the platform that we are taking into the future, that will let us get to the next level where we are truly empowering regulatory professionals to make critical decisions and do the job that they are meant to do. 

The ability for us to listen to our customers, take that feedback and move fast is the second thing I’d mention here. We know that this has to be a validated system, but we are able to make changes and add features in a way that is thoughtful and gets our customers what they need right away. Regulatory professionals are very particular. I know since I am one, and making sure they are comfortable using Rimsys from day 1 is critically important. Being a customer-centric company really makes our experience as a team extremely rewarding.

Q: Where is Rimsys going next?  What are you most excited about?

I think I am most excited about Rimsys being an advocate for the medtech regulatory community and helping them wherever we can. Regulatory has a seat at the table now and it is a great feeling to see that we’re able to help these companies to streamline their workflows, accelerate time to delivery for life-saving products and maintain that compliance to keep those products on the market. Regulatory affairs is a mission critical department that the medtech industry cannot underestimate. It’s empowering because while we are helping our customers, they are helping us and every single one of our other customers through the journey of regulatory uncertainty that everyone is going through right now. It feels like a real partnership between us, our customers, and the industry as a whole and I am excited to see where that will take us.

I am also really excited about where we are going with regulatory intelligence. We are just scratching the surface of this now, but you will see regulatory intelligence data built into Rimsys and providing RA professionals with tools that can really provide a competitive advantage for their company. The release of Rimsys 5 platform (“Phase 1”) provides us that platform that will take us into “Phase 2” of Rimsys, with embedded intelligence that will further empower regulatory professionals to make decisive, correct and confident decisions for their products and their company.

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.

Last week, the entire U.S. Rimsys team gathered in our Pittsburgh offices for the first time in 2022. It was an incredible week of collaboration, learning, goal-setting, and meeting the more than 25 new team members who had joined since our last on-site in December. It was also an opportunity to reflect on the company that Brad (Co-Founder & CTO) and I started just a few years ago, how much we’ve changed, and where we want to go.

I founded Rimsys with a singular focus on medtech regulatory affairs, and solving all of the incredibly painful challenges that I experienced leading regulatory teams in the industry. In large organizations, regulatory affairs is directly linked to hundreds of millions dollars in revenue, yet RA teams still do most of their work manually using spreadsheets and other tools that aren’t remotely fit for purpose. 

The Rimsys platform is designed to digitize regulatory information, make it much more easily accessible, and allow regulatory affairs teams to use it to power a series of automated processes. As a result, our customers have dramatically reduced the administrative work associated with regulatory activities, from reducing release authorization time by 80% to reducing GSPR maintenance time by 99%! Rimsys 5, which we announced this week, introduces more streamlined workflows, a brand-new user interface, and adds even more time-saving capabilities like collaborative submission authoring, and integrated regulatory intelligence.

This focus on regulatory affairs was what drove the initial mission of the company to “digitize, automate, and create order for the medical technology industry”. This mission helped to drive alignment and focus as we were initially building out the company, but it also missed the broader picture of why we, and the industry, were doing this in the first place.

A life-saving shipment

This bigger picture began to take shape when I received an email from one of our customers during the horrific COVID-19 outbreak in India last spring. The customer is a large in-vitro diagnostic manufacturer, and they were working to quickly send humanitarian shipments of testing products to help with the crisis. In the email, along with some images of the initial shipment being loaded for transport, our customer noted that because all of their product and regulatory documentation was managed in Rimsys, they were able to expedite clearance and release authorization, avoiding import delays while paving the way for the life-saving diagnostics to be shipped more quickly.

We talk a lot about efficiency and the direct link that regulatory affairs has to revenue in the medtech industry, but there’s more to it of course. Much more. At the end of the day, medtech companies create products, and regulatory affairs teams work to place them on the market in order to give patients access to technologies that can dramatically improve and even save their lives. This is what we’re doing.

A bolder, broader mission

With this context, our initial mission felt a bit narrow. It spoke to what we were doing, but not really why. So, we decided to revise the company mission statement. Working with our team on-site we crafted a new mission that better aligns with the outcomes we’re helping to drive in the world:

Improve global health by accelerating delivery and increasing availability of life-changing medical technologies

The new mission clearly articulates the “why” behind what we’re doing, but it also deliberately doesn’t constrain our approach. Today we’re focused on using technology to streamline regulatory affairs, but there are many other areas across the industry that our technology can improve; from post-market, to clinical, to marketing. Our vision is for Rimsys to be the leading technology provider to the medical technology industry.

Why this matters

As our company grows, it’s critical to me to maintain the culture that we established in the early days. This isn’t something that happens on its own. Culture only grows organically with deliberate focus and attention. Whether it’s our company values, our focus on continuous learning, our regular on-site’s for remote team members, or our new revised mission, I’m constantly reflecting on how we will build a large, successful business that stays true to our purpose.

Our new mission clearly states our purpose, and explains why we think this industry is so vital. We’re honored to have the opportunity to help more life-changing technologies get into the hands of patients that need them. And, if this mission resonates with you, we’re hiring across all of our teams.

‍

The Rimsys team is both excited and very proud to introduce Rimsys 5 today. The latest version of Rimsys includes a comprehensive regulatory submission module and provides real-time, global regulatory intelligence through a partnership with Clarivate Cortellis. Additional new features include an updated and highly-flexible product hierarchy and the ability to link product, performance, and safety data across the organization through standardized integrations with PLM, eQMS, and ERP systems.

Many of these new features and capabilities were driven by input from our customers.  In addition to the big changes, we’ve also overhauled the user experience, making the entire platform more usable and intuitive.

Rimsys 5 brings a unique approach to regulatory submissions.  The platform now provides regulatory affairs teams with the ability to manage submission projects, collect documents and information, and directly author submission content in a single interface. In addition, customers have full access to their submissions archive without any additional cost. We believe this will lead to significant improvements in productivity for regulatory teams.

What we are most proud of is that only 3 years after introducing Rimsys software to the medtech industry, 10 of the top 30 medical device companies worldwide are trusting their critical regulatory processes to our RIM platform. As the global regulatory landscape becomes more and more complex, Regulatory Information Management (RIM) software will become increasingly critical for medical device companies to bring products to market quickly, and  ensure that they stay on the market. 

Rimsys 5 builds on an already established platform of product-centric regulatory tools, including standards management, UDI, expiration monitoring, market-specific sales status tracking, and more. With version 5 of the platform, regulatory teams can now:

• Access high-quality comprehensive regulatory information. Powered by Clarivate Cortellis, Rimsys 5 provides access to over 200,000 regulatory documents, updated daily.
• Build content plans based on government templates. Users have access to fully customizable submission templates for common market applications, including FDA 510(k), STED, NMPA, and PMDA.
• Collaboratively author submission content. Rimsys allows regulatory affairs teams and other collaborators the ability to work together to create structured submission content within the Rimsys application - without having to jump between outside documents and spreadsheets.
• Manage submission projects, approvals, and health authority communication. Submission features are wrapped in full project management capabilities, allowing regulatory teams to assign tasks, manage approvals, and track communications with internal teams, partners, and health authorities.
• Link product, performance, and safety data across the organization. Rimsys 5 provides open integration with PLM, eQMS, and ERP systems allowing regulatory affairs teams to directly pull design history, testing, and quality control documents into regulatory submissions without duplication. Automated alerts let teams know when source documents have been updated.

• Auto-generate complete regulatory submissions. Rimsys 5 provides automated publishing features that consolidate documents into submission packages in the correct PDF format, creates appendices for file attachments, and renders submissions ready for delivery to health authorities.

All of these features combine to provide a full record of submission history directly linked to individual products, countries, and registrations - giving regulatory teams the tools they need to fully administer, track, and generate regulatory information for every product in every market.

Learn more about the new release at our Rimsys 5 overview webinar on May 18th.

‍

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.

FDA device registration overview

Registering a new medical device with the FDA can be a huge undertaking, and understanding the process and all of the requirements as early as possible is important. This article provides a high-level overview of the steps required before marketing and selling a medical device in the United States. We’ve done our best to include relevant links to both FDA documentation and educational materials wherever possible!

FDA medical device registration steps

Classify your medical device

Classifying your medical device should be one of the first steps in any FDA submission. The FDA classification system is a “predicate-based” system in which devices are classified based on similar devices that are already on the market in the U.S.

You may already have an idea as to which of the three device classes your product falls under, but you still need to determine the specific device category described within 21 CFR Parts 862-892. The FDA provides a good overview and listing of device categories that is searchable. This will allow you to determine which specific section of the regulation pertains to your device, which will then define the classification and relevant premarket requirements. While the majority of Class I devices require no premarket notification, the majority of Class II devices require 510(k) premarket notification, and the majority of Class III devices require a premarket authorization submission, however,this is not always the case. 

Medical device manufacturers can request information and guidance from the FDA regarding the classification of a device through a 513(g) request. For the classification of accessories to your device, a pre-submission may be more appropriate (discussed below) 

Collaborate with the FDA prior to your submission   

The FDA encourages pre-submission collaboration meetings and communication as early in the product development process as possible. It is in the best interest of organizations seeking approval of a medical device to have an open dialogue with the FDA, enabling the FDA to advise before and during the submission process, provide direction on Investigational Device Exemption (IDE) applications, and identify any potential concerns that may affect approval or clearance of the device. This is especially important for devices with novel technology.

There are a number of pre-submission activities defined in the FDA’s “Q-Submission” program (these were previously referred to as “pre-ide” meetings). Q-subs provide an organization with the opportunity to obtain feedback from the FDA before a premarket submission is made. The most common Q-subs are:

Pre-submission (pre-sub) requests provide an opportunity for an organization to obtain feedback from the FDA before completing a premarket submission. Pre-sub requests are made in writing to the agency and can involve a meeting if requested by the submitter. The submitter should have specific questions prepared regarding their submission and/or product development prepared for the FDA to review during this meeting. 

Informal Meetings are requests to share information with the FDA with no expectation of feedback. This may be helpful if your team has a variety of submissions planned, or if your company would like to explain the technology of your device. 

Early collaboration determination meetings are requests by a PMA applicant for the FDA’s determination of the type of valid scientific evidence required to demonstrate that the device in question is effective for its intended use.

Early collaboration agreement meetings are used to reach an agreement between the FDA and the submitter on key parameters of the investigational plan.

Results of early collaboration determination and agreement meetings are binding on the agency. For additional information, see “Early Collaboration Meetings Under the FDA Modernization Act: Final Guidance for Industry and for CDRH Staff”

Prepare the appropriate premarket submission for your medical device

Remember that most Class I devices, and some Class II devices require no premarket submission (though they are required to be listed with the FDA).

510(k) Premarket Notification is used for Class II and Class III devices with a medium risk profile for which there is a predicate, substantially equivalent, device on the market that requires a 510(k) submission.

The 510(k) submission is used to demonstrate that the predicate device is substantially equivalent to the new device and, if successful, results in an FDA “clearance” for the new device. You can read more in our FDA 510(K) beginner’s guide.

Premarket Approval (PMA) is used for Class III devices for which the identified predicate device requires a PMA. These are devices which are high risk; defined as a device that supports or sustains human life, is of substantial importance to preventing impairment in human health, or presents a potential and unreasonable risk of illness or injury. Novel devices which have no substantial equivalent on the market also require a PMA by default.

A PMA is intended to prove that a new device is safe and effective for the end user, and 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. A successful PMA results in an FDA “approved” device.

The De Novo classification process can be used for novel devices for which there is no substantial equivalent on the market, but which have the lower risk profile of a Class I or Class II device. A successful De Novo request is “granted” by the FDA and results in the classification of the device as Class I or Class II. You can read more in our De Novo classification process: a beginner’s guide.

Work with FDA staff during the review process

The more complex your submission to the FDA, the more opportunities you will have to interact with the agency during the review process. Take advantage of these opportunities and be sure to respond to any requests for additional information within the specified time frame. The 510(k) submission process and the PMA submission process both have defined procedures for requesting and submitting additional information during the review process. PMA submissions for devices with new technology may also require interaction with an expert review panel. 

If you need additional clarification from the FDA on your 510(k) or PMA submission, the following options are available: through the Q-submission process:

Submission Issue Requests (SIR) are Q-submission requests for feedback and clarification during a pre-marketing submission including 510(k), De Novo and PMA submissions. These are often held after a submitter receives letters from the FDA asking for additional information or deficiency letters. 

PMA day 100 meetings are Q-submission requests held within 100 days of a PMA submission and are used to discuss any deficiencies in the application, and to begin a conversation on the status of the application. FDA guidance on PMA day 100 meetings can be found here.

Complete a quality system audit

Most Class II and III devices, and some Class I devices will require a premarket quality system inspection. During most of the Covid pandemic, inspections were being conducted remotely, but the FDA resumed domestic onsite inspections in February 2022. 

A compliant quality system demonstrates that your facilities are capable of manufacturing the device as designed to meet its intended purpose, and the FDA will evaluate both design controls and manufacturing controls.

Current quality system requirements are defined in 21 CFR part 820 (quality system regulation or “QSR”), however the FDA is moving to harmonize their requirements with the generally accepted global standards of ISO 13485. In addition, the Medical Device Single Audit Program (MDSAP) can be used as an alternative allowing a single audit that is recognized by regulatory authorities in multiple countries, including the FDA.

Whichever path your inspection takes, it is important to put a strong quality system in place as early as possible.

List your medical device on your establishment registration

Any organization involved in the production or distribution of a medical device intended for use in the United States is required to register annually with the FDA. Establishment registration is defined in 21 CFR Part 807. There is an annual registration fee, which is $5,672 for 2022.

Most establishments that are required to register with the FDA must also list the devices and the activities performed on those devices at the establishment. Registration and listing information must be submitted to the FDA within 30 days of a device being put into commercial distribution. You cannot list your device until it has been cleared or approved through a premarket submission process, if required for your device.

The FDA provides detailed information on the device registration and listing process.

Post-market compliance

We will cover post-market surveillance and compliance in a future post, but here are a few things to keep in mind:

• If your device was approved via a PMA, expect a post-market inspection 8-12 months after approval.
• Changes to a cleared or approved product may trigger additional reporting and submissions. The significance of the change will dictate the type of reporting required for both 510(k) cleared devices and PMA approved devices.
• Your quality system should include a CAPA (corrective and preventive action) tracking system to record and address any issues that arise after the device is on the market.

For additional information on FDA submission processes, see our ebooks which cover the 510(k), and De Novo processes.