Insights & Intelligence for Regulatory Leaders

The Food and Drug Administration (FDA) recently released a final guidance document, “Content of Premarket Submissions for Device Software Functions.” This document is intended to provide information about the recommended documentation that medical device manufacturers should include in premarket submissions for the FDA's evaluation of safety and effectiveness of device software functions. This document replaces the FDA's “Content of Premarket Submissions for Software Contained in Medical Devices” document issued in May, 2005. Note: This new guidance does not apply to automated manufacturing and quality system software or software that is not a device.

In general, the FDA’s guidance documents do not establish legally enforceable responsibilities. Instead, guidance’s describe the FDA’s current thinking on a topic and should be viewed only as recommendations, unless specific regulatory or statutory requirements are cited.

Highlight of changes to FDA guidance on premarket submissions for device software

Since the last time this document was revised (2005), there have been many updates to this new guidance document that are certainly worth noting. Along with the multiple changes and additions, this guide will help with more clarity in the process of determining software documentation for premarket submission and review of software medical devices, or devices that have a software function.  

Some of the highlights that are important to mention include:

• Changes in terminology to more current trends. For example, the Hazard Analysis is now referred to as the Risk Management File.
  
• The table of contents has been extended and divided into several sections, broken down even further to include documentation type and Documentation Level.
  
• Level of Concern is now referred to as Documentation Levels. Although still guided by the level of product “risk," instead of major, moderate, and minor levels, they are now identified as Basic or Enhanced Levels.  Basic is any premarket submission that includes device software function(s) where Enhanced Documentation does not apply. Enhanced includes device software function(s) where a failure or flaw of any device software function(s) could present a hazardous situation with a probable risk of death or serious injury, either to a patient, user of the device, or others in the environment of use.
• The Recommended Documentation section (formerly the Software-related Documentation) section has expanded to include more detail and subsections about software requirements, software architecture, software design, software development, software testing, software version history, and unresolved software anomalies.  
• The Software Description has been revised to add reference to guidance about Multiple Function Device products that extends into software operation, software specifics, and software inputs/outputs.  
• The Hazard Analysis is now the Risk Management file and continues to recommend ISO 14971 for guidance. It’s also been extensively revised to include the risk management plan, the risk assessment and risk management report.  
• Newly added Appendix A provides many Documentation Level examples intended to demonstrate the implementation of the Documentation Level risk-based approach. Over 20+ product examples are included in this list.
• Newly added Appendix B provides examples of diagrams for the purpose of demonstrating how the System and Software Architecture Diagram could be implemented into diagrams, and to help show a clear understanding of the system and software.

In addition to this new guidance, the FDA recommends reviewing the following guidance documents (which is not an exhaustive list) for additional support in determining premarket software documentation for submission.

• Multiple Function Device Products: Policy and Considerations
• Off-The-Shelf Software Use in Medical Devices
• Design Considerations and Premarket Submission Recommendations for Interoperable Medical Devices
• General Principles of Software Validation
• Content of Premarket Submissions for Management of Cybersecurity in Medical Devices
• Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS) Software
• Applying Human Factors and Usability Engineering to Medical Devices

Software for medical device regulatory teams

Many regulatory affairs (RA) teams within medical device organizations are still managing their activities through spreadsheets, in-house custom-built software, or systems designed for other purposes. We believe that regulatory teams deserve purpose-built software that allows them to ensure compliance across products and markets, and provides them with the opportunity to contribute directly to revenue-driving activities.  

Regulatory Information Management (RIM) solutions provide the centralized regulatory functionality needed by today’s RA teams. RIM solutions such as Rimsys are product-centric, allowing regulatory professionals to track all product-specific information and then create market submissions, link standards and essential principles, manage registrations by product by market, and control all regulatory approvals and projects. However, not all RIM solutions are created equal. If you have complex products, devices that include software, or other requirements that not all medical device companies will have, be sure to carefully evaluate potential systems for their ability to address those needs.

Justifying the need for RIM

