The pharmacovigilance system master file
The pharmacovigilance system master file describes the pharmacovigilance system a marketing authorisation holder operates, and inspectors assess that system from it. Preparing it means settling how much detail it carries, how it describes the processes and systems behind the pharmacovigilance system, what the qualified person for pharmacovigilance has to be told, which metrics it reports with their results, what its annexes and its logbook each hold, and how deviations and audit findings are recorded in it.
What the file is and when it must be available
The pharmacovigilance system master file is a detailed description of the pharmacovigilance system a marketing authorisation holder uses for its authorised medicinal products. It became a requirement in July 2012 for companies filing new marketing authorisation applications. It is intended to be a live, custom-made document that accurately reflects the pharmacovigilance system put in place for a given product. It is expected to contain meticulous detail, so that the holder's compliance with current good pharmacovigilance practice guidelines can be assessed from it. The file improves oversight of the existing pharmacovigilance system, identifies deficiencies in it, and gives insight into the risks in how specific aspects of pharmacovigilance are conducted.
As of 2014, a file requested as part of the inspection documentation should be made available within seven days, and competent authorities can also ask for immediate access to it at any time in a product's life cycle.
The level of detail
Many questions arose about the file's scope, purpose and implementation after it was introduced, and much has to go into the file for it to meet the goals the EMA set to improve oversight and accountability of pharmacovigilance data. The German Federal Institute for Drugs and Medical Devices and the UK Medicines and Healthcare Products Regulatory Agency have pointed out a number of gaps in the way the file is being implemented, and their feedback has given marketing authorisation holders insight into the regulators' view of the guidelines and their expectations of the file in practice.
By 2014, as more companies implemented the file, the issue was less how to start one than how to overcome the problems inspectors were pinpointing, and many companies were finding they had to overhaul their file because it lacked the detail inspectors sought. The guideline on the file then gave some detail of what was required, but it was fairly open-ended and left a lot of room for interpretation. It did not define boundaries for the data that should be submitted, which made it difficult for companies to determine upper and lower limits. Companies are reluctant to provide more data than required, because they do not want to invest too much time or too many resources in data that might not be needed, and as a result inspectors often found that the file lacked sufficient detail. A file that lacked data raised flags, which often led to further document requests during the inspection. Implementing the file is an immense and complex task: its extensive requirements affect many functions and procedures, maintaining it is resource intensive, and adopting it has meant a steep learning curve for companies.
As of 2014, six aspects were expected to be included in the file:
- a description of the methods used to monitor the performance of the pharmacovigilance system
- a list of performance indicators, covering both the measurements and their targets
- a matrix of pharmacovigilance activities against standard operating procedure names
- a description of the risk-based approach to audit planning, to audit frequency or to both
- the audit notes
- a logbook showing individual changes to the body of the file
Information from inspectors and assessors is a useful guide to help companies improve the file. The level of detail inspectors have started to give in their feedback goes a long way to help companies and their outsourcing partners prepare a comprehensive file, one that limits exposure to problematic inspections.
Processes and systems
By 2014, regulators had made it clear that simply listing the holder's documented procedures is not acceptable. The file should instead describe the processes of:
- continuous monitoring of benefit-risk profiles
- risk management systems
- the collection, collation, follow-up and reporting of individual case safety reports
- the scheduling, production and submission of periodic safety update reports (PSURs)
- the communication of safety concerns
- the implementation of safety variations
Besides the safety database, any other system or database used to receive, collate, record or report safety information must be described, such as medical information systems, product quality databases, clinical trial systems and any other system important for collecting safety data. The holder also has to provide proof that any delegated activities are performed in compliance with legal requirements.
The qualified person for pharmacovigilance
Companies recognise the file as a valuable tool that enables oversight by the Qualified Person for Pharmacovigilance (QPPV), but the QPPV's involvement in dealing with major changes to the file is not clearly understood. As of 2014, the QPPV must be informed of any change of content that meets the criteria for oversight of the pharmacovigilance system's capacity, function and compliance. Changes to the safety database, major contractual changes and organisational changes should also be communicated to the QPPV.
The addition of corrective or preventive actions to the file, for example after an audit or an inspection, must be reported to the QPPV, who should also be able to access information about deviations from the processes defined in the quality management system for pharmacovigilance. When an existing product requires a change or an increased workload in any pharmacovigilance activity, for example through new indications, ongoing studies or additional territories, the QPPV must be notified. Companies also need to ensure the QPPV is advised of:
- a change in the arrangements for providing the file to competent authorities
- the transfer of significant pharmacovigilance services to a third party, such as outsourced PSUR production
- the inclusion of a product in the system the file covers
- the addition of or a change in a pharmacovigilance contact person nominated at national level
The QPPV must accept any such changes in writing. Other inspection findings about the QPPV have concerned proof of the QPPV's registration with the EudraVigilance database, missing details of the QPPV's backup arrangements, and contact information for the local QPPV nominated at national level.
Metrics
As of 2014, metrics, or key performance indicators, are central to the file and must be included in the annexes together with the results of the measurements. The indicators used to monitor the performance of the pharmacovigilance system should include at least the timeliness of individual case safety report and PSUR reporting, the quality of submissions, the timeliness of safety variations, and an overview of adherence to risk management plan commitments or to other obligations or conditions for marketing authorisations.
Inspectors' feedback has defined the extent of some of these metrics. For example, compliance data for safety variations should include:
- the date on which the company decided a safety variation was necessary, and the rationale for choosing that date
- the targeted and the actual submission dates, against the internal timeline in the relevant standard operating procedure
- the date of approval by the Committee for Medicinal Products for Human Use at EU level and at national level, as applicable
- the date the text of the summary of product characteristics was revised, including questions around the ten-day timeline for updating the electronic Medicines Compendium website
- the date the patient information leaflet was introduced to product packs
The annexes and the logbook
The content of the annexes can change frequently, but as of 2014 those changes did not have to be recorded in the logbook. Annex information can be managed outside the file and versioned independently, but it should be available on demand, and change control should be in place for it. Inspection findings on the annexes include missing detail about worldwide agreements applicable to an EU-authorised product, affiliate agreements included, in Annex B; an incomplete list of the countries in which the product is marketed; and insufficient detail about the nature of an activity and the site contact details in Annex C.
The logbook should reflect descriptive changes made to the main body of the file. A frequent finding is that the logbook gives only general descriptions of those changes, such as a major update to the section about the QPPV, whereas it should give specific details of the individual changes made to the body of the file.
Deviations and audit findings
As of 2014, deviations from the quality system should be documented in the main body of the file until they have been resolved. The file should document deviations from pharmacovigilance procedures, including their impact, until they have been resolved. Not every unplanned deviation from a standard operating procedure is expected to be recorded, but the holder is expected to demonstrate that the impact of such deviations was assessed. The logbook should contain information about the addition, amendment and removal of notes concerning significant audit findings or quality system deviations.
Notes on significant audit findings are to be recorded in the main body of the file, and cross-references to the associated audit report are to be avoided. Each note should include a brief summary of the finding, a summary of the corrective or preventive actions, the date the finding was identified and the anticipated resolution date. Only audits the holder conducted or commissioned are to be included in the file.
Corrective and preventive actions associated with unresolved notes should be identified in the corresponding annex. A note can be removed from the file only when its proposed corrective and preventive actions have been fully implemented, and recording the removal verifies that sufficient improvement has been demonstrated or independently verified.