Rimsys Announces Rimsys AI. Smarter, Faster, and Built for Medtech!

Blogs

MedTech

The ultimate guide to the EU MDR and IVDR general safety and performance requirements (GSPR)

By

Bethaney Lentz

May 9, 2022

4 min read

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

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.

Terminology

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.

EU MDR/IVDR Annex I

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.

EU MDR/IVDR Annex II

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):

GSPR Description Applicable? Methods Applied Standards & Solutions Evidence
7 Devices shall be designed, manufactured, and packaged in such a way that their characteristics and performance during their intended use are not adversely affected during transport and storage, for example, through fluctuations of temperature and humidity, taking account of the instructions and information provided by the manufacturer Yes Design considers packaging requirements. Packaged product has been verified through shipping and transit testing. Product was stored at extremes of temperature and humidity. EN ISO 13585 QMS
EN ISO 15223-1
Labelling
ISTA 2A Testing
Design procedure XXXXXX, rev XX located in document management system
QMS certificate XXXXXX
Package design drawings XXXXXX, rev XX located in document management system
Product label XXXXXXX, rev XX found in section XX of Tech File XX ISTA 2A test report title XXXXX, dated XX/XX/XX found in section XX of Tech File XX
Storage condition test report title XXXXX, dated XX/XX/XX found in section XX of Tech File XX
11.5 Devices labelled as sterile shall be processed, manufactured, packaged and sterilised by means of appropraite, validated methods. No N/A - This does not apply to this device (device id XXXXX) as it is not a sterile device and cannot be sterilised. N/A - This does not apply to this device (device id XXXXX) as it is not a sterile device and cannot be sterilised. N/A - This does not apply to this device (device id XXXXX) as it is not a sterile device and cannot be sterilised.

Proactive monitoring & maintenance

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.

Comparison table: EU MDR Annex I GSPRs vs EU MDD Annex I Essential Principles

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.

Similar posts

MedTech

Nonconformance reporting for medical device manufacturers

By

Wendy Levine

March 30, 2023

4 min read

Defining nonconformance

Very simply, a nonconformance occurs when a specification is not met. The FDA defines a specification in 21 CFR 820.3 as “any requirement with which a product, process, service, or other activity must conform,” and ISO 13485:2016 as a “need or expectation that is stated, generally implied, or obligatory.”

While managing nonconformance starts with fully defining specifications; it is the identification, tracking, and resolution of nonconformance that is a focus of medtech quality and regulatory teams and a requirement of both ISO 13485:2016 and the FDA’s 21 CFR Part 820 quality system regulation.  

Identifying nonconformance occurrences

As part of a compliant quality system, medical device manufacturers should implement procedures to identify and address both major and minor non-conformances. Nonconformances may be identified through processes found in multiple subsystems that are part of an overall quality management system within the organization.

The systems and subsystems in which nonconformances are identified typically include:

  • ERP
  • Regulatory information management (RIM)
  • Product lifecycle management (PLM)
  • Document management
  • Customer service / customer management  
  • Complaint handling
  • Device history records
  • Audit management
  • CAPA
  • Training/learning management  
  • Calibration/preventative maintenance
  • Development change management

Evaluating nonconformance

Once a nonconformance is identified, it should be evaluated in a timely manner, and a determination made as to the disposition of any affected products. Requirements for additional investigation and reporting should also be identified. Based on the severity of the nonconformance and its effect on the safety and efficacy of devices being manufactured or already in the market, a CAPA (corrective/preventative action) record may need to be created. In the U.S., this is defined in the quality regulation 21 CFR Part 820.100.

To disposition a nonconformance, consider the following:

  • Will the existing system detect the nonconformance if it recurs in time for remediation?
  • How likely is it that this issue will recur?
  • What is the impact of the non-conformance (i.e., could it affect patient health)?

Issues that are more severe or are more likely to recur should trigger a more immediate and comprehensive response.

Nonconformances that are escalated and handled under CAPA are based on risk and can include those that have or could have an impact on a product or process that is:

  • Not easily corrected
  • Recurring
  • Severe