Any software selection project begins with analyzing the need for the new software, creating a justification for the project, and obtaining the approval and budget to move forward. RIM solutions will allow your RA team to find information more quickly and operate more efficiently, which means that justification for a new RIM system typically comes from four areas:

1. Cost savings – RA teams can operate more efficiently, reducing the need for outside consultants or contractors and enabling new RA team members to onboard more quickly. Better information also allows RA teams to better forecast projects in order to optimize the internal team size.  

2. Reduced regulatory risk – A centralized RIM system reduces multiple risks, including missing an expiration date or supplying incorrect information to a regulatory body. Even a small misstep can cause an audit finding, removal of a product from a market, or a delay in entering a new market.  

3. Improved competitive advantage – RIM systems significantly reduce the time that RA teams spend finding data and reacting to last-minute “emergency” requests. This advantage allows the team to drive competitive advantages and greater revenue growth through participation in market planning, product roll-out decisions, and other strategic planning. One Rimsys customer was able to improve the time for a product release by 88%. By increasing speed to market, medtech companies can recognize revenue sooner and capture more market share more quickly.  

4. Data harmonization – Medtech companies dealing with duplicated data and systems due to mergers or acquisitions can point to a centralized RIM system as a way to harmonize important regulatory data to ensure compliance and optimize go-to-market activities.

You will likely need to develop a comprehensive business case to support any RIM investment. This will include detailing the limitations of current approaches (including spreadsheets and costs to maintain in-house systems), quantifying the expected benefits, and explaining the evaluation process to arrive at your preferred vendor. Building this as you work through the early stages of RIM selection will prevent delays as you move into the purchase process.

Should I use external consultants to help with RIM selection?

RIM selection projects are sometimes managed by in-house teams and sometimes managed by 3^rd-party consultants. How do you decide which is right for your selection project?

Does your team have experience with large system selection projects?

If your organization has a large IT team and/or digital transformation team, they likely have the responsibility of overseeing the selection of any new software systems. Be sure to understand their capabilities – have members of the team managed large system selection projects before, such as ERP or PLM selections? The regulatory team and others within the organization can provide subject matter expertise, but you will be relying on the technical team to oversee the project, define requirements, help set a budget, and more.  

If the right level of expertise does not exist within your organization, an outside consultant with medical device regulatory experience and with business system selection projects should be considered. This type of consultant can be extremely helpful during the system implementation and adoption phase of the project as well.

Does our team have the bandwidth to manage a RIM selection project?

Even if your organization has an internal team with the expertise to manage a RIM selection project, they may not have the time to do so within the desired project timeframe. In this case, an external consultant can augment your existing team to get the project completed as required.

Do we need a new perspective?

Selecting a RIM solution is as much about digital transformation and process optimization as it is about ensuring you find a system with the right features. Do you have a vision of where you want the RA team to be? Have you looked at the characteristics of top-performing RA teams? If you think you might need a new perspective and an outside voice, an outside consultant may be the right choice for your project.

RIM selection project steps

Once you have determined the need for a RIM system, a selection project should include the following major steps:

Build the selection team  

Put together a core selection team that consists of:

1. A project leader that is typically at a manager level or above within the organization and comes from the regulatory or IT teams.

2. An executive sponsor who may not participate in all aspects of the project, but who will ensure that resources are made available to the team as needed and that the project is kept on track and is aligned with overall company goals.

3. IT team member(s) who will provide feedback on technical system requirements, including security and data privacy, and will support customization and integration discussions.  

4. Subject matter experts representing each department and team who will be using or interacting with the software.

You will add team members once you begin to implement the system, but selection teams typically consist of fewer than 10 members.

Determine requirements and selection criteria  

One of the primary responsibilities of the selection team is to define the requirements for the new system, and the criteria on which systems will be judged. Requirements usually fall into multiple categories, including:

