Blogs

Selecting a RIM system for your medical device company

Wendy Levine

June 15, 2023

4 min read

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:

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.

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.

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.

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:

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

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.

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

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:

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.

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

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.

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.

‍

Share this post

Featured

Rimsys Announces Rimsys AI to Eliminate Repetitive Tasks and Enhance Decision-Making for MedTech Regulatory Teams

Rimsys, the leading Regulatory Information Management (RIM) platform for the MedTech industry, today announced the launch of Rimsys AI, a suite of embedded artificial intelligence (AI) agents.

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.

‍

Why we developed Rimsys from the ground up

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.