In addition, nonconformances that rise to the level of a CAPA require significant resources and typically result in a full project to identify root cause(s), containment, and corrective actions, and monitoring for effectiveness.  

Nonconformances that don’t require a CAPA have simpler resolutions that include documenting actions taken to correct the issue (or justification for no action). If the issue is not recurring, there may be no other action required. For example, a nonconforming material received from a vendor may be a singular issue that was easily identified through existing inspection procedures and is not expected to recur. In this case, the material is returned to the vendor and no additional action is required.

Processes that are out of conformance are often resolved through improved documentation and/or additional user training. However, be sure that the true root cause of the nonconformance is identified as procedural nonconformances can signal additional issues.

Documenting nonconformances

An important part of nonconformance procedures is the nonconformance report (NCR) or other documentation procedures.  Nonconformances are typically documented within the subsystem in which they were identified. Some organizations will have a nonconforming system in which issues originating from all subsystems are documented. Centralized nonconformance systems allow for trending and other analysis across all subsystems, the results of which may generate CAPAs.  

The requirements for documenting a nonconformance may vary by subsystem. In general, however, nonconformance documentation records:

  • The requirement/specification that was not met.
  • The objective evidence supporting the determination.
  • The action that is being taken to address the nonconformity.

Nonconformances are a common point of focus during quality audits by regulatory bodies, including the FDA, and should follow a well-documented process. Auditors will often try to determine if the quality system is functioning effectively by looking at self-identified nonconformances and comparing them to externally reported nonconformances. This is to ensure that nonconforming products were not released, or that the appropriate actions were taken to resolve issues in the field.

The importance of nonconformance reports

Nonconformances related to distributed products of higher risk result in nonconformance reports issued to government authorities through vigilance reporting, medical device reporting, and field action/recall reports. For example, the FDA requires that a medical device report be submitted within 30 days of a serious adverse event (see 21 CFR Part 803 Subpart E). Strong reporting procedures for nonconformances of all types are important in identifying trends, addressing issues before they become critical, and as part of a complete quality management system.

A nonconformance reporting procedure is only part of a strong quality system. Read An overview of 21 CFR part 820 and ISO 13485 overview for more information on establishing quality systems for medtech companies.

Company

Why we developed Rimsys from the ground up

By

Wendy Levine

May 26, 2022

4 min read

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.

MedTech

Your eSTAR submission questions answered by FDA experts

By

Bruce McKean

September 8, 2023

4 min read

Your eSTAR submission questions answered

Starting on October 1, 2023, all 510(k) submissions, unless exempted, will need to be submitted electronically using eSTAR. eSTAR, which is short for Electronic Submission Template and Resource, is a dynamic PDF submission template that contains automation, guides, integrated databases, integrated policies and procedures, and automatic verification to help users prepare a comprehensive medical device submission.

Rimsys recently hosted a webinar, eSTAR submissions overview and live Q&A with FDA, to help the medtech community prepare for the quickly approaching eSTAR deadline. Patrick Axtell, Assistant Director for Tools and Templates Team, and Sajjad Syed, Software Engineer for Tools and Templates Team, from FDA joined our panel of Rimsys regulatory experts to provide an overview of eSTAR, demo, and live question and answer session. If you're interested in watching the webinar replay, you can find it here.

Due to high participation, we couldn't answer all questions live. This blog post provides Patrick's and Sajjad's answers to questions we couldn't get to during the webinar. Read below to learn what other industry professionals want to know about eSTAR!

Q: In the past, the sections were numbered Section 10 - Device Description.  How should section(s) be numbered in the eSTAR?

You may number attachments how you prefer, this includes numbering attachments according to the previous section numbers of the Format for Traditional and Abbreviated guidance document.  However, the numbering hierarchy in the IMDRF documents, which the attachment questions in eSTAR correlate to, may be better, since that numbering scheme is internationally harmonized.  So for example, if you are using the nIVD eSTAR, the IMDRF document specifies the Comprehensive Device Description would be numbered 2.04.01: https://www.imdrf.org/sites/default/files/docs/imdrf/final/technical/imdrf-tech-190321-nivd-dma-toc-n9.pdf.