1. Business requirements – These are broad requirements based on business needs. They will typically answer the question “Why do we need a RIM system?” For example, reducing the administrative burden on the regulatory team with functionality that allows the team to track registration expiration dates, create submission dossiers, and quickly report on registration status by product and market. Include project timeline and budgetary constraints here as well.

2. Functional or user requirements – Functional requirements are a more detailed list of specific functions that users will need to perform in the system. For example, the ability to link standards to essential principles, manage multiple approvals for submission documents, or track UDI product data. DO include requirements that are essential for users to complete their work within your defined quality procedures. DO NOT include requirements that are unnecessarily specific (ex: the product description must contain at least 50 characters) or are so common that all systems will meet the requirement (ex: there must be a product number and description in the product record).    

3. System and technical requirements – Your IT team may already have a list of the overall technical requirements that all software must meet within your organization. These will likely include data security requirements and features that support system validation. Include any specific requirements regarding system availability, upgrade management, and technical support guarantees. See SaaS 101 for medtech regulatory professionals for a list of questions that you should ask a SaaS solution provider. Also include here any procurement requirements that your organization has, such as insurance requirements.

4. Vendor resources and vision – You want to work with a vendor that shares your vision, not only for this system implementation but also for future growth. Evaluate each vendor’s product roadmap and plans for innovation against your organization’s digital transformation plans for the next 2-5 years. Does the vendor share your vision? Do they have the resources to support your organization and that future vision?

Establish project goals and timelines

Establish project goals and an overall project timeline. Is there a hard deadline by which the system needs to be live? What are the goals and metrics with which the success of the project will be measured? Be sure to get written agreement from the project team and executive team on the goals, timeline, and how the information will be reported.

Research RIM vendors (build your initial list)

If you are working with an experienced regulatory consultant, they may be able to get you to your short list without this step. However, if you are unsure of which systems may meet your needs, begin by:

• Researching Regulatory Information Management systems online.
• Talking to other regulatory professionals for suggestions and referrals.
• Consulting with industry analysts. Gartner's annual RIM market guide, and Gens & Associates World Class RIM report both provide an overview of RIM vendors. (Note, however, that both include both pharma and medtech-focused solutions within their respective guides.)

Build vendor short list

Based on the information gathered in the previous step, you should be able to create a short list of two to six vendors. This may require short conversations with prospective vendors, but you should have your short list before you schedule product demos and/or send out a request for proposal (RFP).

Tip: If you communicate with vendors that don’t make your short list, let them know so that they don’t continue to contact you!

Evaluate vendor capabilities  

This part of the project varies greatly from company to company, but your process should ensure that all of your stated requirements are being evaluated against each vendor’s capabilities. Not all team members need to evaluate all requirements – individuals should be assigned based on their understanding of the area being evaluated. The same people, however, should evaluate the same requirements across all vendors to ensure a fair comparison.

If your organization requires an RFI (request for information) or RFP (request for proposal), those need to be compiled and sent to the vendors as the starting point for vendor evaluations. These documents allow your team to gather the same information from all vendors. Put simply, these are documents that list your requirements and ask the vendors to indicate if they address them natively within their software, through third-party integrations, or not at all. Our RIM Buyer’s Guide provides a template that can be used as a starting point.

Whatever your evaluation process looks like, your team needs to see the software. For systems as large as RIM solutions, you may need multiple demonstrations with the vendor and your team. Work with the vendor to determine how the process will work, but typically you will have an overview demonstration and then separately schedule individual sessions, if they are needed, to cover specific features or answer additional questions. While everyone on the evaluation team should attend the initial demo, additional sessions should be scheduled only when needed and only with those team members required. The following can help ensure a smooth process:

• Communicate clearly to your team what they are responsible for during the demo. Who is taking notes? Are different team members responsible for evaluating features in different areas of the software?
• Set expectations with the vendor ahead of time and maintain control of the demo agenda. The software vendor will know what sequence works best for their product, and you should allow them to guide you. However, you will want to steer them away from spending too much time on features that are not important to your team.  
• Ask the vendor to keep track of unanswered questions or features that you were unable to see. The vendor should be expected to follow-up on these items.

