IDMP Data Management – Webinar Transcript with Wim Cypers

Wim Cypers has a long-standing experience in converting business requirements into application functionality and consistently showing industry thought leadership through speaking engagements at several industry events. He has applied his pharmacist training into a keen understanding of how to solve complex business issues.

For several companies, the announcement of the EMA that the DADI project will be the focus for regulatory data submissions has meant that they needed to revisit/realign their IDMP implementation projects once again. But is/was this really needed and if so, how can this be avoided going forward?

It cannot be denied that the approach needed to achieve compliance is shifting continuously but at the same time it is important to realize that the underlying ISO-IDMP structure remains the same. The benefits that implementation of ISO-IDMP brings to the life science industry remain the same. As such it is important that your implementation strategy is not only focused around achieving compliance, but that it also keeps in mind the internal improvements in data quality and processes the implementation of the ISO-IDMP standard can bring. Achieving compliance should be an important part of your strategy, but your strategy should not be controlled by compliance only.

During our webinar titled “Building a Flexible and Future-Proof IDMP Data & Process Management Strategy – Data Management”, Wim Cypers spoke specifically about data which is needed to be compliant and addressed challenges and tips which can help build or improve your IDMP repository.

Why should you read the transcript?

• To understand how you can manage your IDMP data in a way that will align regulatory, IDMP and compliance needs.
• To learn the data standardization requirements
• To explore technology considerations
• To explore the potential integrations with other regulatory process areas/functions to help identify and extract the data you need

A full transcript of Wim Cyper’s presentation is available to download and to read below. 

Before I get started on the actual topics around data management, I want to just talk about what are some of the drivers that you are facing today, or at least when I talk about the industry, what have I seen are some of the drivers that are happening? Of course, there are a lot of digital business transformations that are happening, which are essentially focused on the drive towards structured data. People are asked to be more efficient, more compliant, that is increase for data quality, accuracy, reduced administrative burdens are actually being faced. So, all these things are actually heading your way.

At the same time, we’re also talking about things like compliance. We’re talking a lot about compliance and specifically within the context of IDMP there is of course, a lot more that you need to comply with. But the last few years you’ve probably focused around xEVMPD. Since 2012, xEVMPD has been a mandate to submit product information. Since then, we’ve seen at least the EMA move into IDMP and SPOR.

What is that to IDMP? What if you’re not familiar with that? but of course that is a mandate to submit your product information, that mandate already existed with xEVMPD and with a new ISO IDMP standard. Well, new – it’s already been there for 10 years, but they are now implementing the new IDMP standards.

Now the first few elements I’ve primarily related to product information in regulatory, submitting your product information. But of course, one of the elements also talks about E2B (R3). So, we’re talking about submitting your product data, your IDMP data in an IDMP format. This is also going to be very relevant, not just for regulatory, it’s not just a matter of sending complaint information across. You will also have to find ways to start using that data. The same way that the authorities do and E2B (R3) essentially is an example of that. This is on the safety side, submitting adverse events reports that you can do there. But that has already made reference to elements like IDMP identifiers. This is something that I expect to happen somewhere next year or the year after. So, this is something which is not far away.

The key summary is that there is a digital business transformation happening. It has different shapes and forms and somehow as an organization, you will have to deal with this. Not just from a compliance perspective, but also specifically for internal efficiency gains that you can make.

Now there’s a lot of things coming your way. How can you make sense of those? There’s a lot of acronyms coming the way IDMP, DADI, eAF, FHIR messages, xEVMPD and SPOR. SPOR talks about substances product organizational referential, which is the name of the project within the EMA. A lot of the times when we’re talking about IDMP, especially in Europe, it’s being looked at as a European initiative, which it isn’t. I think it’s also important to be aware that the FDA is also working on this with respect to the SPL. But also in other countries, a lot of companies are looking at this, at implementing IDMP.

