Computer System Lifecycle: Considerations

Hello good people of the world! Today’s post is an overview of the lifecycle of a computer system in regulated industries (pharmaceutical, biologics, and medical device manufacturing). It is based on my almost 20 years experience in the field, and will provide you at a high level the things you should be thinking about with respect to computer systems.

1. Requirements Elicitation
Before anything else, we must understand the requirements around the need for a computer system. This could be the hardest step, and is definitely the most important. Spending extra time and expertise here can prevent a lot of problems downstream. Know who your stakeholders are, and elicit their requirements better than they do. You will often (always ?) find end-users may not know what their requirements are, or may not be able to communicate them effectively. Understand the business process you are trying to automate, and ensure you are talking to all stakeholders: end-users, administrators, managers, etc.

2. Supplier Selection
Once you know what your requirements are, you’re going to find someone to help you met your requirements. At this stage it is important to vet your suppliers to make sure they have the required experience and expertise to deliver a solution to meet your requirements. Supplier selection in regulated industries includes a Supplier Audit.

3. Planning
Now is the time to document your plan. Traditionally this plan is called a Validation Plan, or Validation Project Plan, or Project Validation Plan, but I like calling it a Quality Assurance Plan. Validation is one (big) part of ensuring the quality of the delivery of your new computer system, but your planning needs to encompass all quality considerations. Your plan should include:
– change management procedure to be followed in implementing the system
– updates to your system inventory
– business continuity impact assessment
– risk management considerations (project risk, compliance risk, etc.)
– data privacy considerations
– HR data access considerations
– GxP regulatory determination (e.g., System-Level Impact Assessment (SLIA))
– plan for leveraging supplier documentation
– test strategy for backup, archive/retrieval, restore
– system release strategy
– data migration strategy (if applicable)

4. Specifications
Once your plan is in plan (and agreed upon by all stakeholders), now is the time to specify how the system will meet requirements. Depending on the time of system, risk, GxP impact, etc., deliverables of this stage may be a Functional Specification (FS), Functional Risk Assessment (FRA), Design Specification (DS), Configuration Specification (CS), Requirements Trace Matrix (RTM).

5. Verification
Now that your system is specified, it’s time to test it. Again, depending on the project scope, this stage could include an overall Test Plan, draft SOPs (admin, operating, end-user, etc.), protocol generation, RTM update, business continuity and disaster recovery plans, functional testing, training curricula development, and user-acceptance testing (UAT).

6. Release
Everything has gone well and it’s time to put the system into production use. Be sure to consider: SOP approval/effectiveness, updating the RTM again, any testing in production (such as IQ), system release notification, creating an index of system documentation, closing the Quality Assurance Plan with a report (what actually happened versus what was planned), and closing the change control.

7. Operation
Once the system is in use and everyone is happy, the work is not done! Maintain activities should include: change management, incident/problem management, periodic review of the validated state, periodic testing of backups and disaster recovery, and maintaining the system documentation index.

8. Retirement
Hopefully after many years of service, the time will come to retire your computer system. Be sure to consider data archiving and retrieval in this (final) stage of the computer system lifecycle.

Did I miss anything? Comment below.

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Advertisement

Regulations and Guidance for Assessing a Computer System Supplier

Hello good people of the world! Today’s post is continuing the series on compliance in the cloud. Today’s post is a simple list of regulations and guidance that you can provide to someone who asks the question: why do we have to assess suppliers of computer systems/software? These are the reasons why!

FDA 21 CFR Part 820 Quality System Regulation (link)

Section 820.50 Purchasing controls

Each manufacturer shall establish and maintain procedures to ensure that all purchased or otherwise received product and services conform to specified requirements.

(a) Evaluation of suppliers, contractors, and consultants. Each manufacturer shall establish and maintain the requirements, including quality requirements, that must be met by suppliers, contractors, and consultants. Each manufacturer shall:

(1) Evaluate and select potential suppliers, contractors, and consultants on the basis of their ability to meet specified requirements, including quality requirements. The evaluation shall be documented.

(2) Define the type and extent of control to be exercised over the product, services, suppliers, contractors, and consultants, based on the evaluation results.

(3) Establish and maintain records of acceptable suppliers, contractors, and consultants.