Rate and rank vendors

Using your requirements list, each vendor should be rated for each requirement. Require vendors to clearly indicate if a requirement is met “out of the box,” requires custom development work, or is not supported at all. Consider a scale of 0-5, with 0 being a feature the vendor does not support. Multiplying the rank by the importance of the feature (3 – Critical to have, 2- Important to have, 1- Nice to have), will give you a good picture of where each vendor ranks.

There should be some subjective items that are used in rating, also, such as how easy you believe the vendor will be to work with. Once the vendors are rated, the team should meet to discuss differences between team members' ratings and then to agree on where each vendor ranks. It is important that all requirements are considered and weighed appropriately while ranking vendors. For example, selecting the system with the best price may leave you with a vendor that doesn’t have the resources to support your implementation.  

Negotiate and purchase

Hopefully, you will be able to successfully (and quickly) negotiate with your top-ranked vendor. However, it does sometimes happen that an agreement cannot be reached with the initial vendor for reasons that may include pricing adjustments or unexpected changes to the availability of their resources. In this case, you will need to move on to your second choice.

For more information on specific criteria for purchasing a RIM system, read our RIM Buyer’s Guide.

‍

‍

What is Software as a Service (SaaS)?

SaaS, or Software as a Service, is a software delivery model in which applications are hosted by software vendors and provided to users via the internet.  The use of SaaS software has skyrocketed in recent years, with an estimated 70% of business software being used falling into the SaaS category 2022.  

Also known as a “cloud” delivery model, SaaS solution providers either host the application and related data using their own servers and computing resources or use a cloud service provider, such as Amazon Web Services (AWS) or Microsoft Azure, to host the application in the provider's data center. The hosted application is then accessible to any device with a network connection and is usually accessed via a web browser.  

Many SaaS software systems use a multi-tenant architecture in which a single instance of the software serves many subscribers, or users. Customer data, while stored centrally, is logically separated to ensure security and prevent co-mingling of data. However, for software systems that require validation, such as regulatory information management systems, a single-tenant system can offer greater data security along with the flexibility for teams to fully validate software releases before adopting them.  

What are the benefits of Saas?

• Reduced hardware costs – SaaS removes the need to install and maintain software locally, which reduces the cost of servers and related infrastructure.
• Subscription payments – SaaS software is typically billed on a monthly or annual subscription basis. Not only does this allow companies to spread out the cost of the system, but a subscription model also allows for shorter commitment periods vs. a large up-front capital expenditure (CapEx vs OpEx). The SaaS model also holds software providers more accountable than other models given that the user has the option to cancel or not renew a SaaS subscription, leading to higher levels of service and support.  
• Scalable usage – SaaS service providers automatically scale the resources needed to support users and can provide additional services or features on demand.
• Seamless software maintenance – SaaS software can be automatically updated with new features and, when necessary, patched with bug fixes. While this simplifies software maintenance from the user’s end, users in the medtech industry should expect to be able to test and validate software updates before they are installed on their system.
• Accessibility – Accessed via the Internet, SaaS solutions are available from almost any device in any location.
• ‍Reliability – Because SaaS solution providers have extensive resources, beyond what any individual company would normally have, SaaS software typically has very high reliability and availability in comparison to in-house systems.  ‍
• Security – SaaS solution providers deliver state-of-the-art security and privacy at a level that is difficult for individual companies to maintain.  

As a regulatory professional, what questions should I ask a SaaS vendor?

How are software updates managed?  

SaaS software providers generally install new features, bug fixes, and other updates automatically. However, medical device regulations, such as the FDA’s 21CFR Part 11 and EU’s MDR, require medtech companies to validate any software that they are using that is integral to their quality system or otherwise might affect the safety or efficacy of the devices which they manufacture.  

