As stated in our previous blog, EMA’s webinar “DADI-PMS Webinar Agenda – ‘Variations Form for Human Medicinal Products – What will happen at Go-Live’” made it clear that data quality [in PMS] is dependent on xEVMPD.
PMS, the Product Management Service out of the EMA SPOR project builds on the data foundations of the Referential Management Service (RMS) and the Organisation Management Service (OMS) that are already implemented.
With EMA’s Agile approach, the first iteration of the PMS will cover a subset of the authorised medicinal product part of the ISO IDMP standards. As part of the first iteration, the new ISO IDMP compatible data submission format (HL7 FHIR) replaces the current data submission format, the eXtended EudraVigilance Product Report Message (XEVPRM). xEVMPD data will be migrated to PMS and hence the data quality in xEVMPD will have a direct impact on the data quality in PMS.
Why is data quality in xEVMPD so important?
Let’s face it, MAHs are responsible for their data, period. So it might be a good time for MAHs to check on xEVMPD data before it is actually migrated into PMS, thereby removing unnecessary corrections that might be required later on. Additionally, as PMS will serve as a base for other functions, inconsistent data could move rapidly around related system.
Here are just some of the data fields that might require another look to ensure consistency:
• Marketing authorisation holder (MAH) of the AMP (Authorised Medicinal Product); has anything changed over the last year through e.g. merger or acquisition?
• Qualified Person responsible for Pharmacovigilance (QPPV); have resources been replaced but not updated?
• Master File Location; did the Master File move because of a change in infrastructure?
• Authorisation/Renewal Date; has the renewal data been updated or has the product been withdrawn?
• Product Indication(s) (using MedDRA coding); are there updates on the MeDRA coding that did not filter through?
• Authorised Pharmaceutical Form; has the product moved to additional authorised forms?
All the above are just a few examples of data fields that are undergoing regular change.
How can this process be automated?
xEVMPD uses an EV Code (EudraVigilance code) as a unique code assigned to any entity (e.g. substance, product etc.). An EV Code is generated after the substance has been inserted successfully in the xEVMPD. This EV Code can be used to compare data exported from xEVMPD (via EVWeb) with data held locally. Differences can be identified as long as all data is in the defined format.
The process is simple:
- Locate the xEVMPD messages generated locally separated by EV Code.
2. Locate the xEVMPD messages exported from EVWeb.
3. Compare with further details on differences identified between data fields associated with the same EV Code.
MAHs are responsible for their data and hence it might be a good time to check on whether the data held by the MAH is consistent with the data held at the EMA before any data migration to PMS takes place. Data held in xEVMPD will be the base for PMS and hence the quality of xEVMPD data is paramount. Although later corrections are possible, being proactive rather than reactive will save MAHs and regulators a lot of time and money.
But time is running out…