EudraLex Volume 4 Annex 11: Computerised Systems (PDF)

Section 3 – Suppliers and Service Providers

3.2 The competence and reliability of a supplier are key factors when selecting a product or service provider. The need for an audit should be based on a risk assessment.

3.3 Documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled.

3.4 Quality system and audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request.

Section 4 – Validation

4.5 The regulated user should take all reasonable steps, to ensure that the system has been developed in accordance with an appropriate quality management system. The supplier should be assessed appropriately.

ICH Guideline Q9 on Quality Risk Management (PDF)

II.4 Quality Risk Management for Facilities, Equipment and Utilities

Computer systems and computer controlled equipment

To select the design of computer hardware and software (e.g., modular, structured, fault tolerance); 

To determine the extent of validation, e.g., 

• identification of critical performance parameters; 
• selection of the requirements and design; 
• code review; 
• the extent of testing and test methods; 
• reliability of electronic records and signatures.

II.5 Quality Risk Management as Part of Materials Management

Assessment and evaluation of suppliers and contract manufacturers

To provide a comprehensive evaluation of suppliers and contract manufacturers (e.g., auditing, supplier quality agreements).

ICH Guideline Q10 on Pharmaceutical Quality System (PDF)

Section 2.7 Management of Outsourced Activities and Purchased Materials

• Assessing prior to outsourcing operations or selecting material suppliers, the suitability and competence of the other party to carry out the activity or provide the material using a defined supply chain (e.g., audits, material evaluations, qualification); 

ICH Guidance E6 on Good Clinical Practice (PDF)

Section 5.5 Trial Management, data handling, and record keeping

5.5.3 When using electronic trial data handling and/or remote electronic trial data systems, the sponsor should: 

(a) Ensure and document that the electronic data processing system(s) conforms to the sponsor’s established requirements for completeness, accuracy, reliability, and consistent intended performance (i.e., validation).

That’s it! Are there any I missed? Comment below!

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Compliance in the Cloud: ISO 27001 Information Security Management Systems

Hello good people of the world! Today’s post is continuing the series on compliance in the cloud. In the last post, we looked at the FDA’s 21CFR11, which is the legal statute medical device, pharmaceutical, and biologic manufacturers must adhere to when using computer systems for electronic records and/or signatures as part of their manufacturing process for products sold in the United States.

But 21CFR11 is old (1997!) and vague, really only covering at a high-level the requirements for impacted computer systems. Industry has filled in the details, and the ISO standards are a good example of that.

ISO 27001 covers Information Security Management Systems and costs about US$130. Firms may reference ISO certification as evidence of 21CRF11 compliance, such as Microsoft’s statement here.

Below is a summary of the procedural and/or engineering controls required by the standard. You’ll see a lot of overlap with the CFRs, other industry guidance like GAMP5, and other regulations like MHRA’s data integrity expectations.

Management of Policies

1. Policies shall be defined, approved by management, and distributed to employees.
2. Policies shall be reviewed at a planned interval and must be revised when processes change.
3. Responsibilities shall be defined.
4. Duties shall be segregated to avoid conflicts of interest.
5. Communication with relevant authorities shall be maintained.
6. Communication with relevant special interest groups and forums shall be maintained.
7. Information security shall be addressed in all projects.

Human Resource Security

1. Background checks shall be employed.
2. Responsibilities related to information security shall be documented and understood.
3. Training relevant to job functions shall be mandated and documented.
4. A formal disciplinary process shall exist for employees who have committed an information security breach.
5. Responsibilities shall be managed appropriately upon employee termination.

Asset Management

1. An inventory of assets shall be maintained.
2. Each asset shall have an assigned owner.
3. Acceptable use of each asset shall be documented.
4. Distribution and return of assets shall be managed.

Information Classification

1. Information shall be classified in terms of legal requirements, regulatory requirements, confidentiality, etc.
2. Procedures shall exist for the labeling of information by classification.
3. Management of assets shall take into consideration the classification of information associated with the asset.

Media Management

1. Removable media shall be managed per procedure.
2. A procedure shall exist for the proper disposal of media.
3. Procedures shall exist for the physical transfer of media, including protecting against unauthorized transfer, and damage/corruption of media during transfer.

