Corporate SOP Equipment & Automated Systems Life Cycle

Corporate SOP Equipment & Automated Systems Life Cycle

Overview

Purpose

/ The purpose of this SOP is to define the required activities and deliverables related tothe development and validation of equipment and automated systems within the manufacturing, distribution,and development environments at ABC Company Corporation.

Scope

/ This SOP applies to the development, maintenance, and retirement of equipment and automated systems within areas that manufacture, distribute, and/or test medical devices and combination device products at ABC Company Corporation. This includes any equipment or automated system used to automate device design, testing, component acceptance, distribution, or manufacture.
This SOP excludes equipment intended for R&D prototype development (e.g. proof of concept equipment, feasibility tooling, lab notebook testing, etc) use only.
The development and maintenance of capital equipment medical devices or product systems is not in the scope of this SOP.
This SOP applies to class D items ONLY as defined in the table below. Class A, B and C items must meet the requirements of the Corporate Quality Manual and local site procedures.

Continued on next page

Overview, Continued

Item Class / Definition / Example
Class A
(Instrument) / Those items where the calibration defines the complete functionality of the item. /

• Multimeters
• Calipers
• Chatillon Gage

Class B
(Supply Item/Aid) / Consumables, supply items or hand tools that can be purchased Off the Shelf or easily machined. /

• Wipes
• Tweezers
• Screwdriver

Class C
(Fixture/Mold) / A mechanical assembly or test apparatus usually bench top in size that is fixed during operation or mold tooling that does not utilize software, and may require standard utilities (e.g. house air, power, etc). /

• Custom built fixtures
• Trimming fixtures
• UV Bonding fixtures
• Extrusion Molds

Class D
(Equipment) / An instrument or apparatus designed to mechanize a specific operation used to manufacture, test or affect product, regardless of software presence. /

• OEM and OTS equipment
• Hot Box
• Ultrasonic Cleaner

Applicable Documents

/ See the table below for documents referenced in this procedure:
Document Name / Document Number
Corporate Quality Manual
Corporate Quality Systems Glossary
Corporate SOP Process Validation
Corporate Policy on QMAC Software and Computerized Systems
Corporate Policy on Electronic Records and Signatures
Corporate SOP Quality Records
Corp SOP Supplier Quality Management Policy
Corporate SOP Process Flow Chart
Corporate SOP System Retirement
Corp Template System Intended Use
CorpWI for Intended use w Base Risk Doc
Corporate Template E&AS Validation Plan
Software Development Plan Template

Continued on next page

Overview, Continued

Applicable Documents

continued
Document Name / Document Number
Corporate Template URS
Corporate Template E&AS Review Minutes
Corporate Template Functional Specification
Corporate Template System Test Plan
S/W Analysis Summary Report Template
S/W Review Meeting Minutes Template
System Design Specification Template
Corporate WI E&AS System Risk Analysis
Equipment & Automated System FMEA Template
Software Configuration Specification
Software Unit/Integration Test Template
Deployment Plan Template
Corporate Template E&AS Install Verification Protocol
Corporate Template E&AS Operational Test Protocol
Corporate Temp E&AS IV/OT Report Cover Sheet
Validation Report Template

Corporate Definitions

/ Definitionsforthe following termsused in this procedurecan be found in CorpQuality Systems Glossary,S842773-00:

• Change Management
• Change Control
• Configuration Control
• Version Control
• Risk Management
• Off The Shelf Software (OTS)
• Custom Software (CUST)
• Computerized System

Continued on next page

Overview, Continued

Document Definitions

/ The following are definitions for terms that are exclusive to this document:
Term / Definition
Equipment & Automated Systems (E&AS) / Equipment used to produce or test products or components to be used for submission, commercialization, or product/process development (more specifically points of development that are used for product decision making)
Installation Verification Protocol (IV) / Protocol intended to verify that identified equipment and/or software has been installed and set up correctly
Operational Testing Protocol (OT) / Protocol intended to verify the equipment and/or software functions asdescribed in the functional specifications.
Repeat Build System / A system built with the same hardware and software configuration as an existing system in use.
OTS Off the Shelf / Standard Equipment / Equipment that may include operating software available as a stock item, not specially designed or custom-made for BSC or end user requirements.