Therefore, a SaaS company providing solutions to the medtech industry should offer the ability for subscribers to review and validate software updates before they are installed. This is often done by providing a transition period during which the software vendor allows access to the new version of the software and the existing version. In addition, many software providers, such as Rimsys, will turn off new features by default and allow the user to enable the new feature if and when they want to begin using it. Be sure to understand what, if any, updates will be installed without this review period. Some software vendors will push small bug fixes and minor features automatically.  

Clients should be notified of any updates in a timely manner and, ideally, have access to a non-production version of the software for testing purposes. Be sure to understand how often updates will become available and how often those updates are expected to trigger a re-validation of the system. While every medtech organization will have their own specific policies on this matter, Rimsys communicates the expected impact on software validation of each new release, and the reasoning behind whether an update will or will not require a new validation.

Do you assist with software validation?

While software validation is ultimately the responsibility of the medtech company using the software, there is a lot that a software vendor can do to assist with this process. The software vendor should be able to provide documentation concerning the design, development, and testing of the systems that they are providing. In addition, some vendors will provide test cases that can be used by your own team to test and validate the software. These test cases significantly reduce the burden on the in-house validation team.  

SaaS vendors should also be able to provide medtech companies with their Computer Software Assurance (CSA) plan. In most cases, the FDA and similar regulatory agencies are looking for compliance with a CSA plan in lieu of the more onerous Computer System Validation (CSV) process that was traditionally followed in the past.

How do you handle data security?

This should be an easy question for any SaaS provider to answer. Whether the data is being hosted by a cloud service provider, such as AWS, or by the vendor themselves, there should be a documented data security plan. As part of that plan, the software vendor should be able to demonstrate how data is protected through physical and logical separation within the system and the application of robust encryption to the data both at rest and in transit. Additionally, the vendor should have a well-documented information security management system (ISMS), which can be further evaluated by third parties for adherence to SOC 2 Type 2 and ISO 27001.  

What is your uptime SLA?

SaaS providers should provide uptime guarantees in writing, typically within a Service Level Agreement (SLA). The majority of SaaS business software providers will offer uptime guarantees between 95% and 99%. For mission-critical solutions, such as RIM systems, expect guarantees at, or close to, 99%.

What happens to our data if we leave?

Because you are not storing your data locally, be sure to understand what will happen to your data if you choose to terminate your contract with a SaaS solution provider. You should be able to access your data after termination, download data prior to termination, or both. Ask if you will be charged for this.

Can I access and report on all of my data, all of the time?

It is important to know that you will be able to access all of your data at any point in time, especially during an audit or inspection. Can you create reports that reference any and all data fields in the system? Will older data be archived automatically at any point? Are there API’s available to allow other systems to access the data?

What are your fees based on?

SaaS companies can base their fees on a variety of factors, including data usage, number of users, and features used. Be sure to understand all of the factors that may affect your subscription fees now and in the future.

SaaS terms to know

• SLA: An SLA is a “Service Level Agreement,” which serves as the contract defining what the SaaS vendor is providing and what the customer expects to receive. Among other things, the SLA will define uptime guarantees, what counts as downtime, the procedures followed in the case of a data breach, and how termination of the contract is handled.  
• Uptime: Uptime is the percentage of time during which the SaaS software is operational and available to subscribers. The specifics of how uptime is measured should be part of the SLA. Downtime is the converse of uptime.
• API: API, or Application Programming Interface, is a set of definitions and protocols provided by software applications to allow data sharing and integration between applications.
• Module: A part of the software platform that is dedicated to a specific function and outcome. SaaS pricing is often organized around the purchase of one or multiple modules.  
• Feature: Specific functionality in the software that comes together to achieve an outcome.  

Want to learn more about SaaS solutions for regulatory information management? Contact us to schedule a custom demonstration.

The International Medical Device Regulators Forum (IMDRF) developed a UDI framework for a globally harmonized system for the identification of medical devices. Adopted in principle by regulatory authorities in many countries, the implementation of UDI regulations and supporting databases is at varying stages of implementation across the globe.

UDI Components