Q: After October 1, 2023, will the In Vitro Diagnostics eSTAR Version be acceptable to use for a Dual 510(k) and CLIA Waiver by Application (Dual Submission)?

Yes, the next IVD eSTAR update will fully support Dual submissions, and the workaround we were previously implementing will no longer be needed. CLIA waiver submissions will continue to be submitted via current methods, and are not required to use eSTAR after Oct 1, 2023.

Q. It is not possible to view eSTAR online from cloud storage platforms. eSTAR like IFU Form and CDRH Form cannot be viewed online without users downloading these files. I will highly appreciate if  someone from the panel can give a solution to this. I understand these are special pre-programmed PDFs but it will immensely help if these can be shared for online viewing without having users download these files.

You need to choose to open eSTAR in the default application from within the cloud application you use, you can’t just click on it, since it will open in the browser, and browsers can’t open dynamic PDFs like eSTAR, Form 3881, Form 3514, and other forms FDA uses.

We can’t say that all cloud applications will work, but using Box does work. Once eSTAR is loaded in, click on the three dots, then choose the application you have installed, see screenshots below. I have Adobe Acrobat 2017 and Adobe Acrobat Pro both installed.

Be aware that every time you save the form, you upload it back into the cloud, so depending on how large it is and how fast your internet connection is, it may take many seconds to save each time, though you will see a progress bar.

Q: Does the eSTAR submission need to be submitted by only the US Agent or can this be done by the Foreign Manufacturer?

510(k) eSTARs, like 510(k) eCopies, can be submitted by foreign applicants.

Q: Will it be mandatory to use the eStar template for PMA supplement submissions?

Yes, by the end of 2023, eSTAR for PMA will be released. Similar to eSTAR for 510(k), there will be a pilot, guidance, and a transition period before it becomes mandatory.

Q: When do you expect to release the next version or sub-version of the non-IVD eSTAR template (4.x or 5.0) and will it be more elaborate on cybersecurity?

We are at the mercy of updating when policies are updated, which is irregular and unpredictable. Please email CDRH management and recommend a more consistent (e.g. quarterly) policy deployment schedule so that eSTAR can also have a more predictable deployment schedule. We are updating approximately one to every two months currently. Please be sure to read the Version History on page 1 of eSTAR regarding versioning and which version to use.

Q: How should a device categorized as a breathing gas pathway device in accordance with ISO 18562 be handled in eSTAR? One cannot find ISO 18562 categorization for a device in the eSTAR form.

This is a regulatory and policy question, and we are not sure what is meant by the statement “be handled.” Please reach out to OPEQ Submission Support OPEQSubmissionSupport@fda.hhs.gov with this question and they will direct your question appropriately.

Q: How often does FDA anticipate revising the eSTAR form?

eSTAR updates are almost exclusively timed according to policy updates, which the Tools and Templates Team has no control over. The T&T Team, as well as other groups in CDRH, are pushing for a quarterly update, where any policy updates in a quarter have an implementation date set for the beginning of the next quarter (e.g. Oct 1st, Jan 1st, Apr 1st). Please email Center management and promote this.

Q: The guidance Format for Traditional and Abbreviated 510(k)s: Guidance for Industry and FDA staff recommends a specific format for submissions. Biocompatibility, for example, is section 15. Should attachments in the eSTAR submission cross-reference the sections cited in the guidance? (So still using biocompatibility as an example, attachment 15.1 would be Cytotoxicity, attachment 15.2 would be Sensitization and so on)

The Format guidance, as well as the eCopy guidance, RTA guidance, and many other guidances, no longer apply for eSTARs.  Eliminating the applicability of guidances - simplifying the preparation process - is something we are proud of doing. You do not need to follow the numbering of this guidance.  See response above, where we recommend using the IMDRF numbering scheme instead, which is internationally harmonized.

Q: Where is information for risk assessments and management best included?

