Annex 11: Progress in EU Computer Systems Guidelines - Pharmaceutical Technology

Latest Issue
PharmTech

Latest Issue
PharmTech Europe

Annex 11: Progress in EU Computer Systems Guidelines


Pharmaceutical Technology Europe
Volume 23, Issue 6

A requirement is a need or expectation that is stated, generally implied or obligatory. ‘Generally implied’ means that it is custom or common practice for the organization, its customers, and other interested parties, that the need or expectation under consideration is implied.

The term ‘requirement’ defines a bounded characterisation of the scope of the system. It contains the information essential to support the operation/operators. Some of these requirements include product requirement, quality management requirement, customer requirement, functional capacity, execution capability, operational usability, information needed to support validation, installation and commissioning, SLC documentation required, user's manuals, training, maintenance manual, system maintenance, system test plan, acceptance criteria and regulatory compliance (i.e., EU Annex 11).

Management starts with requirements gathering and concludes when all requirements have been verified or tested. Requirements can be generated by different interested parties. The scope of the system generates many of the requirements for the operation to be supported and these requirements are typically provided by the system owner. The majority of the development of computer systems fails due to poor gathering of requirements, which negatively affects subsequent development activities and associated working products.

The RS is the deliverable in which all requirements are identified. It describes what the system is supposed to do from process, safety, user and compliance perspectives. The RS deliverable may be used as a framework to select the supplier/integrator and to develop the PQ protocol.

The RS deliverable should include an overview of the process in order to familiarize the application software developer with the user, process and data acquisition requirements of the system, and any special considerations for the project. The system functionality must be well defined at the outset in order to provide the prospective supplier/integrator with enough information to provide a detailed and meaningful quotation. Specifically, on data acquisition systems, the RS deliverable must include definitions of the data to be collected, how the data will be used, how it will be stored and retention requirements, data security requirements and where each operation will be completed.

The RS deliverable addresses:

  • the scope of the system and strategic objectives
  • the problem to be solved
  • process overview, sequencing requirements, operational checks
  • sufficient information to enable the supplier/integrator to work on a solution to the problem (e.g. device driven sequencing, the methods required of the presentation of data, data security, data backup, data and status reporting and trending).
  • redundancy and error-detection protocol
  • operating environmental
  • interfaces (e.g., to field devices, data acquisition systems, reports and HMI), I/O lists, communications protocols and data link requirements
  • information gained from operators and supervisors on the system design requirements and expectations in order to influence how the system is designed and operated
  • type of control and process operations to be performed
  • data storage requirements
  • transaction/data timing requirements and considerations
  • regulatory requirements
  • preliminary evaluation of the technology
  • feasibility studies and preliminary risk assessment
  • safety and security considerations
  • security, other requirements
  • nonfunctional requirements (e.g., SLC development standards, programming language standards, program naming convention standards).

Each requirement in the RS deliverable must be unambiguous, verifiable, traceable, modifiable, usable, consistent (individual requirements must not conflict with each other) and complete.

The RS deliverable is confirmed in a test and/or operating environments during the PQ. This must include the verification of the procedural controls associated with the system that were identified in the RS deliverable. Some requirements may be verified before reaching the qualification phase in the formal validation process.

After the approval of the requirements document, the requirements traceability initiates. It is a sub-discipline of requirements management within software development and systems engineering. Requirements traceability documents the life of a requirement and provides bi-directional traceability between various associated requirements. It enables users to find the origin of each requirement and track every change that was made. For this purpose, it may be necessary to document every change made to the requirement. Traceability is an essential aspect during the verification activities in the SLC, and provides important input into design reviews.

The above represent my recommendations, but there are many ways to implement the management of computer system requirements.

E-records Management

Applicable from creation to eventual disposal, records management may include classifying, storing, securing, and destruction (or in some cases, archival preservation) of records. The ISO 15489: 2001 standard defines records management as "The field of management responsible for the efficient and systematic control of the creation, receipt, maintenance, use and disposition of records, including the processes for capturing and maintaining evidence of and information about business activities and transactions in the form of records".

The general principles of records management apply to records in any format. Digital records (almost always referred to as electronic records or e-records) raise specific issues. It is more difficult to ensure that the content, context and structure of records is preserved and protected when the records do not have a physical existence. Undoubtedly the area in which most Annex 11 recommendations are made is e-records and how to manage them.

Annex 11 e-records management recommendations can be categorized according to the e-record life cycle concept. This is a requirement in understanding any discussion about the controls necessary for proper treatment to ensure authenticity and reliability of records. Such a life cycle may be characterized as periods representing creation, access and use, and destruction.


ADVERTISEMENT

blog comments powered by Disqus
LCGC E-mail Newsletters

Subscribe: Click to learn more about the newsletter
| Weekly
| Monthly
|Monthly
| Weekly

Survey
FDASIA was signed into law two years ago. Where has the most progress been made in implementation?
Reducing drug shortages
Breakthrough designations
Protecting the supply chain
Expedited reviews of drug submissions
More stakeholder involvement
Reducing drug shortages
70%
Breakthrough designations
4%
Protecting the supply chain
17%
Expedited reviews of drug submissions
2%
More stakeholder involvement
7%
View Results
Eric Langerr Outsourcing Outlook Eric LangerTargeting Different Off-Shore Destinations
Cynthia Challener, PhD Ingredients Insider Cynthia ChallenerAsymmetric Synthesis Continues to Advance
Jill Wechsler Regulatory Watch Jill Wechsler Data Integrity Key to GMP Compliance
Sean Milmo European Regulatory WatchSean MilmoExtending the Scope of Pharmacovigilance Comes at a Price
New FDA Team to Spur Modern Drug Manufacturing
From Generics to Supergenerics
CMOs and the Track-and-Trace Race: Are You Engaged Yet?
Ebola Outbreak Raises Ethical Issues
Better Comms Means a Fitter Future for Pharma, Part 2: Realizing the Benefits of Unified Communications
Source: Pharmaceutical Technology Europe,
Click here