Access Control

1. A procedure shall exist for access control.
2. User access shall be limited to the networks, systems, and information required to perform their job duties.
3. A procedure shall exist for the registration and de-registration of users.
4. A procedure shall exist for the access provisioning of users to all applicable systems.
5. The allocation of privileged access rights shall be restricted and controlled.
6. Authentication information shall be controlled through a formalized process.
7. Asset owners shall review user access at planned intervals.
8. User access shall be removed at appropriate times, such as employee termination.

Cryptography

1. Procedures shall exist for the use of cryptographic controls to protect information.

Physical Security

1. Security perimeters shall be defined to protect areas containing sensitive information.
2. Secure areas shall employee physical entry controls.
3. Physical protection against external and environmental threats shall be established.
4. Procedures shall exist for working in secure areas.

Equipment

1. Equipment shall be protected from problems with supporting utilities.
2. Cabling shall be protected from interception, interference, and damage.
3. Equipment shall be maintained on planned intervals.

Operations Security

1. Operating procedures shall exist.
2. Change management procedures shall exist.
3. Resource use and process capacity shall be measured and understood.

Backup

1. Backup and restore procedures shall be documented and tested on planned intervals.

Logging

1. Event logs shall be employed, retained, and reviewed on planned intervals.
2. Logs shall be protected from tampering, unauthorized access, and loss.
3. Administration activities shall be logged and reviewed on planned intervals.
4. Clocks used by systems shall be synchronized to a single reference time source.

Development Processes

1. Software development procedures shall be documented.
2. Changes to systems in the development lifecycle shall be controlled.
3. Development environments shall be secured.
4. Security functionality shall be tested during development.
5. Acceptance testing shall be established for all new versions of software.
6. Test data shall be controlled.

Suppliers

1. Risks associated with supplier access shall be documented and mitigated.
2. Risks and mitigations shall be communicated and agreed upon with suppliers.
3. Suppliers shall be audited on planned intervals.
4. Changes to supplier relationships shall be controlled.

Incidents

1. Procedures shall exist for the management of incidents.
2. End users shall be required to report incidents.
3. Corrective and preventive actions shall be applied to the management of incidents.

Business Continuity

1. Procedures shall exist for the continuity of business processes during adverse events.
2. Business continuity procedures shall address information security concerns.

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Compliance in the Cloud: SaaS, PaaS, and IaaS

Hello good people of the world! Today’s post is the first in a series on compliant software in the cloud. Cloud software is characterized by running strictly in a web browser; no software is installed on a client’s local hard drive. Cloud software has significant advantages for users and vendors alike, so it is no surprise that it has become the standard for modern personal and business software applications.

It should also not be surprising that cloud software has made it’s way into compliant industries such as medical device, pharmaceutical, and biologic manufacturing, which is the focus of this blog. Vendors and customers alike want the advantages that cloud software bring.

And what are the main advantages? It’s all about distribution. With cloud software, vendors can push new features to users without any downtime or need for manual upgrading, installation, etc. Vendors can monitor software use, responding to bugs much more quickly, and can make improvements based on how users are actually using the software, without any additional overhead for the user.

It has been demonstrated that the data collected through the routine use of cloud software can be immensely valuable, and there’s the added bonus of what insights could be gained when Artificial Intelligence (AI)/Machine Learning (ML) is applied to these big data sets.

Current commercial offerings are often categories into three categories:

• Software as a Service (SaaS)
• Platform as a Service (PaaS)
• Infrastructure as a Service (IaaS)

Going from top to bottom, IaaS is a service offering typically offering server hardware, server virtualization, data storage, and networking. PaaS would offer all that and additionally server operating system(s), middleware (such as load balancing software, malware protection, etc.), and runtime applications such as databases. SaaS would then offer all that and the specific software application to boot.

Examples:

• IaaS: DigitalOcean, Rackspace, Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP)
• PaaS: Heroku, Windows Azure, Google App Engine
• SaaS: Dropbox, Salesforce, Zoom, Facebook

In medical device, pharmaceutical, and biologic manufacturing companies may use IaaS and/or PaaS to outsource some of their IT needs, and may use SaaS products for such functions as Enterprise Resource Planning (ERP), electronic Document Management (eDMS), Laboratory Information Management (LIMS), etc.