Training

/ Personnel involved in the development, implementation, maintenance or retirement of equipment and automated systems shall be trained to this SOP.

Continued on next page

Overview, Continued

Roles & Responsibilities

/ The tables below define the roles and responsibilities in the E&AS life cycle. One individual can fulfill more than one role but there must be at least one independent reviewer of deliverables.

Role

/ Role Definition / Responsibility / PDM Approver Role
Process/Equipment Owner (Owner) /

• Function that owns the process within which the equipment is deployed (or is being deployed)
• Function that ultimately owns the equipment during the maintenance and retirement stages of the life cycle.

/

• Ensures the proper execution of all the life cycle activities.
• Defines all use requirements for the equipment.

/ Functional Owner
Equipment Development (ED) /

• Function that transforms the Process/Equipment Owner requirements into equipment by executing the development life cycle activities.

/

• Develops the equipment and software according to the life cycle requirements defined in this SOP.

/ Equipment Engineering
Quality Assurance/ Software Quality Assurance (QA/SQA) /

• Function that provides independent review of deliverables generated during the equipment life cycle

/

• Assures compliance to this policy through review of life cycle deliverables.
• Assures that regulatory requirements for equipment and electronic records/signatures are properly defined and implemented.

/ Quality Engineering

E&AS Life Cycle

Overview

/ There are three stages in the life of Equipment and Automated Systems: development, maintenance and retirement. The development stage represents the time from which the need for equipment is identified to its validated deployment. The development stage consists of five phases: planning, specification, design, construction, and installation & testing. The proper completion of development stagedeliverables results in validated equipment that can be used in product design verification, design validation, distribution, test method validation, process validation, and/or product manufacturing.
The maintenance stage begins once the development stage is complete until the equipment is retired. During the maintenance stage, changes are implemented in a manner that ensures the equipment remains in a validated state.
The retirement stage ensures that the equipment is properly decommissioned and provides for long-term access for associated electronic records, if applicable.

DevelopmentStage

Overview

/ The development stageconsists of five phases:Planning, Specification, Design, Construction, and Installation & Testing. These phases can be done in parallel and may overlap.
The rigor that is applied to the development and validation of the equipment shall be commensurate with the risk the equipment poses to patient/user safety, regulatory compliance, and with the complexity of the equipment itself. In order to accomplish this, a scaling methodology is applied to the activities and deliverables.
Once all five development phasesare completed, the equipment is validated and ready for use.The Installation Verification and Operational Testing activities at the end of this work stream represent the activities performed to meet the “Installation Qualification” requirement defined in the Corporate SOP Process Validation (PDM: S842771-00).
When equipment includes software, software validation activities are nested within the development stage activities.
The overview chart in Appendix A depictsthe various work streams during this stage.
The “Main” work stream (green) at the top includes the activities associated with the definition and construction of software and equipment. The depicted activities are meant for in-house development. However, when a vendor is contracted to develop equipment, similar activities are required only if they will be executed by the vendor (see Corp SOP Supplier Quality Management Policy: PDM S841671-00).
The next work stream down (blue) depicts the risk management activities. Early in this phase the product design FMEA (DFMEA), the process FMEA (PFMEA),or applicable risk documents provide key inputs to decisions regarding the equipment implementation and scaling of the life cycle process.

Continued on next page

Development Stage, Continued

Overview

continued / The third work stream shown (orange) reflects the parallel activities that occur with test development. It is important that test development occur simultaneously with the requirements and design development so that tests can be linked to these elements early and gaps can be identified. This also ensures that requirements and design definition are clearly articulated in a testable manner. Also, during the “building” of software, there are standard software test methodologies that are expected to be included as appropriate. These include, but are not limited to, unit tests, “white box” test, integration tests, etc. depending on the software technology employed.
The last work stream shown (pink) indicates the expected timing for change management activities. Change control of deliverables occurs from the beginning of the process. This means that as documents are developed and used, they need to be revision controlled and approved. This includes all documents, which include those that define the configuration of the equipment. The level of control shall be appropriate to the stage of development. Any version/revision used as part of a document review, testing activity, or other auditable activity shall be controlled.
During the construction phase of the development stage, configuration control shall be implemented on the equipment and software components. This means that all identified issues/bugs shall be addressed and documented. The criteria for when to implement change management during the project shall be defined within the validation plan.

