An Inspection Request Should Not Trigger a Scramble Across Systems
An inspection request arrives for one marketing authorisation holder (MAH) client.
The global Pharmacovigilance System Master File (PSMF) is current. The applicable local information exists. The vendor agreements are stored in the contract repository, and the affiliate has already updated its local contact details.
Yet assembling the complete inspection package still requires several emails.
The local team has revised its annex, but the global team has not reviewed the impact. A vendor transition is reflected in the contract register but not in the PSMF. The product list is current in the regulatory system, while the approved PSMF still shows the previous marketing status.
Nothing is completely missing.
The information has simply moved through different systems, clients, and territories without one controlled governance route.
For pharmacovigilance (PV) service providers, managing global and local PSMFs is not primarily a document-volume problem. It is a relationship problem. Every change may affect a global system description, one or more clients, several local requirements, and multiple approval pathways.
Key Takeaways: A scalable multi-client PSMF model starts by separating client, pharmacovigilance system, and jurisdictional boundaries. Global content should be shared only where it reflects the same operating system, while local teams assess relevant changes through controlled review. Technology may route changes and preserve versions, but regulatory interpretation and approval remain human responsibilities.
Global and Local PSMF Governance Is Not One Universal Document Model
The phrase "global and local PSMFs" can be misleading.
European Medicines Agency (EMA) Good Pharmacovigilance Practices (GVP) Module II states that PSMF content should reflect the global availability of safety information for medicinal products authorised in the EU. It should present information about the pharmacovigilance system at global, regional, and local levels. (European Medicines Agency (EMA))
That does not mean every EU country requires a separate local PSMF or country annex package.
Other jurisdictions may require a national PSMF, Pharmacovigilance Sub-System File (PSSF), local supplement, or another country-specific format. The applicable model must be confirmed for each territory.
For service providers, global and local should therefore be treated as a governance architecture, not a fixed document format.
The global layer describes the common pharmacovigilance system, central processes, shared systems, and oversight arrangements.
The local layer records the information needed to explain how that system operates, differs, or is supplemented within a particular jurisdiction.
The objective is not to remove every country reference from the global description. It is to place information at the level where it can be maintained accurately without creating unnecessary duplication.
For additional regulatory context, see Global vs Local PSMF Compliance
Multi-Client PSMF Management Begins With Three Boundaries
Before designing templates, repositories, or approval workflows, the service provider must define three separate boundaries.
The Client Boundary
Each client requires a controlled environment.
Templates, working methods, and standard review procedures may be shared internally. Client product information, agreements, system descriptions, approvals, and audit histories should remain separated.
This is particularly important when the same service-provider team supports several MAHs.
A contributor may work across multiple accounts, but that does not mean the underlying client records should be visible across those accounts.
PSMF Manager's compliance and security controls include role-based access, two-factor authentication, encryption, audit trails, and backup controls that service providers can assess against their client-separation and intended-use requirements.
The Pharmacovigilance System Boundary
One client does not always equal one PSMF.
EU GVP Module II permits one PSMF to describe a pharmacovigilance system covering one or more medicinal products. A company may also operate more than one pharmacovigilance system, in which case each system requires a separate PSMF.
Each MAH remains responsible for ensuring that an applicable PSMF exists, accurately covers its products, remains accessible, and can be provided to competent authorities. Written agreements should define maintenance, access, and provision responsibilities.
A service provider should therefore organise PSMFs according to the pharmacovigilance systems they describe, not simply according to client names or commercial contracts.
The Jurisdictional Boundary
The third boundary determines which content is genuinely local.
A country-specific file should avoid repeating the complete global narrative unless the applicable regulatory format requires it. A practical local structure should focus on local responsibilities, safety-data collection routes, products, procedures, reporting arrangements, and differences from or additions to the global system.
PSMF Manager's global and local PSMF management workflow centralises shared content while allowing local teams to maintain territory-specific information.
When a global update may affect a local file, the platform can flag the relevant country PSMF, route it for local action, and preserve the resulting decision rather than silently replacing local content.
Follow One Global Change Through the Local Decision Chain
Consider a change in the global literature-monitoring vendor.
At first, it appears to be one contractual update.
In practice, the provider must determine which business partners use that vendor, which products and territories fall within its scope, when the new arrangement becomes effective, and whether local affiliates retain separate literature-monitoring responsibilities.
The global PSMF may require revisions to the organisational description, sources of safety data, procedures, or contractual records.
A local file may require no change, a simple reference update, or a more substantial revision where the local operating model differs from the global process.
Global content should therefore not be pushed directly into every local PSMF.
A controlled sequence is:
Source change → client applicability review → global PSMF assessment → local impact assessment → review and approval
Where source information is maintained in compatible contract, quality, regulatory, or document systems, external data-source integration can notify relevant users and create a corresponding change request within the PSMF workflow. The source update still requires review before it becomes approved content.
The outcome must also be recorded consistently. Ask AI may suggest wording for Annex I or support the review of proposed changes. It does not replace the QPPV, reviewer, or approver, and the final decision remains with the responsible human user.
Standardise Governance, Not the Client's System
PSMF service providers benefit from standardisation, but it must be applied at the right level.
One can standardise how changes are requested, how impact assessments are completed, how contributors are assigned, how reviews are recorded, and how inspection packages are generated.
It should not standardise the factual description of every client's pharmacovigilance system.
Two MAHs using the same case-processing vendor may have different contractual scopes, escalation routes, products, territories, and QPPV oversight arrangements.
Reusing the same narrative without checking those differences creates a PSMF that looks consistent but does not accurately describe either system.
Shared templates should guide the structure and review method. They should not become a source of copied assumptions.
Vendor Oversight Must Be Reconciled Per Client
The service provider is often only one part of a wider outsourced PV network.
A client may use different organisations for case processing, medical information, literature monitoring, signal support, aggregate reporting, regulatory activities, and local representation.
The PSMF should accurately describe the relevant organisational relationships and delegated activities.
Under the standard EU GVP Module II annex structure, Annex B contains lists of contracts and agreements. Annex C contains lists connected to sources of safety data, including affiliates and relevant third-party contacts. Annexes F, G, H, and I cover system performance, audits, products, and change or document-control history.
The PSMF narrative does not need to reproduce every contract clause word for word. It must accurately reflect the responsibility being performed.
For every outsourced activity, the provider should be able to connect four records:
The agreement → the PSMF description → the oversight evidence → the applicable client or territory
A vendor appearing in the contract register but not in the system description is a gap.
So is a vendor described in the PSMF under a scope that no longer matches the active agreement.
Version Control Must Preserve Current and Historical Answers
Multi-client PSMF governance often focuses on one question:
What is the current approved version?
That is essential, but an audit or inspection may also ask:
What did the approved PSMF show on a particular date?
The second question requires more than a current folder and a naming convention.
The provider must preserve the relationship between global changes, local impact decisions, review comments, approvals, and resulting PSMF versions.
PSMF Manager's tracked-changes workflow highlights edits, identifies who made them, and retains reviewer comments and approval activity.
Its version-history capability preserves earlier PSMF versions with timestamps, user details, change descriptions, and audit-trail information.
Together, these controls help distinguish a proposed global update from the approved local response.
This becomes especially important when one global change produces different outcomes across territories.
One local PSMF may require revision. Another may record a no-impact decision. A third may require a future update because the operational change is not yet effective in that market.
For a deeper explanation of these records, see PSMF Version History vs Audit Trail.
Audit the Workflow, Not Only the PSMF
A document review can confirm that the expected wording appears in the PSMF.
It cannot confirm that the local operation works that way.
A shadow audit tests the documented system against actual practice.
Select one local market and follow a real process from beginning to end. Ask the affiliate how a safety report is received, entered, reconciled, escalated, and transferred.
Compare that explanation with the global PSMF, local documentation, procedures, agreements, and system records.
The objective is not to rewrite the PSMF so that it matches an uncontrolled workaround.
Where practice and documentation differ, the team must determine which is correct. The operational process may require correction, the PSMF may require revision, or both may require controlled change.
This test is especially useful before approving a local file, after a vendor transition, during a system migration, or when responsibilities move between global and affiliate teams.
Test PSMF Inspection Readiness by Client, Jurisdiction, and Date
EU GVP Module II requires the PSMF to remain current, permanently available to the QPPV, and permanently available for inspection. A requested copy must be provided no later than seven days after receipt of the request. Where several MAHs use the same PSMF, each applicable MAH must be capable of providing it within that period.
A meaningful internal retrieval test should therefore specify three variables:
One client. One jurisdiction. One date.
The team should be able to identify the applicable global content, current local information, supporting vendor records, approval evidence, and the version that was effective on the selected date.
The seven-day PSMF submission period is intended to support a controlled response, review, and submission. It should not become an emergency reconstruction window.
The PSMF generation workflow creates a read-only PDF from the latest approved content and includes the applicable sections, annexes, bookmarks, and Annex I change-log information. The workflow should be tested with actual client and local records before an inspection request arrives.
Clear Decisions Make Multi-Client PSMF Management Scalable
The strongest multi-client PSMF model is not just about managing multiple PSMFs.
It creates a consistent method for deciding which pharmacovigilance system the PSMF describes, which products are covered, which information belongs at the global level, which requirements are local, and which source changes require review.
It also records who assessed the impact, which local files were affected, what was approved, and which version was effective at a particular time.
Once those decisions are controlled, managing global and local PSMFs across multiple clients becomes more scalable.
Without that control, every new client adds another collection of folders, trackers, copied content, exceptions, and dependencies.
Review the complete PSMF Manager feature set or request a demonstration to assess how global and local workflows, source connections, access controls, tracked changes, version history, Annex I support, and PSMF generation can strengthen multi-client governance.