Establishing a UDI strategy involves understanding requirements for both labeling and regulatory database reporting in each country in which your devices will be marketed.

UDI labeling

The UDI is typically presented as a barcode label on device packaging or the device itself (depending on specific requirements). The UDI consists of two major components:

• UDI-DI - This is the static portion of the UDI which identifies the manufacturer along with the specific device version. The UDI-DI (device identifier) is assigned by an approved organization, such as GS1, and contains a company prefix and the manufacturer's internal product code. The UDI-DI is the primary identifier to be used in looking up device attributes in country-specific databases and is assigned prior to placing a product on the market.  
  As GS1 is widely recognized as an issuing agency across global regulators and industry, the UDI-DI is often referred to in the GS1 nomenclature of Global Trade Item Number (GTIN).
• UDI-PI - This is the dynamic portion of the UDI which is assigned by the manufacturer and identifies a manufacturer’s lot number, serial number, manufacturing date, expiration date, or other data as required. The UDI-PI actual values do not appear in country-specific UDI databases, but these databases often require information about the type of data that the UDI-PI represents on the device label.

UDI regulatory database requirements

Many countries have established, or are in the process of establishing, databases to store UDI data. In the United States, use of the Global Unique Device Identification Database (GUDID) is mandated for medical devices. In the EU, EUDAMED consists of multiple modules with one specifically established for UDI. The UDI module is currently available for voluntary use, with mandated compliance scaled in transitional periods through 2026.

Currently, the US GUDID database provides for machine-to-machine (M2M) transmission of data, allowing manufacturers to upload product UDI data directly into the database. The EU has established requirements for M2M transmission as well, but these requirements are not finalized. Most other countries do not have M2M capabilities at this time. ‍

Universal UDI ®

While each country defines specific UDI data requirements, there is a core set of data that is consistent across many markets. At Rimsys, we refer to this data as the Universal UDI® data. Storing Universal UDI® data separately from any country-specific UDI data is an important data management strategy. This ensures that data is single-sourced and consistently applied across submissions to regulatory UDI databases and in other locations in the manufacturers’ quality management system where the data may be needed.

When storing UDI data locally, consider that the same information may be required in different formats in different country regulatory databases. Currently, Rimsys supports the specific data requirements of the US, EU, Saudi Arabia, China, South Korea, and Singapore. Additional countries, which are expected to have similar IMDRF style requirements, will be added as those databases are established by regulators and brought to the industry. Some examples of these countries are Australia, Switzerland, UK, Brazil, and India.  

Note that outside of the US’s GUDID, UDI databases are in flux in most countries. This means that having a central RIM system to track known and well-established UDI data is increasingly important.

Machine to machine transmission of UDI data

Machine to machine (M2M) transmission is the process in which data is transmitted from a company’s internal database, typically a RIM or PIM/PLM system, to the regulatory UDI database. Currently, the GUDID database in the US is the only database for which machine to machine (M2M) transmission has been fully developed and is fully supported. Rimsys offers M2M data transmission for GUDID and is currently working to establish M2M transmission with EUDAMED.

Synchronizing UDI data

It is important to note that there are really no requirements for a medical device manufacturer to keep a quality record of the UDI data submitted to regulatory databases (the official data of record is the data that has been reported to and is retrievable from the regulatory database). This means that it is up to the manufacturer to declare the actual source of data for the quality system and to ensure that data is in sync where required. 

One of the strategies that can be used when implementing a new RIM system, such as Rimsys, is to export data from GUDID, EUDAMED, and other regulatory UDI databases. That data then forms the basis for the UDI data that is input into the RIM system, ensuring consistency in the application of data across other countries’ UDI databases. 

Maintaining and updating submitted UDI data

It is important to implement procedures to ensure data in a product’s UDI record is consistently applied throughout your internal systems as well as with the various regulatory databases. While a single data point should be stored in as few places as possible, everything should be done to minimize the chances that data will get out of sync.

