EMA, IDMP, SPOR, XEVMPD

Would you support IDMP that isn’t IDMP?

Joel Finkle, Director Regulatory Innovation & IDMP Strategy

For the last few months – both at the January and March EU IDMP/SPOR Task Force Meetings, there has been debate about how to send IDMP data to agencies in Europe. Although the ISO standard specifies the HL7 SPL format, the initial iteration of EMA’s implementation is only going to use pieces of the standard, and it is awfully complex. Among the options being considered are integration with CESSP– whose project is ongoing and can’t be synchronized with IDMP right now, and expanding the scope of the XEVMPD standard – which has always been hand-waved away as just the wrong solution.

If you don’t know what those abbreviations mean, you’re probably reading the wrong blog, but here they are:

  • EU: European Union [ok, you knew that one]
  • IDMP: IDentification of Medicinal Products, a set of ISO standards for biopharma product registration
  • SPOR: Substance, Product, Organisations and Referentials, the EMA Master Data Management project to manage IDMP and related data
  • EMA: European Medicines Agency, the organization responsible for EU health approvals whose headquarters may soon be leaving London
  • HL7: Health Level 7, an organization developing data standards for health and life sciences
  • SPL: Structured Product Language, one of HL7’s standards
  • CESSP: Central European Single Submission Portal: A new portal designed to integrate the electronic application form with the agency gateway portal
  • XEVMPD: Extended Eudravigilance Medicinal Product Dictionary – the predecessor to IDMP in Europe
  • XML: Extensible Markup Language
  • ISO: International Organization for Standardization (doesn’t that just trigger your OCD?)

Apparently, in the few weeks since the March meeting, the XEVMPD option has come up again. The primary reason against expanding XEVMPD is that no other region is likely to ever implement XEVMPD (or is that EXEVMPD*), as it’s not an ISO standard, rather it’s a standard that only Europe has implemented. That in turn could slow down adoption of IDMP across the world. A world-wide drug registration process is something that we’d really like to happen, as it spreads the costs of software and services over a wider set of registrations. IDMP is also designed to be a universal format for exchanging that drug registration information across borders – for importing during emergency shortages, or determining the root cause of a set of seemingly-unrelated adverse events.

But would it be so bad?  Here’s some points in favor of using XEVMPD as a mask covering over the IDMP data:

  • XEVMPD is already in place, and an upgrade would be less stressful than a complete replacement
  • Japan has no stated plans to implement IDMP, and the US says that the current Drug Registrations and Establishment Listings are already IDMP compliant (even if they are much simpler), so they’re not in any hurry to make changes. Canada and Switzerland are probably next in line for IDMP implementation, but they usually follow EU’s lead.
  • Although it’s not a standard, the XEVMPD XML message is much simpler and human-readable.
  • An Expanded XEVMPD could still use the IDMP identifiers: The Medicinal Product ID (MPID), Package ID (PCID), Pharmaceutical Product ID (PhPID), and Batch ID (BAID), which would help the standardization of international exchange of safety information.
  • From the Market Authorisation Holder’s point of view, it shouldn’t make a difference: The same information has to be excavated from submission dossiers and commercial documentation, and publishing to the agency should just be a button press.

So the big question is whether this would be supported by software vendors. Most vendors already have some form of XEVMPD support. Many already have the capability of generating an SPL IDMP message, using a lot of guesswork and assumptions since the EU implementation guide isn’t yet published.

I’d really like to hear from you: How do you feel about using XEVMPD to deliver IDMP? Either comment here, or on the LinkedIn page where I post this, or send a message through the ACUTA contact page if you’d like to be anonymous, or would like more information on how we could help you implement the IDMP requirements.

 

* I’m using an E, for Expanded, matching the old EMS and XMS Expanded and Extended memory systems on the IBM-PC. (Yes, I’m old enough to remember that). The fun part is that EXEVMPD and XEVMPD would both be pronounced the same.

Mask image by Kat Theobald under Creative Commons license

Author: Joel Finkle

Joel became embroiled in electronic submissions when regulatory came downstairs and asked "Can we convert all our clinical study reports to WordPerfect format for the FDA reviewer?" and he didn't say, "No." Since then, he's been involved with custom CANDAs, PDF publishing, eCTD, document template automation, Regulatory Information Management, HL7's RPS, and the ISO IDMP standard. He joined ACUTA in April of 2017. He'd share some of his famous tomatillo salsa with you, but he can't carry it on airplanes.

2 Comments on “Would you support IDMP that isn’t IDMP?

  1. There are other options, Joel. When we first “did” IDMP, we had a 11615-specific HL7 message that was completely compatible with SPL (one transform in xml), but way simpler to implement. And it had a (admittedly simple and exemplar) business process supporting it (and it had Japanese support). But because it wasn’t “exactly” SPL, it was taken off the table. So I think if you want to look for options that are simpler than SPL but compatible to it – so you really can have a global standard – there are definitely other things out there. You don’t have to go “back” to xEVMPD, which is not a standard anywhere. And although I don’t like it, because it’s thrown the entire nursery out with the bath water, you could use FHIR. And because IDMP is already founded on a robust information model and the ISO datatypes, you would mitigate so many of the issues that FHIR has. So that’s worth looking at too 🙂

    1. Thanks, Julie. Except for the issue of having to build a new format nearly from scratch (which includes FHIR), that’s probably reasonable. In fact, I wish we could apply the same philosophy to eCTD 4 too.

Leave a Reply

Your email address will not be published. Required fields are marked *