Your regulatory team needs dedicated software to manage market entry activities, maintain regulatory integrity, and ensure post-market compliance. While small medtech companies often start out managing regulatory data in spreadsheets, this quickly becomes unwieldy.  

Can you develop a system that tracks product information and registration expiration dates? Yes, absolutely – especially if your medical device company has internal software development capabilities as part of your IT team. However, a strong RIM system will also give you the ability to completely manage market entrance documents and regulatory workflows. And building a RIM system will also require significant input from your regulatory and quality teams, in addition to IT resources.

Admittedly, we are a bit biased here, but this is the reason we started Rimsys – to create regulatory order in the medtech community and help regulatory professionals automate processes and digitize information so that they can spend more time on activities that truly make a difference for their organizations.

Before you begin a project to build your own RIM system, or to modify an existing system to meet regulatory needs, consider the entire size and scope of the project. This article discusses the common areas where custom-built RIM projects can run into unanticipated costs or issues.

Meeting software regulatory requirements

RIM systems are the source of information used by your regulatory team to provide accurate and timely information to regulators and auditors to ensure that your organization is compliant with existing regulations. This means that the software system itself needs to meet certain requirements. To ensure a compliant and secure RIM system, you need the following:

• ISO 9001 certification

Your organization may already be ISO 9001 certified, but in developing your own software to manage internal data and processes, you are greatly expanding the scope of your ISO 9001 project.

• ISO/IEC 27001 certification

ISO/IEC 27001 is the global standard for information security management, including data protection and cyber security and resilience. You will need to obtain ISO/IEC 27001 certification for your RIM system.

• 21CFR Part 11 compliance (US) and EU annex 11 (EU)

21 CFR Part 11 is the portion of US federal regulation that addresses electronic records and electronic signatures as related to FDA processes and documents. The EU Annex 11 is the equivalent regulation in the EU. A good RIM system is designed with Part 11 and Annex 11 compliance in mind and can easily be validated to the regulations. You will need to demonstrate procedures that ensure all electronic records kept in the RIM system are controlled, authentic, and can be verified. Features such as data audit trails and specific electronic signature requirements need to be implemented.

• SOC II Type 2

SOC II Type 2 may be used in place of ISO/IEC 27001 to demonstrate suitable data security, particularly in cloud-based systems. SOC II Type 2 reports prove a company’s controls, but are not a certification provided by an independent registrar. SOC II Type 2 also requires an Informational Security Management System (ISMS), which is the framework focused on risk management and risk mitigation.

• GDPR compliance (EU)

While often associated with email marketing activities, the EU General Data Protection Regulation requires companies that store any information about an EU citizen to have specific safeguards in place. In particular, if your RA team includes EU citizens then their personal data is subject to GDPR and, among other things, they have the right to request their data is deleted from the system if they leave the company. All personal data needs to be protected from outside access as well.

Reducing overall cost of ownership

Building a RIM system from scratch or building RIM features into a QMS or PLM system is not a one-time endeavor. Consider the following on-going activities that will be required:

• Addressing regulatory changes

Global medtech regulations are constantly changing. For example, Rimsys created an entirely new module to handle Unique Device Identifier (UDI) requirements as countries announced compliance dates related to UDI labeling and databases. In this example, and in others, each country has different requirements regarding the data that needs to be stored, the format of that data, and the ways in which it is to be reported.  

A RIM system is not just a software development project. It requires the attention of regulatory professionals who can ensure that the system is properly handling the requirements of each country in which your device is marketed.

• Managing validation documentation

As with a medical device, a validated RIM system cannot be modified without following specific and documented procedures designed to ensure the system’s integrity. Any time a new feature is added, or a change is made to the system – whether it be a small bug fix or the addition of a major new function to address an updated regulation – the affected part of the system will need to be revalidated.

• System support  

The cost of maintaining and supporting a system as complex as a RIM system is significant. Such costs include not only the development costs, but the cost to train and support users of the system on an ongoing basis. If you are using internal resources, as many companies do, it is important that you include the lost opportunity cost for your development team in cost calculations. What are your developers not working on while they build your RIM system?

Consider carefully whether your IT team is positioned to become a software development team in the long-term. An IT team that is advocating for an in-house solution should be able to provide a plan for how often new features will be provided, how the system will be supported, and how an ongoing product roadmap will be managed.

Reasons not to build a RIM system in-house

Considering the above information, the primary arguments you can make against building a RIM system in-house are:

• Building a RIM system is not just a software development project. We will need to stay on top of changing regulations and requirements and be prepared to update the system frequently. Note that this is the primary argument to be made when an IT team is pushing for an in-house solution (a situation we see frequently).
• A RIM system built with internal resources builds your existing regulatory process into the system. Are you sure that those processes can’t be improved upon? A RIM system that is used by many medtech companies not only includes built-in industry best practices but will evolve to support new workflows and processes as the industry changes. A custom-built RIM system will have none of those advantages.
• The system will need to be validated and certified according to several standards and regulations, like our medical devices. This has the potential to significantly increase the scope of our ISO-related processes and other internal procedures.
• Purchasing a dedicated RIM system from a company that is solely focused on providing up-to-date functionality for regulatory professionals is a safer and simpler choice.

We have worked with a number of companies that ultimately chose to implement Rimsys after attempting to build a RIM system in-house. Faced with the unexpected complexity of the development project, they ultimately chose to go with a packaged solution. Be sure to carefully evaluate all potential costs, including on-going costs, when making the build vs buy decision.

‍