Any product data changes must be evaluated for, among other things, the effect on existing UDI data submissions to regulators. The data changes must be evaluated to determine if the UDI-relevant data can be updated in impacted regulatory databases or if an entirely new UDI-DI and record must be reported. In some cases, such as a change to the product’s catalog number or contact phone number, an existing UDI record may simply need an update. In other cases, such as a change to the sterilization requirements, a new UDI-DI and a new record may be required.  

EUDAMED considerations

The EUDAMED database and M2M requirements for UDI are still not finalized, but they are much more static than they were even a month or two ago. We believe that it is beneficial for medical device manufacturers to establish and organize the data needed to submit their products to EUDAMED as soon as possible.  

Legacy devices are those medical devices and In Vitro Diagnostic (IVD) devices that are compliant to previous directives (MDD, AIMDD, IVDD) that are being placed on the EU market under the allowed transitional period. With the compulsory application of EUDAMED identified in the 2026 timeframe and the expiry of the transitional period in 2024, there was no need for manufacturers to register legacy devices in the EUDAMED system. Today, with the extension of the transitional period for the certification of devices under MDR and IVDR through 2027, legacy devices may now again be subject to submission of UDI data in EUDAMED.    

There will be a 24-month transition period for manufacturers to apply UDI data to EUDAMED once all modules go live. However, if you have any type of action requiring interaction with the Vigilance module of EUDAMED, the required UDI information for those devices must be present in EUDAMED prior to that interaction. The Vigilance module is intended to manage all types of vigilance reports, including Manufacturer’s Incident Reports (MIR) and Field Safety Corrective Action (FSCA) reporting. This also includes and requires post market surveillance reporting submission to the Vigilance module such as Periodic Safety Update Reports (PSUR) and Post Market Surveillance Reports (PMSR).

Manufacturers may be surprised with a shortened transitional period for compliance to EUDAMED’s UDI module due to this requirement and should place priority on higher-risk devices due to the increased likelihood of an interaction with EUDAMED’s Vigilance Module.

For additional resources, watch a replay of our webinar, Why UDI is a regulatory concern, not just an operation process - or read our eBooks, The Ultimate Guide to EU MDR/IVDR UDI and The China NMPA UDI System.

‍

Staying on top of changing regulations and expectations is challenging for MedTech regulatory professionals around the world. The following list is some of the educational resources that are most used by RA teams to stay current. With the exception of RAPS, we focused primarily on resources provided by regulatory agencies directly. Rimsys does not endorse or validate information on these sites.

Professional Organizations

Regulatory professional organizations provide a combination of free and paid training courses and certifications.  

RAPS

The Regulatory Affairs Professionals Society (RAPS) is the first stop for most regulatory professionals looking for education and certification:

• Courses (open to non-members) - includes RAC exam prep, online courses, webinar replays, and training bundles  
• Learning portal (RAPS members only)
• Connect RAPS (RAPS members only forum)

TOPRA

TOPRA is a professional membership organization for individuals working in healthcare regulatory affairs. TOPRA was founded in the United Kingdom and is active in Europe.

• Regulatory Affairs courses and webinars
• Conferences and networking events

Regulatory Agencies

United States (FDA)

The FDA offers a variety of free educational resources, including live and on-demand webinars, along with written documentation:

• Training and Continuous Education home page
• Continuing education programs
• CDRH Learn
• Guidance Webinars

EU Medical Devices Sector

• Event list (including educational webinars)
• Publications (including step-by-step guides)
• EUDAMED information center

Canada

• e-Learning courses on how medical devices are regulated in Canada

Singapore

While these are not training modules, the following free “tools” are available from the Singapore Health Sciences Authority:

• Is it a medical device?
  Answer a series of questions to determine if your device is considered a medical device in Singapore.
• Risk classification tool
  Answer a series of questions to determine the risk classification of your medical device.
• Registration and licensing requirements
  Answer a series of questions to determine the correct registration route.
• Medical device grouping tool  
  Answer a series of questions to determine if you can group your medical devices together for registration.

Additional third-party resources

