Learn about the necessary features for a successful RIM platform

In my previous articles (Part 1, Part 2) we talked about the history of RIM and structural must-haves for a RIM system.

It’s also important to know the questions that will be asked of the data as well as ensuring that details around the various regulatory specifications are covered.  As the saying goes, the devil is in the details.  Sometimes it’s hard to decide what may be overkill vs. what’s absolutely needed that may seem like overkill.

Looking at the basic features of a RIM platform, holding aside usability and data details for now, a RIM platform must have the following features:

• An Information Management paradigm historically governed by a database, with the structure as described in my second paper.  Companies often use their RIM platform as a Product Master File and or a Master Data Management tool (more to come on MDM in a later paper), so the data captured must be robust.
   
• Product and Registration Management is needed to track licensing information across geographies and to track specific details related to the licenses.  Even in European Procedures, where the spirit of the Procedures is to agree on as much as possible, there are many differences that must be taken into consideration.
  ​​
• Submission Management is needed to track the planning, submission creation, sending and approval of regulatory actions both for individual agency submissions and across geographies.
   
• Dossier Planning is needed to create and manage assemblies to support global submissions.  Having the ability to attach the right documents in each Assembly Package of Content for a specific region or purpose (and therefore the ability to connect to eDMS’s and fileshares) is key to this piece of RIM. 
   
• Submission Publishing puts the assembly content in a compliant published output to send to the authorities. Anything to streamline this process is a real bonus.  Look for tools that can publish globally, also those that can publish electronic, eCTD and paper from a single assembly – this is a huge time saver.
   
• XEVMPD functionality to support the EMA’s Article 57 mandate.  The data collected for XEVMPD should be a natural consequence of the regulatory business process.  Creating the XEVMPD file to submit to the EMA should not only be intuitive but must also provide a file that is compliant against the XEVMPD technical specifications to ensure it won’t be rejected.  As well, functionality to process the EMA’s acknowledgements must be included in order to complete the XEVMPD circle.

A bit new to RIM is support for IDMP, which is twofold.  The Information Model needs to be able to hold and track data to be sent to authorities. Eventually, when guidance is provided by agencies, RIM will need to create IDMP files based on each agency’s requirements.

IDMP requirements do not stop there.  Unlike XEVMPD where data is sent to the EMA after regulatory submission approval, IDMP files will be included as a file in a regulatory submission and not just initial or final submissions.  The IDMP file will be included in all submissions making it part of the Lifecycle Operations. Data updates will be provided to agencies for the entirety of a regulatory event with the intent that reviewers will use both documents and data for their regulatory assessment.  This means the RIM system must create the IDMP data file for each submission, have the ability to include it in the published output, and must also track the updated IDMP data against each submission (sequence).  The system must be able to manage and show the lifecycle of the data in a holistic way.  Plenty more to come on IDMP in a future white paper.

In my next article, I’ll go into more detail about each of the features described here.