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.
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:
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 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.
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 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.
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.
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:
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.
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.
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.
Considering the above information, the primary arguments you can make against building a RIM system in-house are:
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.