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
What role should the US government play in the current Ebola outbreak?
Finance development of drugs to treat/prevent disease.
Oversee medical treatment of patients in the US.
Provide treatment for patients globally.
All of the above.
No government involvement in patient treatment or drug development.
Finance development of drugs to treat/prevent disease.
28%
Oversee medical treatment of patients in the US.
12%
Provide treatment for patients globally.
9%
All of the above.
45%
No government involvement in patient treatment or drug development.
7%
Jim Miller Outsourcing Outlook Jim MillerCMO Industry Thins Out
Cynthia Challener, PhD Ingredients Insider Cynthia ChallenerFluorination Remains Key Challenge in API Synthesis
Marilyn E. Morris Guest EditorialMarilyn E. MorrisBolstering Graduate Education and Research Programs
Jill Wechsler Regulatory Watch Jill Wechsler Biopharma Manufacturers Respond to Ebola Crisis
Sean Milmo European Regulatory WatchSean MilmoHarmonizing Marketing Approval of Generic Drugs in Europe
Seven Steps to Solving Tabletting and Tooling ProblemsStep 1: Clean
Legislators Urge Added Incentives for Ebola Drug Development
FDA Reorganization to Promote Drug Quality
FDA Readies Quality Metrics Measures
New FDA Team to Spur Modern Drug Manufacturing
Source: Pharmaceutical Technology Europe,
Click here