Learn about 2 key RIM components

RIM Blog Series – Part 4: The Special Relationship Between Product and Process Data

BY Sue Metz, Vice President, Technical, Parexel - 8.15.19 -

In my previous articles I talked about the history of RIM, structural must-haves, and provided a quick list of these features for a RIM system.   If you missed them, you can find all the articles here (history of RIM, structural must-haves, and a quick list of these features for a RIM system).

I see RIM as having 2 separate yet symbiotic pieces which I refer to as Product and Process.   Both pieces are important in their own right, but in a robust RIM system they work very closely together to provide the bottom line value of end-to-end RIM.   In this article I provide an explanation of what I mean by Product and Process.

Information Management Paradigm to hold Product data

An information management paradigm historically governed by a database is the underlying structure forming the heart of a RIM system.   More and more we are hearing that companies use their RIM platform as a Product Master File or a Product Master Data Management tool (more to come on MDM in a later paper).  The data captured must consequently be robust and agile.   I realize the terms robust and agile are subjective. Below is what this means to me with respect to RIM.

Over the past 15 years, Life Sciences products have changed in many ways.   Innovations in technology with respect to delivery mechanisms, breakthrough medicines, and even the way clinical trials can be conducted, have all contributed to increased complexity in the definition of products. 

I remember when a transdermal patch to deliver medication was seen as innovative.   Now we have devices such as ingestible sensors for disease diagnostics and monitoring, and glucose monitoring patches to painlessly monitor glucose levels.   The framework from which to track product data must be robust enough to define and manage new delivery mechanisms, new devices, and new breakthrough medicines without a great deal of disruption to the RIM system.   Agility in design, as well as in the system’s ability to easily update structure, is key.

Adding to the complexity is that each life-science product may have its own nuances (data details) depending on where it’s manufactured, how it’s packaged, and which agency is governing the approval to market the product.   What this means is that the structure of your RIM system must be able to track many different nuances in accordance with specific agency requirements and approvals.   A simple example is: a product may be approved for one shelf life in one country, but it may be approved for a totally different shelf life in another country.

I’m sure many or most of you already have some knowledge about IDMP (Identification of Medicinal Products), but basically IDMP is a set of ISO Specifications defining a conceptual data structure for Medicinal Products.   What’s great about it is that it’s a standard, something that didn’t exist back when we were first developing a RIM system.   With agencies looking to embrace the standard, or at least pieces of the standard, for submissions of regulatory data, RIM systems should have a goal of including some or all of the data concepts into their Information Management Paradigms to manage the product data details I’ve referred to above.

One last comment on the level of granularity is that data describing products must be tracked over the life of the product as it is approved in each country where it’s marketed.  This adds a time dimension to the structure to provide you with a snapshot in time to see how the product changes or progresses throughout its lifetime – I’ll cover that a little more below.

Information Management Paradigm to manage Process data

In addition to the Robust and Agile product structure requirements, process data elements are needed to track the regulatory activities that take place for a product to be placed on the market and keep it there.  Take this basic high-level submission process as a starting point:

Infographic displaying a high level submission process.

At a high-level, companies plan their submissions, prepare their documents, create published output, submit the published output to an agency, likely go through a question and answer period, and eventually achieve approval to sell the product based on all the information provided to the agency.  These activities speak to the process of getting and keeping products on the market.  The functionality and features needed to support this process are absolute must-haves for a RIM system.

To me, the most important kind of functionality supporting the submission process is the planning and tracking of milestones.   Milestones are the steps defined in the regulatory planning and submission process.  When setting up a submission plan, the regulatory strategist will know which milestones need to be included in the plan.   

Milestones are typically based on factors like the country or region where the submission is taking place.  In the case of Europe, the EU procedure being used will also be a factor.   Milestones for an initial application are likely very different from variation and supplemental milestones.  Clinical Trial submission milestones are different from Marketing Authorization milestones.  The type of product (ex:  vaccine, biologic, device, etc.) often needs to be taken into consideration and one last type of milestone we often see is the tracking of internal steps or hand-offs that occur.  A simple example of an internal milestone is the transfer of submission ownership or dispatching of the submission to an affiliate.

As if defining the steps/milestones to be tracked isn’t enough – the tracking of each milestone should also show the date a milestone is expected to be achieved, and the actual date it was achieved.  I’ll stop here and as I mentioned above, more detail will be addressed in a future article.

In my next article, I’ll define functionality a system should have to be considered a comprehensive RIM tool.  I’ll be organizing the functionality in a module way especially since that’s how folks often think about RIM, but it is important to note that all of these “modules” must work together in harmony.

We are always available for a conversation.


We are always available for a conversation.


Communication Preference

Communication Preference