A serious adverse event arrives at a local affiliate on a Friday afternoon. A medical liaison takes the call, recognises it for what it is, and starts a local record. Everything about that moment is correct — except for one fact that nobody in the room is thinking about. The reporting clock has already started. Not when the central safety team eventually sees the case. Now, at the affiliate desk.
GVP Module VI is unambiguous on this point: the clock for a valid ICSR begins as soon as the minimum criteria reach any personnel of the marketing authorisation holder, including contractors and local staff. By the time the case has been forwarded, entered into the central safety database, quality-checked and routed for submission, several of the fifteen days may already be gone — consumed not by processing, but by the handoff itself.
This is the gap that sits between local and central pharmacovigilance. It is rarely dramatic. Most cases cross it without incident. But it is the place where compliance risk quietly accumulates, and it is structural rather than careless: it exists wherever the people who receive safety information are organisationally separate from the people who process and submit it. In a global organisation running affiliates across dozens of markets, alongside vendors, distributors and licence partners, that separation is the normal state of affairs.
The handoff nobody owns
Consider what the gap looks like in practice. An affiliate receives a case and logs it locally. The expectation is that it travels promptly to the central team for entry into the safety database. But the affiliate’s view of “what I’ve sent” and the central team’s view of “what I’ve received” are two different records, kept in two different places, reconciled — if at all — on a periodic cycle.
So a case stalls. Perhaps the forwarding email is missed. Perhaps a follow-up arrives locally and never makes it upstream. Perhaps a vendor collecting cases under an agreement batches its transfers and one slips. None of these is a failure of intent. Each is a failure of visibility: at no single moment can anyone see, with confidence, that every case received locally has actually landed centrally. The discrepancy surfaces weeks later, when someone runs a reconciliation — by which point the clock on a late case has long since expired.
This is precisely the risk GVP Module VI sets out to contain. Where pharmacovigilance data transfers within an organisation, or between organisations under contractual agreements, the guidance states that the mechanism should give confidence that all notifications are received, and that a confirmation or reconciliation process should be undertaken. Reconciliation, in other words, is not housekeeping. It is the named control for exactly this handoff — the instrument the regulator expects you to use to prove that nothing fell between two desks.
And the expectation goes further than running the check. Agreements with third parties are expected to specify the processes for the exchange of safety information and for reconciliation, including its timelines. Reconciliation is meant to be systematic, scheduled, and tied to the relationship it governs — not an ad-hoc cleanup performed when someone remembers.
Why a point solution doesn’t close it
Here is the uncomfortable part for anyone hoping a single tool will solve this. The reconciliation gap cannot be closed by a reconciliation feature alone, because the control depends on information that lives in four different places.
To know that a local case reached central, you need the local case record. To know who you are reconciling with and on what cadence, you need the agreement — the PVA or PV clause that defines the relationship, its reconciliation periodicity, and when it begins and ends. To know which data collection programmes and studies fall under that partner’s scope, you need the programme and study inventory. And to prove all of this to an inspector, you need it reflected in the PSMF annexes — the contractual-agreement and data-collection lists that describe the system as it actually operates.
A standalone reconciliation tool sees only the first of these. It can compare two lists, but it cannot tell you that a reconciliation schedule should have started the day an agreement was signed, that it should stop the day the agreement terminates, or that the partner it is reconciling against is the same entity named in Annex B of your master file. Those connections are where the gap actually lives. Close the comparison and leave the connections open, and you have automated the symptom while the cause carries on.
The control has to span the chain. That is the real argument for an integrated platform — not that integration is tidy, but that the regulatory control itself is only coherent when qualification, agreements, case forwarding, reconciliation and the master file are reading from the same data.
What “integrated” looks like in practice
It is worth walking the chain concretely, because the value is in how the pieces hand off to one another.
It begins with the partner. A third party — a vendor, distributor or licence partner — is qualified through a structured workflow: assessment, questionnaire, review, sign-off. Qualification is not a filing exercise; it is the gate that determines whether safety data may flow through this relationship at all.
Once qualified, the relationship is formalised as an agreement. And at the moment that agreement is signed, the reconciliation schedule is created automatically from it. This is the connection a point tool cannot make: the agreement does not merely permit reconciliation, it generates it, with a defined periodicity, inheriting the partner and scope already captured upstream. The control switches on as a consequence of the relationship existing, rather than depending on someone remembering to set it up.
Cases then flow against that backdrop. A local affiliate creates a case record the moment safety information is received — the moment, recall, that the clock starts. The case is forwarded to the central team, entered into the safety database, and then linked back to the originating local record automatically. That link is the quiet but critical step: it closes the loop between “sent locally” and “received centrally” as a matter of system state, not manual attestation. The local register and the central database stop being two stories about the same case.
Reconciliation then runs continuously against this connected picture, rather than as a periodic act of reconstruction. If a case logged locally cannot be found in the central safety database, the system raises an alert straight away — informing both the local and central teams while there is still time to investigate within the reporting window, not weeks later when the clock has already expired. Where the local and central records agree, no intervention is needed. Where they diverge, the discrepancy is raised as work — investigated, fed back, resolved — rather than noted and forgotten. The exception becomes an action with an owner, and the manual monthly reconciliation that once absorbed local safety officers’ time is replaced by live assurance: less work for the affiliate, higher compliance for the organisation.
The lifecycle closes as deliberately as it opened. When an agreement is terminated, a final reconciliation is forced before the relationship can be wound down — you cannot quietly end a partnership with cases still unaccounted for — and only then is the schedule automatically deactivated. The control persists exactly as long as the relationship it governs, and not a day longer.
And throughout, the same entity, agreement and data-collection records that drive these workflows are the records that populate the PSMF annexes. The contractual-agreement list and the organised-data-collection list are not reassembled by hand at review time; they are a reading of the live system. The description in the master file and the operation of the system are drawn from one source, which is the only reliable way to keep them from drifting apart.
The shift worth making
For most organisations, the local–central relationship is governed by goodwill and periodic checking: affiliates and vendors are trusted to forward, central is trusted to receive, and a reconciliation cycle is run often enough to catch the worst of what slips. That model is not wrong so much as it is blind between cycles — and the gap it leaves is precisely where a fifteen-day clock can run out unseen.
The shift is from reconciliation as a recurring act of reconstruction to reconciliation as a continuous property of a connected system: agreements that switch the control on, case links that prove the loop closed, exceptions that become owned work, and a master file that reflects all of it without being rebuilt by hand. The organisations that manage this gap well will not simply pass inspections more comfortably. They will know, on any given day, that the cases received at the edges of their organisation have reached the centre — and be able to prove it.
That assurance is difficult to manufacture from a single feature, because the gap is not a single feature’s problem. It is what becomes possible when the modules that govern partners, agreements, cases, reconciliation and the master file operate as one system. That is the problem HaloPV’s modular platform is built to solve.
About the author
Gyöngyi Mezey is Director, Product Management at Qinecsa. She brings 17 years of experience in pharmacovigilance, built on a background in healthcare, and works on aligning product direction with the operational realities of how safety teams run their systems day to day.