It’s not just a matter of being complaint in Europe. It is also something that you will need to do across the board. That’s purely from a compliance perspective, but hopefully at the end of this session over at the end of this series, you will also see that IDMP and implementing an IDMP program is not just about compliance. It’s also about making business processes more efficient.

Now the question that I typically get is why are we doing this? What is the benefit of this if it’s more than compliance? Where do we need to look at?

The slide below presented by the EMA shows you very clearly on how the EMA thinks about IDMP implementation.

It’s not just about regulatory. It’s not just about one element within that cycle. It is a process or it’s a standard, which is being implemented across the product life cycle. It goes from clinical all the way to marketed products all the way to the end of the life cycle and what EMA specifically is also doing, they’ve published certain documents on that.

EMA are integrating their internal systems. Why? Because they want to get a view of an end-to-end process. How is your product evolving? How is your product moving along across the life cycle? The main benefit of that is patient safety or the main driver for that for an authority is patient safety. Benefits of course are also important, but it’s about how can we make sure that we understand the product end to end from the beginning to the end and have a common standard that brings all those domains together, that brings clinical together with regulatory, together with safety and even also manufacturing in the end.

If you look at it from that perspective this is, if I had not told you that this was an EMA slide, you probably would also been able to look at it as saying, well, this could be an internal slide also. So, if you look at what the authorities are doing, there is no reason why as a life sciences organization, you could also look at IDMP as a way to integrate your different systems and make your business processes more efficient to make your data more efficient. This is a general introduction about what it is and how it works.

Strategy to Build a Future Proof Repository​
Some companies might already have a solution in place and might have a master data management solution in place. So, where that could function as a basis.

What would be the main requirements?​

• Ensure Regulatory compliance with different regulations and standards​ (Focusing on EMA/SPOR today but need to expand in other regions)​
• Integrate with department needs for data and processes​
• Expandable to accommodate phased implementation and growth​
• Increase efficiency and ensure ROI (invest in a wise solution)​
• Leverage on existing data as much as possible​
• Able to manage and reconcile differences in terminology​
• Expose only relevant information for specific domain​
• Able to leverage on external data sources (OMS, RMS, MedDRA, SRS etc.)

I have been involved in several projects and the most successful projects that I have seen are projects that focus on central repository to store in first instance, the IDMP product data and the related data. But also (because it is extendable) we can see that some companies have looked at that in a larger Master Data Management (MDM) solution.

Why an MDM? Well, of course there are some negatives to it also there is a larger investment needed. Most companies must build a new repository around this. It does require the data collection programs need to be set up, integrations must be built and so on. From a first glance, the Central repository that is building an MDM solution, for your IDMP data management seems to be very comprehensive and it takes a lot of time to build it up in money.

Building an MDM and building a central repository gives you a lot of benefits and especially if you look at it from the long-term perspective, if you want to build which is future proof.

How do we build this in the sense that it is expandable? Today, we have SPOR – we have the DADI project going on, but tomorrow the FDA comes in you might have different internal requirements. So again, you want to have an expandable solution. It is not influenced by changes in regulations. What I mean by that is if tomorrow xEVMPD changes, you do not have to change your whole strategy. You might have to pick up some parts of your central repository. You might have to fine tune that, tweak it, but it does not address your source data. It does not impact your regulatory system, its not necessarily impacted by that change. By approaching it as a central repository, you don’t necessarily have to make changes to your source information or your source processes.

If you build based on the regulatory system, instead of putting a separate central repository in place, what companies have said, well IDMP is 80% to 90% comes from the regulatory system and you are right. Especially if you look at SPOR iteration one, most of the data will come from your regulatory. You should already have that in your regulatory RIM system. Some companies already extract xEVMPD from that. It would only be logical to then think about, well, I can also think my IDMP, DADI data can also be exported from that.

