Your PSMF Is a Compliance Document

Treat It Like an Operations Manual Instead

A vendor migrates. The org restructures. A new safety database goes live. None of it makes it into the PSMF, and eighteen months later, the document still describes a system that no longer exists. Nobody decided to let it drift. It just wasn't anyone's job to keep it current, so it didn't stay current.

Sponsors who pass inspection and still have a broken PV system almost always made the same choice early on: they built a document an inspector could read, not one their own team actually uses.

Passing inspection was never the hard part.

The document that was never supposed to sit still

Under GVP Module II, the pharmacovigilance system master file is supposed to give an accurate description of the pharmacovigilance system as it actually exists, not as it existed on the day the file was drafted. It is meant to be readable at any point in time and backed by a log of changes that shows how the system has evolved. That is a description of a living document. Most PSMFs are not treated as one.

Eighteen months in the life of a filed-away PSMF

Figure 1. Three changes, zero updates. The inspection is just the moment the gap becomes visible to someone else.

Where the gap shows up

Nobody owns the update. The organization restructures, a vendor changes, a safety database migrates, and the PSMF still describes the old arrangement. Updating it was never part of how those changes got made, it was a separate compliance task assigned to someone who wasn't in the room.

New staff learn from people, not the document. The PSMF is written for an inspector's checklist, not as a working reference, so new pharmacovigilance staff onboard using tribal knowledge instead. The actual operating knowledge lives in people's heads, not in the one document that is supposed to be authoritative.

Root-cause analysis has nothing to check against. When a signal is missed or a case is dropped, there is no reliable operational document to diagnose against. The PSMF describes an idealized system that may not match what actually happened.

The log of changes stops telling the truth. Entries read “reviewed, no changes” year after year, even as the underlying system visibly changed. That pattern is itself a signal to an inspector that the review was not a real review.

What an operations-manual PSMF actually requires

Assign real ownership. Someone operationally embedded in the PV system should own the PSMF, not solely QA or an external consultant, so updates track process changes as they happen.

Update on the event, not the calendar. The PSMF and its log of changes should update at the moment a process changes, not on a fixed annual cycle that lags behind reality by months.

Make it the onboarding document. New PV staff should learn the system from the PSMF itself, so the document earns its authority instead of competing with informal knowledge.

Reconcile it against reality. Periodically check what the PSMF describes against what the safety database and case logs actually show, the same way you would reconcile a vendor's case count.

Let the log of changes tell a real story. If a review finds nothing to update three years in a row, that is worth questioning, not filing.

The one-minute PSMF test

A quick internal gut check. If you cannot answer confidently, that is where your PSMF has drifted from your PV system.

The cost of getting this wrong

A sponsor can pass an inspection with a PSMF that looks complete and still be running a PV system nobody could accurately describe on paper. That gap doesn't announce itself. It surfaces later, in a missed signal, a slow onboarding, or the next inspection, where the document that was supposed to be the authoritative record turns out to have been fiction for years.

At AWINSA Life Sciences, we build and maintain PSMFs as living operational references.