Continued on next page

Development Stage, Continued

Planning Activity

/ The goal of the planning activity is to define the intended use of the equipment, define user requirements, and plan for all development life cycle activities. Figure 1: Planning Diagram details a process flow for a fully scaled equipment development process. Table 1: Planning Deliverables lists the deliverables and responsibilities associated with the flow chart activities along with templates that can be used to document these deliverables.
A clearly defined intended use will help to further scope the user requirements and functionality of the equipment. The Corp Template System Intended Use: 90158868 is used to document the intended use of the equipment and the initial risk assessment. The Corp WI for Intended Use w Base Risk Doc should be used to assist in completion of the system intended use.
In order to complete the initial risk assessment part of the system intended use, it is imperative to have information about the process the equipment will be used with and any risks associated with that process or the product being manufactured or tested by the process. This information is used to make decisions regarding the risk associated with the equipment being developed and the scaling of development activities.
The validation plan defines the specific plan for implementing the aspects of the development life cycle. All rationale for scaling of deliverables shall be documented in the validation plan.

Continued on next page

Development Stage, Continued

Scaling

/ The deliverables and their content are scaled based on the associated risks of the equipment use and the complexity of the equipment. There are two major scaling activities: the scaling in or out of deliverables and the detail of deliverables based on complexity (level of rigor).
The first group of scaling activities is performed as qualified individuals make choices regarding the best way to confirm that the equipment will perform as intended. These choices vary depending on the technology used, the amount of control ABC Company has over the actual development of the equipment (i.e. contract development or purchased “off-the-shelf”), the extent of integration between hardware and software, and a variety of other circumstances. In some cases, a vendor audit can be performed to confirm that the vendor employs good development practices. In cases where the development occurs internally, good development practices must be used with confirming objective evidence. In all cases, the activities represent the due diligence performed to confirm the equipment, and associated software, meets its intended use. This scaling is documented and approved in the Validation Plan which indicates all activities to be performed that will confirm the equipment performs as intended. The associated Validation Report cites the completion of these activities as evidence to support the conclusion that the equipment including any software is validated. When dealing with equipment and/or automated systems that do not contain software all software specific deliverables can be scaled out.
The second scaling activity occurs during the completion of the deliverables agreed upon in the first scaling activity. Based on the risk and complexity of the equipment the level of rigor and detail required to document each required deliverable may vary. As the equipment is developed, complexity of the equipment may drive more depth of the deliverables in order to ensure complete and clear definition of the equipment.
Scaling methods, such as combining required elements into a single document,rationalizing a required deliverable,or changing the quantity/type of reviews, can be utilized as long as it is defined, with justification and approved in thevalidation plan.

Continued on next page

Development Stage, Continued

Scaling

continued / Use the Patient Risk and Compliance Risk from the system intended use to determine level of concern according to the following table:
Level of Concern Table
Compliance Risk
Low / Medium / High
Patient Risk / Low / 3 / 3 / 2
Medium / 2 / 2 / 1
High / 1 / 1 / 1
Levels of Concern as follows:
1 = Major
2 = Moderate
3 = Minor
The following scaling table shows the required deliverables based on level of concern and equipment type.

Continued on next page

Scaling Table

