We all know the legislative deadline for submitting pharmacovigilance data as IDMP (Identification of Medicinal Products), is July 1st of 2016. We only have just a bit over a year time to become IDMP ready and prepare for the submission of medicinal product information. xEVMPD (Extended EudraVigilance Medicinal Product Dictionary), the current legislative format, was “simple” and “easy” to compile compared to the large and complex data structures for IDMP. Most of you have probably read the five relevant ISO IDMP guidelines ISO 11615, ISO 11616, ISO 11238, ISO 11239, ISO 11 240. They provide all necessary details on required data, but also we all know that these ISO guidelines will be followed by official and final EMA and NCA implementation guidelines (later this year?) that will describe what exactly we will have to submit on July 1st 2016. Let’s look at the facts first to determine what we can do to be prepared:

Fact is, that IDMP will become mandatory for every MAH (Marketing Authorisation Holder). Fact also is that IDMP will require the collection of much wider data categories such as clinical particulars, medicinal products, manufacturers, marketing authorizations, packaged medicinal products and pharmaceutical products. The required data for these categories will come from different data sources. A primary source will be our own existing in-house systems such as legacy data sheets combined with data sourced in our internal regulatory information management (RIM) system and other internal sources such as the ERP (Enterprise Resource Planning) system. This internal data will need to be combined and synchronized with data from official databases such as the Global Ingredient Archival System (GInAS) for substance related data, the Unified Code for Units of Measure (UCUM) for strength definitions and the pharmaceutical dose forms, units of presentation and routes of administration (EDQM).

Let’s look at a very simple example and its complex implications, Ibuprofen 5mg: The substance itself would be described in the submission dossier. The IDMP relevant substance code would need to be extracted from GInAS and the strength terminology would come from UCUM. Within my IDMP system I will have to consolidate these different data sets and combine it to one compound data set, the IDMP data set. Conducting this data collection manually already for one single medicinal product can become time consuming. Let’s assume the very realistic scenario of a data change that is happening in one of the used source systems. If for example GInAS is applying a change but there is no notification in place that tells me to also update my IDMP compound data set in my IDMP system, things will become complex for me very quickly.

I honestly believe, the only real solution for managing complex compound data categories will be a regulatory master data management system. I would expect such a system to ensure automatic data updates via defined business rules as well as automatic data collection from any type of other internal source system. Acquiring and implementing such a system will involve costs, but once in place, it will provide all benefits of master data management. Publicly available studies confirm, that for today’s pharmacovigilance related pharmaceutical product management, up to 100 minutes per product per year are being used to simply keeping the data up to date. With the increased complexity of IDMP, this yearly effort will become 3-5 times as high. According to a recent study conducted by the University of Leipzig, Germany, it is estimated that via master data management, the yearly maintenance time for comparable data records such as pharmaceutical product data, can be reduced to 20 minutes per year.

Therefore when looking at the complexity of IDMP, the logical solution is the implementation of a regulatory master data system. Besides fulfilling IDMP compliance requirements, it will also provide tremendous savings within my regulatory information management. I am able to capture on benefits such as eliminating data duplications and obfuscation while increasing reporting capabilities as well as automation potential. It ultimately results in a single source of truth for all my regulatory data.