It is also less expensive, but it is less future proof and now you are putting a lot of strain on your regulatory system. Especially if you start looking at expansions above and beyond compliance, when you are starting to say look regulatory, or if safety starts asking regulatory to say, look I need the IDMP data, please give it to me or if clinical starts saying, look, I want to extract changing data. You put a lot of strain on your regulatory systems instead of having a central repository.

If you do think about going to that solution though, one thing that I would advise you is really to make sure, before you decide and if you say, well, we still want to do this, and we don’t really want to go onto a different track. Make sure that your regulatory process and your data are cleanly separated within your RIM system.

Can your regulatory solution (RIMS) be used as the central repository?

• Data in RIMS maps mostly with xEVMPD / IDMP / SPOR data but need to consider if there is a clear separation between process and data management in RIMS
• Risk of modifications in whole RIMS solution due to changing regulatory submission requirements.
• Nonregulatory relevant extensions not possible or extra strain on RIMS solution
• Not easy to manage differences in terminology between departments

At first glance it looks interesting to take your regulatory system as the core for an IDMP compliant central dictionary but long-term considerations towards extensibility and maintenance need to be considered. Full separation of data and regulatory process data would be recommended.

ISO IDMP is the perfect solution for the central repository. It is an internationally well adopted standard. It does not necessarily mean you have to follow it. I also have seen solutions that have just literally copy and pasted the data model from IDMP into your central depository. That should also not be the idea, to do something like that. But nevertheless, make sure that the concepts are there, make sure that you build it around an ISO IDMP compliant framework.

It makes it futureproof because you are building a repository based on standards. This standard will evolve. You will be able to move this around. It is not something that you do uniquely. It is something that is done within the industry. It is based on specific needs where you can extract subsets, you can extract the subset for safety, xEVMPD, SPOR version 1, version 2. It is extendable. Also, when regulations change, it can change the regulations without having an impact on your other integrations with safety needs.

If SPOR now goes from one operating model to another, or DADI in this case if they move this, you can focus on that part and only change that without changing anything else or impacting any other business processes that you might have already built. New business needs can be added much more easily, which also brings me to the point that you gradually must build up this program.

Where Can I Get the Data?​
You will soon come to your realize that especially if you look at iteration one for the moment for Europe. You will come to regulatory which is your main source of information. Now you could take it a step back also and then start asking the question about, where does regulatory get data? That is for now assume that the data with regulatory that and will come back to the golden source of information, but the regulatory will have lot of information. It already is the source for xEVMPD, and it is also logical that from an IDMP perspective, you look at that data.

The second source of information, when you build a process in place, make sure that the solution that you put in place or the solution that you find in the market also deals with unstructured data in a nice way. Because a lot of data is there and the last thing you want to do if you are bigger company is drill down your thousands of documents and put the data in manually. It is not much more secure than an NLP process that it is the errors that are being made in there are as much. Make sure that you basically have a solution that can bring documents into the mix and make it into data.

You will also quickly identify that there are other sources in place we are saying regulatory for now, but as soon as you start building out your processes and your more advanced beyond compliance aspect, you will see that other sources are also there. What those other sources include clinical information, study information, especially if you are talking about the investigational site of the products batch information and manufacturing information.

Then of course also think about external sources. External standards are there, especially if you are familiar with the SPOR. The organizations are referential in the SPOR initiative. Those talk about manufacturer data referential, which are code lists, list pick lists, and so are managed by the authorities. So, you can leverage on that also. You really need to look at that type of data also, and make sure that type of data can also be brought into your solutions.

There is also a technology layer that you must consider when you build that central repository, because all that data that you have somehow will have to make it into the central repository. The last thing you want to do is enter it all manually or put manual processes in place that bring the data from one place to another.

I would highly recommend that if you have not done so yet do a data assessment. How ready is my data? and even if you have done it before. I mean, it is a bit difficult to say, but what I have also seen is the companies repeat this on a regular basis. They basically just do an assessment to see how things have changed primarily, because in some cases, some of you might have done this data assessment a few years ago. If you have done it recently, it might still be accurate. But again, regulations have changed in the meantime, also different focuses there. So, it never hurts to do another data assessment.

