For the past years we have been working with clients on their Serialisation compliance and with this post we want to share some of the insights gained while helping clients to find operational ways to handle the EMVS alerts.
Authentication of FMD compliant packs against the EU hub became mandatory for dispensers with the same deadline of February 9th, 2019 as applicable for manufacturers. Thus, functionality was established from the get-go for creating and distributing alerts when errors are encountered in the system. In the system, not all alerts are distributed to the MAH. The alerts distributed to MAHs are the so-called level 5 alerts which are typically created when authentication attempt fail due to a mismatch between data in the EMVS and that in the request.
The lack of clear and uniform regulations on alert handling has caused much uncertainty about what is being expected from the MAH and since the concepts of serialization were new to the entire supply chain, the frequency of errors – and thus alerts – has been overwhelmingly high.
In the void of good standardized tools for EMVS alert handling, manufacturers have struggled to find operational ways of handling the alerts. Specifically, the challenges include:
- Alert retrieval from EMVS to a format that is useful for further analysis
- Evaluating alerts to assess the risk that alert is due to falsified medicines and not merely another technical error
- Setting up a convenient repository that allows for search and monitorization of alerts
- Setting up processes for reacting to requests involving EMVS alerts
- Setting up criteria and processes for contacting NMVOs
Rate of alerts
According to data from EFPIA, the rate of alert occurrence varies greatly among the member states. From 0.03% of all scans causing an alert in Slovenia to more than 3% in Ireland (April 2020 data).
Thus, the average number of alerts received by MAH per day will not only vary according to degree of compliance and sales volume but is also depending on how sales vary among the EU member states.
However, the technical choices made on the serial number format also have an important say in the type and frequency of alerts received. In one example, a Danish MAH uses alphanumerical serial numbers. The MAH receives alerts from the EMVS with a frequency corresponding to around 0,25% of the EU sales volume with very little variation week for week in 2020. Of these, more than 80% of the total number of alerts and 90% of the manual analysis relates to the use of letters in the serial number. Thus, as will also be discussed below, manufacturers serializing using numerical serial numbers are sparred from a range of alerts.
EMVS alerts are made available to MAHs either by being pushed to the MAH via integration to corporate level IT system or pulled from EMVS by access through login on the EMVO gateway webpage.
When assisting clients, Pharma IT has been using retrieval through the EMVO gateway since this provides access to the alerts in a manner independent of customer and in CSV format which is versatile for further analysis.
Analysis of alerts: What is the exercise all about?
As the title of the Falsified Medicines Directive (FMD) indicates, the purpose of the legislation is to create barriers for falsified medicine to enter the market. In practice, however, the system has been flooded with errors that appear technical in nature and until this picture changes, the general perception in the industry is that EMVS alerts are almost exclusively caused by technical errors. This has caused many EU member states to adopt a softer approach to implementation in which a pack can be legally dispensed despite authentication fail.
When evaluating alerts, it deserves explicit mention that it will never be possible for the MAH to positively rule out that a pack is not falsified by evaluating alert data alone. However, with the believe that most alerts in the system are not caused by falsified medicine, the purpose of the MAH analysis of incoming EMVS alerts is to single out the few alerts that deserves further investigation from the many that have a plausible technical explanation. As usage of the system matures, the tolerance for errors should become smaller until, hopefully, the point where all EMVS alerts are truly considered to be potential counterfeit.
Commonly encountered alerts
The errors described in this section all relate to the use of alphanumeric serial numbers, containing a mixture of letters and numbers. In our experience, these are by far the most commonly encountered types of alerts when alphanumerical serial numbers are used. Obviously, any MAH serializing by means of numerical serial numbers, would not encounter such errors and would be able to react on any alert in which SN is not strictly numerical.
A common type of DataMatrix scanners, the keyboard wedge scanners, passes the the scanned data to the IT system as if it was entered on a keyboard. Accordingly, if caps lock is on for a connected keyboard, a lowercase letter will be interpreted as uppercase and vice versa. Likewise, If the keyboard layout is not set to English, letters may be interchanged e.g. interpreting a Z as a Y and vice versa or Latin letters may be changed to letters from the Cyrillic alphabet.
In cases where SN in alert contains a mixture of uppercase and lowercase letters, the alert has been classified as suspect since no plausible technical explanation for their cause has been found. This also applies to cases where SN in alert contains characters not used in the serialization profile(s) of the MAH, when not due to the use of a keyboard wedge scanner.
Other commonly encountered alerts
Commonly encountered types of alerts that are not related to the use of alphanumerical serial numbers includes
- Alerts caused by mistakes in the data uploaded by MAH to EMVS
- Alerts caused by part of batch data not successfully uploaded to EMVS by MAH or not successfully distributed to all relevant markets
- Alerts in which length of serial number in alert does not match the length(s) used by the manufacturer
- Alerts for which data needed for analysis is not provided in the alert
- Alerts in which special characters are included in Batch or Expiry date
- Alerts in which expiry date in alert not matching that encoded in the DataMatrix. In these alerts, expiry date has been first or last day of month or “00”.
Particularly frustrating to the MAH are cases when automated systems repeat an authenticate request with data causing an alert. Authentication attempt repeated in 10 or 15 minutes intervals may cause thousands of alerts until stopped. Since clients are anonymized, they cannot be contacted directly and informed about the problem and contact must go through the relevant NMVO.
A good system for handling EMVO alerts
So, what would be a good tool for MAH to use in the transition period? As we see it, good systems for handling EMVS alerts share the following features:
Analysis: Automated and assisted
Although full automation remains an elusive goal, a good system for handling alerts should have a high degree of alert handling without need for human intervention. In cases where complete analysis cannot be completed by the system, the user should be aided in completing the analysis and recording the conclusions efficiently. Such assistance may be given in the form of suggesting a likely cause and preparing relevant data to examine in the analysis.
In our experience, it has been possible to reach more than 99% of the alerts handled automatically or with accurate suggestion for expected technical root cause with the majority of the remaining 1% not having an identifiable probable technical cause and thus needing investigation as possible counterfeit.
Repository: Clear and concise display of conclusion
The user should be able to quickly gain concise information about the conclusions made after analyzing the alert. What is believed to be the root cause? What is the supporting evidence for this claim? All should be efficiently conveyed to the user without overloading the user with information. A successful way to approach this, have been to introduce alert categories. By familiarizing the user with these, the expected root cause can be communicated to the user in a clear and concise manner for the majority of the alerts.
Repository: Providing overview and trending
With a steady stream of alerts received, it has proven a valuable tool for the MAH to be able to collect statistical insights from the alerts collected. Using conclusions from the alert analysis together with timestamp, key areas of focus may be identified and the company performance in respect to compliance may be measured. From statistics on client IDs and markets, insights may be collected providing a good starting point for constructive dialogue with NMVOs.
Repository: Bulk search from list provided by NVMO
Since MAHs are regularly contacted by NMVOs with request to respond to a list of alerts, any system handling alerts for an MAH must provide a means to efficiently match the data in such a list with the data in the internal alert handling system.
Processes, Roles and Responsibilities
To successfully integrate EMVS alert handling into the organization, ownership of system as well as the associated processes must be defined. Below are examples of processes that deserves consideration with respect to the level of documentation and validation needed as well as the expected frequency or response times required for the task in question
- Alert retrieval and analysis
- Correcting errors in EMVS reporting discovered by analysis of alerts
- Handling of alerts for which a plausible technical error cannot be identified
- Monitoring and trending on alert with regards to alerts expected to be caused by technical errors on client side
- Responding to alert related requests from customers or NMVOs
So even though there are no tool for complete automation of alert handling, we recommend that the processes are anchored as part of daily operation as fast as possible.
With small tweaks to the alert retrieval and processing, EMVS alerts can be managed efficiently without substantial effort from the organization.
See more about our Serialisation service and contact info here