Depending on the type of submission you have selected (e.g. 510(k), De Novo, then Traditional, Special, Abbreviated), certain sections will become visible and active and some of them will be disabled. However, the bookmark pane will show all the sections in the entire eSTAR. Hence, please fill the sections that are visible to you since they are based on your selections. For example, if you have selected a Traditional 510k, the “Benefits, Risks and Mitigation Measures” section is not applicable. Hence it is not displayed and clicking on it leads a user back to the first page of the eSTAR. However, if you select “Special” as the 510k you are submitting, the “Benefits, Risks and Mitigation Measures” section does become applicable, and is displayed if you click on the bookmark. Also note that if you select De Novo, the section does become active as well. Another point to note is that for a Traditional 510(k) submission, if you do want to submit a Risks, Mitigations, Benefits report, you can attach it in the Performance Testing --> Bench Testing section of the eSTAR and identify it as “Other Non-Clinical Evidence”.

Q: Under Biocompatibility any idea when there will be endpoint questions for hemocompatibility or coagulation?

Hemocompatibility endpoint information, including Hemolysis, Complement Activation, and Thrombogenicity information, will appear depending on the tissue contact type and duration you choose. If you choose Implant Device >30 days, you will see this tab appear for example. The tabs that show are based on our Biocompatibility guidance.

Q: Guidance and Special Controls Adherence Section: According to the 510(k) electronic submission guidance document, identification of any applicable device-specific guidance documents or special controls should be included, which was done in the past; however, eSTAR requires each specific special control regulation or guidance recommendation to be listed. Can you please specify to what level of detail needs to be included within this section? The text box contains a character limitation, so it is unclear how specific information needs to be.

There are four textboxes like this in eSTAR. The specifications, characteristics, etc., of the device should not be provided in these textboxes. Instead, these textboxes should be used to refer to the attachments where these controls or recommendations are found, per each specific recommendation. These textboxes do expand as text is typed in, if needed. Keep in mind that the special controls, device-specific guidance citations would be divided among these four textboxes.

Q: Why are Advertisements included within the Labeling section, when they should be considered promotional materials? Could reference to advertisements be removed from this section?

Advertisements and promotional materials are included under the Other Labeling, and within the sub-attachment type "Other Labeling and promotional material" since this is consistent with Internationally harmonized document N9 and N13.  As the help text states, whether you actually need to attach it at all (it is an optional attachment) is dependent on the jurisdiction. For FDA, you would need to reach out regarding your device and current policy at opeqsubmissionsupport@fda.hhs.gov.

Q: I need to know how eSTAR would promote efficiency.

There are many efficiency gains with eSTAR, this is not an exhaustive list. The eSTAR website also includes some of this information.

-eSTAR complements the reviewer's internal smart review template used to review the submission (i.e. the questions correlate).  Therefore the reviewer is getting what they are expecting

-eSTAR provides a standardized format so that the reviewer (and applicant) always know where to find certain information

-eSTAR auto-updates many aspects of the submission, most notably it ensures the content is present negating the need for an RTA review by the reviewer, and therefore RTA holds

-eSTAR autocompletes information that you enter, ensuring you never need to enter the same information twice

-eSTAR includes built-in databases that ensure you see the information pertinent to your device (e.g. device-specific guidances), classification information automation, and the standards database, for auto-filling standards info accurately

-eSTAR has many forms built in, so that you don’t need to attach or upload them (e.g. T&A statement, Form 3514, 510(k) Summary, Declaration of Conformity, Form 3881)

-eSTAR guides the applicant through what is needed throughout, ensuring we collect everything that needs to be provided, and you know how to do it correctly

-eSTAR is collecting submission data in a structured format, which will help automate many aspects of our processing.  This will provide applicants and reviewers many benefits (e.g. automating the submission log-in process, therefore permitting reviewers to receive a submission within minutes of when the submission is uploaded in the CDRH Portal)

-eSTAR is intended to be used as a resource also, since it consolidates all the information needed (e.g., regulation links, guidance links, submission process information) to prepare a submission

I agree to the privacy policy including to Rimsys using my contact details to contact me for marketing purposes.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Hand holding smartphone showing email app with 12 unread messages notification.