The Change Has Happened. The PSMF Has Not Changed Yet.
A PV vendor takes on a new responsibility.
The agreement is updated. The operational team knows. The new process starts.
But when does that change actually become part of the approved PSMF?
This is where PSMF lifecycle management matters.
The lifecycle does not begin when someone opens the PSMF to edit a Section or Annex. It begins when the pharmacovigilance system changes and continues until that change has been assessed, reviewed, approved, recorded, and preserved in the controlled file.
Key Takeaway: A PSMF change is more than an edit. The real control lies in making sure every relevant system change can travel from source to approved PSMF without losing its owner, rationale, review, or evidence along the way.
EU requirements state that the PSMF must be kept up to date and that its information should accurately reflect the pharmacovigilance system in place. The PSMF and its Annex are also subject to version control, as set out in Commission Implementing Regulation (EU) No 520/2012.
That creates an important period between:
“The system changed”
and
“The approved PSMF reflects the change.”
The eight stages below are a practical lifecycle model for controlling that period. They are not an eight-stage sequence prescribed by EMA or any other regulator.
One Change. Eight Handoffs.
Imagine the same vendor change moving through the system.
1. The Source Change Is Identified
The vendor agreement changes.
The first control is simple: does the PSMF process warrant an update?
Source changes may come from SOPs, vendors, organizational changes, products, safety systems, affiliates, audits, or other PV activities.
If this handoff fails, the operational system moves forward while the PSMF remains unchanged.
PSMF Manager's External Data Sources capability can help bring relevant source updates into a managed PSMF workflow.
2. Someone Decides What the Change Means
Now comes the PSMF impact assessment.
Does the change affect:
- Any Section?
- An Annex?
- Both?
- Global and local PSMFs differently?
- No PSMF content at all?
That last outcome matters.
“No PSMF update required” is still a decision that needs to be documented.
The important control is that the change has been assessed and the resulting action is clear.
3. A Controlled Revision Is Opened
Only after the impact is understood should editing begin.
A revision should have an owner, a defined status, and a clear reason for being opened.
This is where PSMF change control separates a governed workflow from ad hoc editing of a shared document.
4. The Draft Is Updated Against the Source
The relevant Section or Annex is revised using the approved source information.
This stage answers:
Does the PSMF still tell the same story as the system it describes?
A vendor responsibility should not say one thing in the agreement and something different in the PSMF.
5. The Draft Has to Survive Review
Review should go beyond checking wording.
Reviewers need to look at:
- The supporting source
- The scope of the change
- Related Sections and Annexes
- Global or local impact
- Whether anything has been missed
Tracked Changes can make the revision visible, but the judgment remains with the reviewer.
6. Approval Turns a Proposal Into a Controlled Decision
Before approval, the update is proposed PSMF content.
After it passes the organization's defined approval workflow, it becomes part of the controlled record.
The evidence should clearly show who approved what and when, with appropriate QPPV visibility and oversight.
Approval should not have to be reconstructed later.
7. Can You Still Explain the Change Six Months Later?
This is where Annex I, audit trail, and version history work together.
| Evidence | Question It Answers |
|---|---|
| Annex I | What changed? |
| Audit trail | Who performed the action and when? |
| Version history | Which approved PSMF state existed? |
EMA requires relevant alterations to be recorded in the PSMF logbook, including the date, responsible person and, where appropriate, the reason for the change.
For a deeper distinction, see PSMF Version History vs Audit Trail.
8. The File Is Generated, Retained, and Becomes the New Baseline
The approved content can now be compiled into the controlled PSMF.
The final version should be retrievable, previous approved versions should remain preserved, and the approved state should be protected from uncontrolled editing.
PSMF Generation and Version History support this final part of the lifecycle.
But Stage 8 is not really the end.
The approved PSMF now becomes the baseline against which the next system change will be assessed.
Where Does PSMF Lifecycle Control Usually Break?
Look for the handoffs:
The source changed, but nobody assessed the PSMF impact.
The content was revised, but the source was not checked.
The update was approved, but Annex I was completed later.
A new version exists, but the previous approved state cannot be retrieved.
If any of these happen, the issue is not simply document maintenance.
It is a break in the PSMF lifecycle.
A well-managed lifecycle keeps the real PV system and the approved PSMF connected through every change, rather than trying to reconcile the two later.
See How One Change Moves Through the Full PSMF Lifecycle
PSMF Manager connects source changes, impact review, tracked revisions, approval workflows, version history, Annex I support, and final PSMF generation within one controlled environment.
Request a Demo to see how a change can move from source to approved PSMF without losing the evidence between the two.