Stay tuned for future blog posts on the subject of compliant cloud computing concerns, including: existing solutions, the validation life-cycle, regulatory documentation expectations, data integrity concerns, 483s, and CSA (Computer Software Assurance).

MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Oral Solid Dose – Supporting Equipment and Systems

Hello good people of the world! Continuing the series on oral solid dosage forms, today we’re going to talk about supporting equipment and systems. The main equipment in unit operations get the spotlight when it comes to manufacturing Oral Solid Dosage forms, but they cannot work without supporting equipment and systems.

Supporting Equipment:
Typical supporting equipment in a OSD manufacturing process includes:

1. Air Systems: all modern manufacturing processes use air systems for process, instruments, and environment. HVAC helps control environmental conditions, including particulate (viable and nonviable) counts, temperature, and humidity. Compressed air systems may be used in the process to cool or cover product, such as with nitrogen, or operate unit operation steps, such as in fluid bed drying. Automated systems will use compressed air to pneumatically control valves and other components.
2. Dust Collection: compared to biotech and other pharmacuetical processes, OSD processes have the added complication of dust collection. OSD material movement and processes can create a lot of dust, which can be a risk from a product quality point-of-view, but also a safety point-of-view, since dust can lead to fires and even explosions. Dust collection equipment must be employed to minimize and control dust.
3. Vacuum Systems: vacuum systems may be used for cleaning, dust collection, and also in process steps such as vacuum drying.

Supporting Systems:
Typical supporting systems include:

1. Change Control: it is expected that engineering changes are controlled with quality oversight through a formal process.
2. Preventive Maintenance: it is expected that regular preventive maintenance be performed and documented formally.
3. Calibration: it is expected that “critical” instruments are calibrated at regular intervals traceable to an international standard. Calibration procedures and results must be formally documented. The method to determine and results of the determination of critical instruments must be documented.

What supporting equipment and/or systems do you use in your OSD manufacturing process? Comment below!

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Oral Solid Dose – Unit Operations

Granulator at an OSD Plant in Vietnam

Hello good people of the world! Continuing the series on oral solid dosage forms, today we’re going to talk about unit operations typical in a oral solid dose manufacturing process.

Typical OSD processes may include some combination of weighing/dispensing, material transfer, blending, granulation, drying, milling/sieving, compression, encapsulation, and coating. Some considerations around each step may include:

1. Weighing/Dispensing: includes sampling for quality purposes. Materials to be sampled typically include: APIs, excipients, primary and secondary packaging, cleaning agents. Sampling areas must be protected from contamination.
2. Material Transfer: material flows should be documented and reviewed, with the intention of minimizing any contamination.
3. Blending: materials are typically blended to ensure a uniform composition, prior to downstream process steps. Many methods exist, including: tumble blending, bin blending, and agitator mixers.
4. Granulation: granulation is the process of combining particles into a granule. Many methods of granulation exist: wet massing/extrusion, high shear, spray, speronization, and hot melt extrusion, for example.
5. Drying: the purpose of the drying step is to remove any excess moisture from the drug product. Drying methods include: tray , fluidized bed, and spray drying.
6. Milling/Sieving: the purpose of this process step is to reduce granule size to conform to specification. Some methods include: impact/hammer mills, conical mills, and oscillating horizontal screens.
7. Compression: compression is used to create tablets.
8. Encapsulation: encapsulation is used to create capsules.
9. Coating: coating is used to apply a coat to tablets

In the next post we’ll cover supporting equipment and quality systems. What process steps do you use in your OSD process? Comment below!

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Oral Solid Dose – Material Handling

Hello good people of the world! Continuing the series on oral solid dosage forms, today we’re going to talk about material handling. Oral solid dose manufacturing is typically a batch process, which means materials need to be transferred from step-to-step. Sometimes there is direct conveyance between steps, but often transfer is performed via Intermediate Bulk Container (IBC).

In terms of design, IBCs should be able to handle the worst-case (lowest) density material in the process. IBCs should be cleanable, especially if a single container will support many product manufacturing processes. IBCs should be designed in such a way that they drain easily. Charging/discharging must be considered.

IBCs may be transported on wheels, or by a pallet truck.