Some sites that we find particularly useful. Note that Rimsys has no business relationship with these sites.

• Medical Device Made Easy podcast
• Medical Device Academy

Paid Resources

Notified Bodies and other large consulting firms can provide detailed training options, but these organizations are in the business of providing expert consulting and education, so these options are not free. Those listed here provide individual, self-service, training courses that are charged per-session:

• TUV SUD
• BSI

If you have any additional resources that you think we should include here, please connect with us on LinkedIn or Twitter!

Medical device manufacturers seeking to place a new device in the U.S. market through a 510(k) submission are required to identify a legally marketed device that is substantially equivalent to the new device – i.e.: the predicate device. Selecting the correct predicate device is extremely important in ensuring the success of your 510(k) submission. New devices without a predicate are automatically classified as Class III devices requiring a premarket authorization (PMA) submission (although those with a lower risk profile can apply for reclassification through a De Novo request).

Predicate device requirements

A predicate device is used in a 510(k) submission to demonstrate that the new device to be marketed is safe and effective. This is done through establishing substantial equivalence between the predicate device and the new device. The predicate device must be a legally marketed device approved through a 510(k) submission, to which equivalence can be demonstrated. In identifying a predicate device, preference should be given to devices which are currently marketed in the U.S. and which have received 510(k) clearance relatively recently.

Predicate devices may be:

• Postamendments devices – devices marketed after May 28, 1976. The majority of 510(k) submissions claim substantial equivalence to a postamendment device.
• Preamendments devices – devices which were legally marketed in the U.S. before May 28, 1976 and which have NOT been significantly modified and for which a regulation requiring a PMA application has not been published by the FDA.
• Either postamendment or preamendment devices which are no longer marketed in the U.S. In this case, the predicate device cannot be a device that is, or was, in violation of the FD&C act.

Substantial equivalence

A medical device is considered substantially equivalent to an identified predicate device if the devices share an intended use and meet either one of the following:

• Shared technological characteristics, OR
• Different technological characteristics that do not raise different questions of safety and effectiveness and the safety and effectiveness of the device is demonstrated by information submitted to the FDA.

It is also important that the predicate device selected does not use outdated or superseded technology, which means that newer devices tend to be used as predicate devices. Note that while substantial equivalence needs to be demonstrated, the devices do not need to be identical. However, if the FDA finds that substantial equivalence has not been demonstrated with the identified predicate device, the applicant may:

• Resubmit the 510(k) with new data
• Request a Class I or Class II designation through the De Novo classification process
• File a reclassification petition
• Submit a premarket approval application (PMA)

How to find a predicate device

The FDA provides a 510(k) database containing all devices cleared through the 510(k) process. This database is updated monthly and can be filtered by device class, product code, applicant name, and other information.  

Before searching the 510(k) database, the device and product classifications should be determined. The best way to find the correct classification of a new device is to use the Product Classification database, which can be filtered by device name and review panel, along with submission type, product code, device class and more. Searching the 510(k) database with the correct 3-letter product code is typically the most effective way of finding potential predicate devices.  

Using a reference device in a 510(k) submission

The identification of a “reference device,” in addition to a primary predicate device, can be used to “support scientific methodology or standard reference values.” A reference device cannot be used in lieu of a primary predicate device and the FDA will evaluate the appropriateness of the reference device.

Note that prior to a 2014 guidance, the FDA allowed for “split predicates,” or the use of one predicate device to demonstrate equivalence in intended use, and another to demonstrate equivalence in technological characteristics. The current guidance finds the use of split predicates "inconsistent with the 510(k) regulatory standard.”

The importance of selecting the right predicate device

Selecting the right predicate device is critical to ensuring that your device can be brought to market through the 510(k) pathway. Selecting the wrong device will result in delays to the regulatory approval process. If an applicable device with current technology cannot be identified, other pathways, including De Novo request and PMA submissions, should be considered. For additional information, read The Beginner's Guide to the FDA 510(k).

‍