Development Stage Phases / Level of Concern
Deliverable / 3 / 2 / 1
(Minor) / (Moderate) / (Major)
OTS / CUST / OTS / CUST / OTS / CUST
Planning / Intended Use / Base Risk Assessment (AA) / R / R / R / R / R / R
Validation Plan (01) / R / R / R / R / R / R
User Requirements Specification (URS) (AA) / O / O / O / R / R / R
Project Review / O / O / O / R / R / R
Specification / Functional Specification (FS) (AA) / R / R / R / R / R / R
Risk Analysis (01) / O / O / R / R / R / R
Test Plan (AA) / O / O / O / R / R / R
Vendor Management (AA) / O / R** / O / R** / O / R**
Validation Plan (AA) / R / R / R / R / R / R
Requirements Traceability Analysis (URS to FS) (AA) / O / O / O / R / R / R
Project Review / O / O / O / R / R / R
Design / Software / Equipment Design Deliverables(AA) / O / R / O / R / R / R
Risk Analysis (AA) / O / O / R / R / R / R
Design Freeze Design Review / O / R / O / R / R* / R
Construction / Software Configuration Specification (AA) / R / R / R / R / R / R
Software Source Code & Build Documentation (AA) / O / R / O / R / O / R
Software Unit / Integration Test (AA) / O / O / O / R / R* / R
Code Review / Walkthrough Minutes (AA) / O / O / O / R / R* / R
Equipment Build Documentation (AA) / O / R / O / R / R / R
Deployment Plan (AA) / O / O / O / O / O / O
Requirements Traceability Analysis (FS to IV&OT) (AA) / R / R / R / R / R / R
Installation Verification Protocol (AA) / R / R / R / R / R / R
Operational Testing Protocol (AA) / R / R / R / R / R / R
System Freeze / Test Readiness Review / R / R / R / R / R / R
Installation & Testing / Installation Verification Report (AA) / R / R / R / R / R / R
Operational Testing Report (AA) / R / R / R / R / R / R
Operation & Maintenance Deliverables (AA) / R / R / R / R / R / R
Validation Report (AA) / R / R / R / R / R / R

*May be verified through vendor management.

**See Corp SOP Supplier Quality Management Policy

RRequired Deliverable (unless rationale provided)

OOptional Deliverable

N/ANot applicable

(XX)Must be released to at least revision XX by end of phase

Development Stage, Continued

Figure 1: Planning Activity Diagram

Continued on next page

Development Stage, Continued

Table 1: Planning Deliverables

Activity / Responsible / Deliverable(s) / Template Options / Approvers / PDM Doc Type
Provide input information from risk management documents, process flow charts andother source of risk information. (e.g. PFMEA, DFMEA, Process Flow Chart(s) and/or Hazard Analysis) / Owner / N/A / N/A / See PDP Design & Process Development Activities / See PDP Design & Process Development Activities
Define intended use and base risk / Owner / IU/Risk Document / 90158868 / Owner, ED, QA/SQA / E&AS Intended Use
Select template set & provide rationale for selection / Owner / Validation Plan / 90220729 / Owner, ED, QA/SQA, Managers / E&AS Quality / Validation Planning / Reporting
Define user requirements / Owner / User Requirement Specification (URS) / 90220977 / Owner, ED, QA/SQA / E&AS URS
Project Review / Owner / Evidence of review / Review Minutes: 90220405 / Owner, ED, QA/SQA / E&AS Review / Report
Make or buy decision / Owner / None / (include in review minutes) / N/A / N/A

Continued on next page

Development Stage, Continued

Specification Activity

/ The goal of the specification activity is to document the functionality of the equipment and begin risk analysis. Figure 2: Specification Diagram details a process flow for a fully scaled equipment development process. Table 2: Specification Deliverables lists the deliverables and responsibilities associated with the flow chart activities along with templates that can be used to document the deliverables.
The intent of the trace analysis at this point is to ensure that the all items listed in the User Requirements Specification (URS) are properly represented in the Functional Specification (FS). In addition, this activity ensures that the planned testing appropriately addresses all areas of the URS and FS.
A cross-functional review of the trace analysis is required. The evidence of the trace analysis review can be generated in multiple ways, for example:

• Embedded tracing in the specification and testing documents. (for example, using a unique numbering system)
• The cross-functional team meets and reviews the trace analysis, then approval of the meeting minutes that contain the results of the review will serve as evidence of review
• Generate a traceability matrix to document the trace analysis.

The validation plan shall indicate which tracing method will be used.
For equipment containing Off the Shelf (OTS) software, all functionality of the software being used by the equipment shall be assessed as part of the validation. OTS software planning and specification deliverables should be assessed through vendor management.

Continued on next page