Discharging may be facilitated by applying vibrations to the IBC, either internally or externally.

For direct conveyance, gravity, pneumatic conveyance, and mechanical conveyors are options.

What considerations around material handling do you have in your OSD lines? Comment below!

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Oral Solid Dose – Equipment Cleaning

Hello good people of the world! Continuing the series on oral solid dosage forms, today we’re going to talk about equipment cleaning. OSD manufacturing equipment can be notoriously hard to clean, and manual cleaning procedures introduce high risk of contamination and carryover. It is recommended that any new or existing process equipment be cleaned with automated processes wherever possible.

The three automated cleaning processes typically used in industry are:

• Clean-in-Place (CIP)
• Wash-in-Place (WIP)
• Clean-out-of-Place (COP)

CIP is done without moving the equipment, as the name implies, and uses a CIP skid to deliver cleaning and rinse solutions. CIP should not require any manual operations.

WIP is done in-place as well, but may include some manual operations, such as removing filters.

COP requires equipment to be moved to a wash station. Tanks and vessels are typically COP’d.

Some specific concerns related to cleaning OSD equipment include:

• Dry Granulator/Roller Compactor cannot typically be CIP’d. Particularly the auger must be removed and COP’d.
• Fluid Bed Dryers a large and complex, making cleaning difficult. Modern dryers will include CIP/WIP but typically still require manual cleaning of some parts.
• Milling equipment typically requires the screen to be manually removed before any CIP/WIP.
• Tablet presses can be difficult to clean, requiring many manual interventions prior to washing.
• Capsule filling machines should be wettable to allow cleaning.
• Tablet coaters should include WIP

Of course, cleaning processes, whether automated or not, need to be validated. Riboflavin tests may be performed to verify wash coverage, and swabbing can verify lack of residual API and cleaning solutions.

What challenges have you run into in cleaning your OSD manufacturing equipment? Comment below!

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

PLC/HMI IOQ – What to Test?

Hello good people of the world! Today’s post is on initial control system Installation and Operational Qualification (IOQ) of a simple system consisting of an Human/Machine Interface (HMI), Programmable Logic Controller (PLC), and any number of end devices (valves, pumps, sensors, etc.). The question is what should be tested?

Obviously there’s a ton of guidance out there (see e.g.: GAMP) that will have a lot more detail than this post. The purpose here is to list at a high level the tests that could be expected. So let’s get started!

Installation Qualification
IQ can be its own protocol or combined with OQ in an IOQ for cases without a ton of complexity. IQ is supposed to verify the installation of hardware, software, and any peripherals. You also want to check what documentation is available/applicable here. IQ tests may include:

• Documentation Verification (e.g. SOPs, EREC/ESIG assessment, operating/maintenance manuals, panel and electrical drawings, etc.)
• Hardware Verification: verify the make and model of major components at a minimum
• Software Verification: verify/record software versions. You’ve got to know what you’ll be OQ’ing!
• Configuration Verification: verify any hardware and/or software configuration. This could be two tests, one for hardware, one for software.
• Loop Check Verification: verify loop checks are performed.
• Alarm Configuration Verification: ideally alarms a setup in such a way that you don’t have to functionality test them all!
• Any other critical installation items

Operational Qualification
OQ is the meat of your control qualification. Here you want to test critical functions, that hopefully you have identified earlier (see here for one approach). OQ may test:

• Interlock Verification including e-stops. A lot of interlocks are safety/business related, but they’re often included in OQ due to how critical they are.
• Functional Alarm Verification – be sure to include data loss/communication alarms
• HMI Navigation and Layout Verification
• Restart/Recovery Verification
• Sequence of Operations Verification

What kinds of testing are you sure to cover in your control system IOQ protocols? Comment below.

Like this MWV (Mike Williamson Validation) blog post? Be sure to like, share, and subscribe!

Serialization Basics

Hello good people of the world! Today’s post is high-level regarding serialization. Serialization is a process mandated by the world’s regulatory agencies to reduce counterfeit drug products in the market. Besides being costly to drug companies, counterfeit drug products are often less efficacious and less safe than the real drug they are purporting to be. Additionally, counterfeit drug products can be contaminated with other APIs and/or toxic excipients.