EMVS alert investigation, with a cited cause and a drafted closure for every alert
Every pack-verification alert gets a cited cause and a drafted closure in hours, well inside each country's deadline.
See one case, screen by screen ↓Every alert from the EU hub starts a national clock — one working day for a data issue in France, two working days in most markets, seven calendar days in Germany. For each one, the alert manager has to work out whether the pack is genuine or a possible falsification, and answer the national system in its own form, with its own cause categories.
Most alerts are technical: a pharmacy scanner with Caps Lock on, a keyboard layout that swaps Y and Z, an expiry typed day-first, a batch never sent to the market it was delivered to. But proving it means moving between the hub portal, the serialization repository, the pack’s history and email — about 20 minutes an alert. Done 400 times a month, the routine cases crowd out the one alert that has no technical cause at all.
Estimated split for about 400 alerts a month, by hand and with the solution, in hours.
Specialist agents read each alert, check the upload, the pack's history and the scan, name the cause and draft the closure; the alert manager approves each one.
At 09:02 an unknown-serial alert arrives from a pharmacy in Cork. Across the alert clock, a pack in Milan has no technical cause. Here is what happens to both, screen by screen, in the working solution.
Lena opens the alert clock: 61 open alerts across 12 national systems, 31 closures already drafted, the next deadline in France in 5 h 30 m, and one possible suspect in Milan. The EU hub is pulled every 30 minutes — last at 09:05, next at 09:35 — and the agents sort each alert as it lands.
“Possible suspect: 1 — no technical cause found · head of quality decides.”
A-26-04417: code A3, unknown serial number, on a Veltrimab 40 mg pen from batch VB2607, dispensed at Harbourview Pharmacy, Cork at 08:47:12. The Irish clock gives it 2 working days. Lena presses Investigate, and each agent’s step shows as it runs: the batch was uploaded on Sep 14 with Ireland as a target market, there is no exact serial but one match ignoring case, and the pack verified as genuine 41 seconds later.
Scanned against uploaded, tile by tile: “Same characters — letter case inverted on 8 of 8 letters.”
The probable cause, in the root-cause category the national system expects: end user, scanner set-up, letter case inverted. Four findings carry their source — the serial matches upload record UPL-26-0871 at part 3, line 1,882 when case is ignored; batch, expiry and product code match exactly; the pack history shows it verified 41 s later by the same pharmacy; and Harbourview has 7 alerts with the same pattern in 30 days. Seven other causes are listed as ruled out.
“This is a scanner sending text with Caps Lock on.”
The note is drafted for the Irish national system: alert ID and code, product code and batch, the serial and expiry as uploaded, the root-cause category, a short description, the corrective action and “Pack may be dispensed: Yes — not a suspected falsification”. It stays marked DRAFT until Lena approves. She can edit the description; the edit is recorded. She approves and sends, and the alert waits for the national system to confirm.
The writer’s rule: never state that a pack is genuine without the pack history evidence.
The alert belongs to RC-108 — six open alerts and one closed in 30 days from the same pharmacy, all with the case inverted and every pack verified seconds later. The corrective action is a scanner set-up letter to Harbourview through the Irish national system, already drafted, asking the pharmacy to check that Caps Lock is off. Six alerts close with one fix.
A-26-04473: batch not found, on a Veltrimab pen at Farmacia Navigli, Milan. The pharmacy re-scanned it twice and typed it by hand; it is still unknown. No serial in batch VB2609 is within 5 characters — the nearest differs in 7. The batch was only ever sent to Germany and Austria. The same serial raised the same alert in Barcelona on Oct 3. And the pack says it expires 31 Mar 2028; batch VB2609 expires 30 Sep 2027.
The classifier never forces a technical cause: unexplained alerts always go to a person.
The pharmacy’s photo, sent to the alerts mailbox, is set beside the Plant 3 reference artwork. Three differences are marked: the printed expiry, a narrower typeface for batch and serial with no quiet zone around the 2D code, and a tamper-seal perforation pattern that differs from Plant 3 seals. Everything goes into the evidence pack — nothing is sent.
Lena escalates the alert to Omar with the evidence pack attached: upload lookup, distribution path, pack history in two markets, photo comparison, the seven causes ruled out and the pharmacy statement. He has three choices — report it as a suspected falsification, ask for the pack first for inspection at Plant 3, or close it as technical and send the note back to Lena.
Omar signs with his password and the meaning of the signature — “I confirm this pack is a suspected falsified medicine” — kept with the alert for 10 years. The notification goes to the Italian competent authority, with a copy to the Italian national verification system; the pharmacy is asked to keep the pack quarantined and return it for analysis, and Dana Okafor in brand protection is added to the case.
Alerts received, closed on time inside each national deadline, median time to closure, what caused them, the alert rate by market and the end users with repeat alerts. In the sample data 99.5 % of alerts had a technical cause, and Ireland’s rate stands out at 3.10 % of scans — mostly case inversion.
The same morning’s alerts, seen by the four people who carry them — what their week looked like, and what it looks like now.
Specialist agents read each alert, check the upload, the pack's history and the scan, name the cause and draft the closure; the alert manager approves each one.
Reads each alert from the EU hub pull — the alert code, the market, the end user and the scanned data.
Looks up each alert in the serialization repository: was the batch uploaded, to which markets, is the serial in the batch, and which serials are nearest when it is not.
Reads the pack’s life from packaging line to the alert: commissioning, shipments, every verify and decommission, and what happened after the alert.
Compares the scanned data with the uploaded data character by character, and against the end user’s earlier alerts, to spot case inversion, keyboard layout swaps, added characters and date formats.
Weighs the evidence from the three checkers, picks one probable cause with a confidence, explains it with citations, lists the causes it ruled out and groups the alert with others that share the cause.
Drafts the closure for the national system in its required form, cause category and language, with the corrective action and whether the pack may be dispensed.
Builds the evidence pack for an unexplained alert and drafts the notification to the competent authority and the quarantine request for the end user.
Approves closures; the head of quality decides suspects. The agents propose; a named person decides.
Ask about any alert, batch, market or cause — or say what to change. Every answer points to its evidence.
Why did the Milan pack raise an alert?
Alert A-26-04473 (Italy, batch not found) has no technical cause. No serial in batch VB2609 is within 5 characters of it; the batch was only ever sent to Germany and Austria; and the same serial raised the same alert in Barcelona on Oct 3. The pharmacy’s photo shows a 2028-03 expiry against 2027-09 for the batch. It needs Omar Haddad’s decision before the Italian deadline.
Why so many caps-lock alerts?
A keyboard-wedge scanner types the 2D code into the pharmacy system like a keyboard; with Caps Lock on, every letter arrives with its case inverted and our alphanumeric serials no longer match. Harbourview Pharmacy, Cork has 7 such alerts in 30 days. A scanner set-up letter through the Irish system usually stops it (RC-108).
What happens if it is a falsified pack?
An alert with no technical cause is a possible suspected falsification. The suspect case builder assembles the evidence pack; Omar Haddad decides and e-signs. If he confirms the suspicion, the notification goes to the national competent authority and the national system, and the pack stays quarantined at the pharmacy and is requested for analysis. Nothing is sent without his signature.
Add a rule: auto-confirm caps-lock alerts when the pack verifies within 2 minutes
Done. New rule Auto-confirm case inversion: when every letter of the serial is case-inverted and the pack verifies as genuine within 2 minutes, the closure is drafted and queued for one-click approval. You still approve every send. The rule is on in Settings and recorded in the audit trail.
13 screens from the working solution, on its sample data. Pick one to see it large.
Confidence, grouping, escalation, national clocks and approvers are settings — and a new rule can be described in one sentence for your approval.
| Setting | Default | Choose from |
|---|---|---|
| Draft a closure automatically when the agents are at least | 90 % confident | 80–99 %, one point at a time |
| Group alerts that share a cause | On | Same batch, same end user or same pattern within 30 days |
| Escalate anything unexplained | On | Straight to the head of market quality |
| Serial seen in two markets | On | Always escalate as a possible suspect |
| End user with 3 or more alerts of one pattern | On | Propose a scanner set-up letter through the national system |
| National deadline, per market | France: 1 working day · Ireland: 2 working days | 1 working day · 2 working days · 72 working hours · 7 calendar days |
| Who approves closure notes | Lena Ortiz | Lena Ortiz · Omar Haddad |
| Who decides possible suspected falsifications | Omar Haddad | Omar Haddad · Dana Okafor |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample alert data · “target” = the design goal, measured in the live solution · “estimated” = our estimate · “typical” = published alert analyses (1–2% of scans raise alerts). Regulatory context: EU Falsified Medicines Directive and Delegated Regulation (EU) 2016/161. People, companies and products named on this page are fictional — characters and sample data in the working solution.
When a pack scan at a pharmacy or hospital does not match what the marketing authorisation holder uploaded to the EU hub, the national verification system raises an alert. The company has to find out why, within the national deadline, and close it — or treat the pack as a possible suspected falsification. The EU FMD Alert Investigation Agent does the checking and drafts the closure; people approve and decide.
Three agents check each alert in parallel: the upload record matcher looks up the batch, target markets and nearest serials; the pack history checker reads every verify and decommission; the scanner pattern finder compares the scan with the upload character by character. The cause classifier then picks one cause with a confidence, cites the evidence and lists the causes it ruled out.
No. The closure note writer drafts each note in the national system’s form, cause category and language, and the alert manager approves it before it is sent — one by one, or together by national system. Causes below the confidence threshold come to the alert manager to check first.
It is classified as a possible suspected falsification and never forced into a technical cause. The suspect case builder assembles the evidence pack, and the head of market quality decides — report it, ask for the pack first, or close it as technical — and signs. Only then are the authority notification and the quarantine request sent.
Yes. Alerts that share a batch, an end user or a pattern within 30 days are grouped under one root cause. A scanner set-up letter goes to a pharmacy through its national system, and a batch missing from a market becomes one corrective request to serialization IT, so the whole group closes with one fix.
Yes. Each market’s clock is a setting — 1 working day, 2 working days, 72 working hours or 7 calendar days — as are the confidence needed to draft a closure, the grouping and escalation rules, and who approves closures, decides suspects and makes corrective uploads.
Always. The agents are read-only on the serialization repository and never change a pack status. A person approves every closure, the head of market quality signs every suspect decision, and every step is kept for ten years.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your alert export, upload records, national rules and a sample of past alerts — and it goes live once every quality gate has passed. We will walk you through it on your own alerts first.
Ask any supply question in plain words and get a traced answer in seconds.
1-min filmSpecialist BuilderAn analyst builds a new data specialist by conversation in minutes, with no code.
1-min filmSupply Early WarningEvery supply signal read as it lands, and a ranked, cited shortage alert raised weeks before stock runs out.
1-min filmWe’ll run alert investigation on a sample of your own past EMVS alerts.