As a basis, you can always start looking at IDMP. What data is there – iteration one, what fields are there? Probably do not try to do ISO IDMP at once. You can start focusing on iteration one. For that, especially because that’s a near compliance issue, but can always keep ISO IDMP standard in mind.

• Use IDMP as the basis for the assessment.
• What information can be found where (identify primary source)?​
• Identify clear compliance and business cases.
  • Map to IDMP fields​
  • Identify additional needed data elements​
• Do we have the data available and in which format?​
• Data collection or cleaning needed?

Not every field in ISO-IDMP might seem relevant from a compliance perspective but consider the cross-domain benefits and internal business needs also before defining the scope. However, do not fall into the trap of trying to capture everything in the first phase. The solutions should be extendable for a reason.

Priority and focus can change over time and is very much dependent on the needs of the department over time.  So, consider that what might be accurate for one department might not meet the needs of a global solution.​

• Are processes in place to update data?​
• Are verification steps in place in the source systems?​
• Is data based on reliable data sources​
• Is data available on a global basis?

Companies have started looking at it from the perspective of EMA and SPOR. DADI is a European initiative. So let me just look at the European data. It is a viable solution and of course, if you have resource constraints, you might be looking at the data, but be aware that, if you only look at European data now, that tomorrow you might be doing the exact same exercise for the rest of the world data.

If you’re cleaning up your data anyway, you might as well clean it up for the rest of the world, even if Europe only requires European data. Keep in mind that the data that you’re looking at is not just for xEVMPD or for SPOR. But you also want to gain advantages within your organization. So, from that sense limiting this to only European data might set you back in certain areas.

Accuracy of data also has a time element to it. Maybe another example is essentially what I’ve also seen is that companies over time change their processes, they change how they work with certain elements or with certain data elements to be more specific, how they populate them. So, it could be, if you look at the status today that everything seems to be okay. But if you look at it from a horizontal perspective, so more from a historical perspective that all your data might not be as clean as you wanted it to be.

Consistency is also an important thing and that’s probably when I do my assessments, this is really something that is really one of the more challenging ones or the most interesting ones to talk about it.

It’s really if you talk to different departments, if you talk to everybody, everybody uses the same. Supposedly the same terminology uses internal terminology, but they all talk a different language. The examples here are clear salt is sodium chloride, it’s all the same. But it is consistent within that department, but you must start looking about consistency across departments here also.

The elements like RMS OMS, ISO standards can help with that. You must define a strategy for harmonization which doesn’t necessarily mean that everybody must start talking the same language. You can change it over time, but also don’t try to change everything at once. It’s very difficult to and to make changes and especially people that I’ve talked about in certain languages, but you must be aware that this is probably one of the main challenges when it comes to implementing IDMP. It is bringing different data sources into it. It’s essentially data consistency and how people talk and how people translate things.

When you look at data, it can be accurate. It can be correct. You might have all the translations in place, but you also must think about it, and this is indeed purely towards compliance. Is the data timely? because you also know if you’re talking about compliance, you’ll have to submit your xEVMPD and put your DADI and your FHIR messages in the future. You will also have to submit them in a timely manner.

As soon as you get the approval within X number of days, you will have to submit that data to the authorities. So, if you look at your sources, the question is that, are they entering the information in a timely manner? Will I get the information timely for my golden source? or do I have to make a change in that point? It’s also something which is overlooked a lot of times. Then at the last minute, when you go into production, you might have to start chasing them up continuously. So, make sure that you have that under control and probably also make very clear agreements with the source system by saying look this is the reason why it is and basically you must do this for this reason.

It’s not just about the one-time transfer there.

• Who will be responsible for data going forward?​
• Which process will ensure that data will keep on flowing?​
• Are the right future focused processes in place?​
• Are the right quality check and quality assurance steps in place?​
• Is the awareness and commitment there from senior managers?

