For years, Sara worked in a hospital, making care possible for others. Now, after being diagnosed with breast cancer, she was the one in need of care.
As discussed in my previous paper, RIM started about 15 years ago and is a discipline that supports Life Sciences Regulatory Processes.
Originally RIM was designed as an enhancement to regulatory publishing. However, the need to have an underlying data structure to keep track of submissions and connecting submissions to data fields was a new concept in 2003. Being able to do all of this in a “web-enabled” environment instead of a client-server environment was revolutionary. It changed the way regulatory staff worked and made submissions and product connections that were not previously possible. Because it was web-enabled the software had zero-footprint, meaning that the users did not need to install anything on their PCs, which was a win for IT organizations. Users and management were able to see a holistic view of what was happening because everyone who had access (security aside) were accessing the same data and the same system, using the same concepts and definitions.
eCTD was new, and people had to get their heads around the specification structure, technology components, document granularity authoring and the concept of submission lifecycling. The M2 ICH subgroup was formed to get more of a handle on how to interpret the eCTD standards. ETICS (eCTD Tools Interoperability Compliance Study) was working to better understand and figure out how to get everyone on the same page with respect to the eCTD tools being developed. If vendors weren’t using the same concepts, interoperability to take eCTD output created by one tool and use in a different tool would be a nightmare. Along with any specification like this, processes needed to be defined to support these new types of submissions. This is when Regulatory Information Management was born. It was important for everyone to understand what was needed to support the concept of a lifecycle in general. Things like which actual submitted content (now called sequences in eCTD) were related for the intended regulatory action(s) requesting approval, because as you know it very often takes more than just one sequence to get to a final approval. There was a defined beginning and end to a regulatory action, with all kinds of things happening along the way. It was important to manage the processes and regulatory information within the concept of a lifecycle.
Capturing this information is all well and good but what is the purpose, how does this information essentially help a company? Having systems and tools able to support eCTD and lifecycle publishing was only the beginning. Organizations also wanted to be able to run queries and reports on various pieces of information that were buried deep in a submission. Wouldn’t it be great if I could run a report to show how many submissions I would have to make if my ingredient manufacturer went out of business; or I just finished tests for a longer shelf life on product x in package abc – show me all the licenses approved for that package where I can file for the extended shelf life. These are just a couple of simple requests that seem like no-brainers now, but back then, being able to get this information through queries and reports would save so much analysis time, helping regulatory make informed decisions more quickly. This truly was a revolution!
We worked with our clients to define and develop process flows that would bring eCTD to life, and in turn used the process flows to develop a system in support of the flows. Developing the system to support regulatory processes is the reason why LIQUENT InSight continues to be a leader in RIM.
For our LIQUENT InSight platform, we developed the concept of an Event to define the regulatory action (reason for the submission in the first place) and related all of the submission (Sequences) to the Event. This concept shows the true effort it takes to get approval as well as what data may have changed along the way to approval.
If we’ve learned nothing else over the years, we’ve certainly learned that the discipline of Regulatory Affairs and Regulatory Operations is very complex. To simply state what a RIM Platform must do in order to be called a RIM Platform does not really do it justice. None the less, I’ll try my best to define the attributes of a RIM Platform.
Historically this structure was governed by a database. The agility of the structure is very important since there are many different kinds of life science products needing to be tracked. It’s also important to consider what attributes are needed to truly define a different type of product and what’s needed at the various levels of defining a type of product. For example, data fields needed to define a Medicinal Product are different than what’s needed to define a Medical Device and are different than what’s needed to define a Vaccines and are different than what’s needed to define a Veterinary Product, and so on. As products become more innovative, the complexity continues to grow.
Something I found interesting when I began leading RIM workshops was that there didn’t seem to be 1 answer to “what is a product”. And depending on the types of products discussed and the different countries or even departments that were included in the workshop, there were often quite a few variations. Having IDMP as published guidance that can be rallied around has made this discussion much easier.
Process data covers things like dates and statuses as well as workflow information to track users performing various tasks. The process data must have the proper relationships and take into consideration the nuances of a workflow – for example a task in a workflow can often go in circles before coming to completion. I’ll get into more detail about data in an upcoming paper, but in order to understand what makes up a RIM system it’s helpful to understand some of what’s needed from a data perspective
Parexel takes pride in our ongoing endeavor to engage our clients with the ever changing and fluctuating needs of the Regulatory Environment, technological advancements to meet our client’s various needs.
In Part III of this paper I’ll describe the features or modules that are “must haves” for a RIM system.