35. Performance Qualification (PQ) Package

Regulators agree that you can outsource services, but they insist that you cannot outsource your GXP responsibility. (p. 160)

 

The figure below illustrates the PQ variation on the Standard Package Model

 

 

Every Performance Qualification (PQ) validation package needs to have a Service Level Agreement (SLA) to define the roles, responsibilities and reparations governing the installation and ongoing support of the software application used for GXP purposes. Such an agreement should meet the well-defined needs of the customer as well as those of the vendor (internal or external IT or software supplier) and should provide clear lines of communication and recourse to all participants for issues arising.

Some organizations think of an SLA as a baseball bat to be used against the supplier in times of crises without giving any thought to the necessary ongoing role and responsibilities of the end user. Some organizations operate as if the PQ package is completed and validation is done and over once a GXP system goes live. Both ideas are serious misjudgments. While performing a Needs Analysis and developing a User Requirements Specification (URS) may be Day Zero of the PQ package, Go-Live is just Day One of the Operational Phase of the system’s life cycle. The PQ validation role continues on through to the retirement of the system and archive of the GXP data for retention purposes.

From the regulatory view, all aspects of a software application and its platform system performance can have an impact on GXP data integrity and quality and all are the ultimate responsibility of the end user management employing a specific system for a GXP regulated work process. FDA 483 observations and warning letters go to end user managers, not the system suppliers.

It is end user management’s role to ensure that periodic QA audits are conducted on both internal and external suppliers of GXP systems and data services. It is also the ongoing end user role to do the following:

1. Document a risk analysis for any application software changes, e.g., new patches, releases or upgrades
2. Perform documented new function testing and regression testing defined as per risk analysis and performed within supplier’s test window schedule
3. Update URS and user materials as needed for new procedures or functions with the system
4. Train work process users on changes to the GXP system that impact their operations with it
5. Monitor support and maintenance of GXP platform infrastructure
6. Train users and adhere to standard IT security practices in the work process

A monthly joint IQ/PQ report is ideal, but a quarterly IQ/PQ report by the ongoing end user PQ validation team leader could also be useful for showing “due diligence” management control by end user management for the GXP application and platform system. Such joint configuration management reports need to be negotiated as part of the SLA contract discussions with third parties.

 

Next Month: Software Development Practices – Software Architecture Document (SAD)

Writing software for regulated environments should be a creative discipline and not a creative art form. Guidance from GAMP 5 states that “Each project should define the program coding standards, directory structure standards, and the file naming conventions to be followed. (p. 216)