The success of this project is not only based on successful implementation.  The real success and ROI will come if you build a strategy for the future.  This also means showing the benefits to all departments and showing them what this can mean to them.  So, focus not only on data and process but also on awareness. So really when you want to build a Futureproof IDMP solution data, ownership and maintenance are three very keywords, I would say within your whole solution here or within your whole element that you mentioned.

When you have your central repository, you have all the data, you have the process in place to keep it up to date. Now you want to start exchanging data. As I said, it shouldn’t be one directional. Of course, you must bring the source data in. It must be done in an efficient way. It must be done in a way that reduces the manual effort as much as possible, or even completely takes it away from that matter. So, technology is a very important aspect in this element also.

When you think about technology the first thing that you need to think about is elements like how do I get the data? and this is purely technical, where you’re talking about, what data sources do I have? and what do I need to bring that data into my central repository? And the first step is of course, bringing it into your central repository. The second step will also be, how can I take data out of my central repository? So, all that data also must be considered, and the first layer is purely technical. Does the technical solution that I have in place support multiple ways of communication? Does it support web services? Does it support APIs? Does it for documents specifically? Does it have OCR and NLP capabilities? Does it have gateway capabilities for xEVMPD for instance? Even if you have very old systems in place, you might still want to consider a very basic point-to-point solution. So, it might not necessarily be an API, but you might still leverage older technologies. Think about this when you select your technology framework, your technology platform before you start deciding. Because building onto that platform might be easier, might be difficult, but make sure again, towards that vision of future proof, make sure that you know what you’re getting into.

There are also data transformations that need to happen. Field mappings must be done. This is an internal layer where there’s some user interactions that will need to happen. Fields will have to be mapped. Data will have to be mapped. Schedulers will have to be defined on when data is transferred at what point in time. What are some of the triggers? data review workflows might happen under that central repository data consistency checks through rule builders. So, there are certain functionalities that you also must pin think about it. The central repository is not just a matter of repository with a technical layer around it. It also must have a functional layer around it.

It is nearly impossible to have everyone in your organization to always use the same terminology.​ Even regulators across the globe are not there yet.

Just to give you one example about the data mappings, for instance, this is really where I come back to the example of terminology alignments. Having to be addressed by technology is that if you try to have everybody talk the same language, it’s not going to happen and this is something you can be ambitious, you can say now on everybody talks about Salt. Everybody talks about it, but it can happen a few times, but over time it goes away, and people fall back into their own old habits.

So, technology here can help very, very strongly with respect to these kinds of translations. Just to give you one example, there’s so many other examples, but really synonyms translations are there. I now talked about even people talking in English in three places where at some point in time we will also have to think about different languages and really technology here can help you very strongly with a mapping tool between even external standards like OMS and RMS. So, I think that’s really one area where technology can help very closely.

• Most companies have / are making progress but face challenges when direction from regulators change​
• It might be a good time to re-evaluate your strategy and use experiences from other companies

Most companies are making progress. So, when I really look at where we are in the market today, companies are making progress. But it always makes sense to reevaluate your strategy. A company like Celegence, could help you with input and looking at external help is very important.

You have your inside world, your internal world, you know your own business, but what other companies like Celegence could bring to the market, for instance, is the fact that they have experience from multiple sources, multiple companies, where they have seen what works, what doesn’t work, what works well. So really that could also be brought into it. So, reevaluation of your mappings, but also bringing on the external experiences from other companies into your mix, I think would be very important here.

Questions to ask:​

• Have we made progress or are we impacted by changes in approach from the EMA​
• Are we re-aligning our strategy again after DADI announcement​
• Is our IDMP strategy focused on compliance or will it benefit the organization​
• Do we know what our internal roll out plan will be to other departments
• Is our strategy allowing for flexibility to address global implementation of IDMP​
• Does it remain challenges collect and/or align the data