global sop - documentation management procedure

Global SOP - DOCUMENTATION MANAGEMENT PROCEDURE

HAEMONETICS CORP. - COMPANY CONFIDENTIAL Before using this document, please consult Agile for the latest revision.

of 26

Global: SOP02.01 Revision: CU

Purpose This procedure provides the minimum requirements for Haemonetics Document Control and Records Management, including issuance, review, authorization and control.

Scope This procedure applies to all world-wide facilities and organizations in Haemonetics, including corporate.

This procedure applies to new documents and document revisions under the management and control

of documents that are part of Corporate documentation as well as Quality Management System (QMS), Design History File (DHF), Device Master Record (DMR) and Device History Records (DHR).

The Organization Chart is maintained by Human Resources within the Workday system on a real time basis and is not subject to the controls of this procedure.

1.0 References

Regulations and Standards

Code of Federal Regulations 21CFR §211 Code of Federal Regulations 21CFR §820

Health Canada - Medical Device Regulations (MDR)

European Union Medical Device Regulation 2017/745 (EU MDR 2017/745)

Japanese Pharmaceutical Affairs Law

ISO 13485: Medical Devices

NOTE: the documents referenced above are shown without revision levels, unless specified, the most current version

applies.

Document Document Number

Haemonetics Global Quality Manual QM

Document Control Policy PLY-QMS-0001

Global SOP-Documentation Control System Templates/Forms SOP02.01-A

Global SOP-Document and Part Numbering, Revisions and Naming Standards SOP02.01-B

Global SOP-Record Retention and Retrieval SOP02.03

Review and Control Process for Standards and Guidelines SOP02.04

Drawing Formats SOP02.07

Obsolescence Procedure SOP02.09

Engineering Drawing and Documentation Procedures SOP02.08

Verification of Manufacturing and Service Procedures and Instructions SOP09.08

Global SOP-Employee Training and Training Qualification SOP11.01

Global SOP-Good Documentation Practices SOP30.05

Completion of ECO Cost Impact Worksheets WI1097

Tijuana-Covina Work Instruction - Record Retention and Document

Distribution

WI1627

Global Work Instructions For Supplier Change Notification WI1646

Global Work Instruction-Part and Document Creation, Revision And Non-

Revision Controlled Workflows

WI2242

Work Instruction for Robar Approved Labels WI1811

Global Work Instruction-Change Analyst WI2212



of 26

Global SOP02.01 Revision: CU

Global SOP-NonConforming Event SOP05.01

Global SOP-Label Review, Control and Inspection Procedure SOP08.01

Global SOP-Lot Numbering/Serialization Procedure SOP09.01

Device Master Record, Device History Record and Product Release Procedure SOP09.06

Lot Numbering/List Numbering For Bar Coded Bag Labels SOP09.09

Global SOP - Design Control New Product Design And Release Process SOP15.01

Global SOP-MDD Technical File Requirements SOP15.09

Global SOP-Clinical Investigation Capital , Equipment and Disposables SOP16.09

Global SOP - Temporary Change Notification SOP2529

Agile Training: Navigation, Basic Search And Approve/Reject TI1075

Agile PLM: Manufacturer & Manufacturer Part Creation Training TI1438

Revision and Non-Revision Controlled Approval Matrix Agile100190

Document Translation: Language Verification Form FRM-SOP-02.01-01

2.0 Definitions

Term Definition

Part Is defined as a purchased or manufactured material or good. Drawing, Manufacturer’s

Data Sheet or a Specification document is used to demonstrate the characteristics of the Part.

Document Is defined as controlled written policy, operating procedure, inspection

Procedure, manufacturing procedure, specification, etc. that directly or indirectly affects product quality and which forms the part of QMS, DHF, DMR or DHR

Correction A change or update made to an item (part/document) to correct a clerical error or discrepancy in the content.

Note: Changes made to update or revise a design or process shall follow the

requirements per SOP15.01.

Item Parts and documents are referred to an “Item" in Agile.

IFU or DFU Instructions or Directions for Use

Global Document Globally applicable documentation that covers processes across multiple sites and regions.

Regional Document Specific regional level documentation that covers region specific process detail.

Site Document Specific facility-level documentation that covers site specific process detail.

Translation Process of translating words or text from one language into another without altering the content.

Master file The main file from which one or more translations are performed is called a master

file.

Approval Documented review and acceptance of the proposed change.



of 26


Haemonetics Dictionary………………………………………………………………………………………………. SOP02.00

Dictionary, HSS………………………………………………………………………………………………………….SOP3009

Responsibilities

The following section establishes roles and responsibilities for this Process. Document Control is responsible for

management and control of this process. Document Control personnel will ensure timely review, processing,

documentation, and release of the change in accordance with corporate and regulatory requirements.

In addition, various functions and roles within Haemonetics have been assigned a set of responsibilities to

ensure compliance and efficiency of the change control process. The following table describes each role or

functional area’s key responsibilities throughout the review. These responsibilities are not intended to be all

inclusive or to exclude personnel from reviewing other aspects of the change. Not all functional groups may be

involved in the review and approval of a new or revised document.

Agile Product Lifecycle Management (PLM) is an enterprise-wide software suite designed to manage

product data from concept through obsolescence.

Agile access is requested using the Haemo IT form located on the HaemoNet site. Document Management specific access includes:

General Access - allows user to Navigate/Search/View/Approve/Reject

Item Content Manager - allows user to create and make changes to Parts, Documents and Numbering

and process Revision/Non-Revision Workflows.

Role Responsibilities

Accounting / Finance Consider the impact of change on the cost and resources.

Change Approver

Assess the proposed change for compliance to this procedure, verify affected items

are complete, inventory dispositions are appropriate, supporting documentation is

included and appropriate, relative to the Approver’s area of expertise.

Change Initiator or delegate

Prepare package including all required supporting and affected documents and to

ensure their integrity, accuracy, and sufficiency.

Complete required workflow forms per applicable SOPs.

Affected item attachments conform to applicable Documentation Control SOPs and

other global SOPs where applicable.

Use correct templates for drawings and documents.

Ensure correct document numbers and revisions are used.

Ensure document and workflow includes appropriate document references.

Ensure all facilities impacted by the change are included.

Include clear and accurate mark-ups.

Provide a detailed summary of change and reason for change on the workflow

Cover Page.



of 26


If the change is due to a CAPA, indicate the associated CAPA number on the cover

page of workflow. Provide all-inclusive justification for change.

Include or reference data supporting the change.

Ensure that the workflow has been linked to design history file, when applicable.

o Provide Implementation plan when applicable e.g.

o Material Disposition i.e. use as is, scrap, rework etc.

o Cost Sheets o MI Validation

o Change Affectivity - Lot and/or Serial number, Implementation Date, Expiration Date where appropriate.

Select appropriate approvers where applicable per SOP guidelines.

Manage action through verification to final implementation which could include

training. Before initiating a change to a document, the Change initiator must reach out to

Document Owner with proposed changes.

Complete the ‘Does this change affect the Compliance Matrix?’ Field (Yes or No)

and if the answer is ‘Yes’, update the appropriate Compliance Matrix.

Determine if new procedure is required or if an existing procedure should be

revised. In an event where QSO needs to be implemented prior to 30 days communicate the

change to the impacted personnel.

For earlier effective date, provide a written, signed and dated request to doc control.

Clinical

Ensure that risk of the proposed change has been adequately addressed and the

overall risk of product is within acceptable limits. Marketing or Regulatory claim are in alignment with clinical data.

Clinical data, test method, acceptance criteria was adequate and support the

change.



of 26


Document Control

The Administrator/Change Analyst acts as the Manager of the Documentation Control

process with the responsibility to review and ensure the completeness of documentation packages as submitted by the originators from submission to release,

cancellation, or closure.

Consider the proposed change and ensure that

Workflow conform to document control SOPs.

Documents and drawings conform to approved templates.

Documents and drawings number and revision are correct.

Summary of Change and Reason for Change workflow entries are provided and are

adequate per SOP guidelines. Justification(s) for change is provided and it is

adequate per SOP guidelines. Prerequisite workflows have been approved e.g. component and subassembly

change has been approved prior to final assembly change; Pre-ECO DR has been

approved prior to ECO approval etc.

Workflow has established relationship with design history file (when applicable).

Documents attached to the workflow support the change and disposition strategy

(when applicable). Incorporate/accept redlines at ANR step.

Correct typos at ANR step (if identified).

Manages and maintains the document approval matrices.

Responsible for watermarking previous revision of items on the workflow as

“Superseded”. This does not apply to Parts, MI and SI.

Responsible for approving/releasing labels in the Robar system.

Manages notification of periodic document reviews.

Document Owner

Responsible for content accuracy to ensure integrity and compliance.

Assess the need and scope for developing documents, for system releases, this

includes making sure instructions are available (i.e., Work Instructions).

Responsible for assessing impact of change.

Responsible for ensuring new and revised documents are incorporated into

appropriate training (process and/or job family), and training effectiveness measurement is applied as applicable.

Verify effectiveness of verification and validations testing associated with the

change as applicable. Ensure V&V testing was performed according to the plan.

Ensure procedure makes reference to other relevant procedures

Responsible for periodic review of owned documents.

Information Technology

Consider the proposed change and assess impact to IT infrastructure, software etc.

Validation of Hardware

Validation of Software

Integration with other systems

Archival and Disaster Recovery

Impact to Business Requirements

Compliance with procedures and regulatory standards

Legal

Consider the proposed change and assess impact with regard to

Compliance with product trademarks

Intellectual property issues

Product liability concerns



of 26


Manufacturing

Consider the proposed change and assess Impact to

List Numbers and BOM

Manufacturing documents such as MIs/Forms, SI etc.

Manufacturability Integration into existing process.

Operator Training

Impact to various manufacturing sites

Validation of tools, equipment, fixtures, manufacturing software and manufacturing

process.

Perform disposition of parts, WIP, Finished Goods.

Ensure DMR is accurate, complete and up to date for released product.

MI validations

Ensure all documents, tools, fixtures and manufacturing equipment are alpha

released prior to use in production. Ensure Agile revision of the item match to the revision of the item listed on the

Oracle BOM.

Responsible for requesting new/revised released revision of procedure from doc

control (applicable only to sites where document control is responsible for

distributing released documents).

Marketing

Consider the proposed change and its impact with regard to

Use of approved label fonts, visual identity.

Alignment with marketing specifications and advertising claims.

Content accuracy, graphics, verbiage and revision control.

Impact to existing marketing literature.

Oracle Web Methods

Administrator

Ensure transactional readiness when required prior to release of the change

package.

Purchasing and Contract

Manufacturing

Support change originators in the ECO Cost Impact Worksheet process per WI1097

to ensure product costing and inventory dispositions are managed appropriately.

Communicate changes to external suppliers and providing them with required

documents.

Communicate supplier changes per WI1646 Global Work Instructions for Supplier

Change Notification

Quality (QS)

Consider the proposed change to assess impact with regard to regulatory standards,

corporate or site specific procedures. At a minimum but not limited to: Ensure document/drawing as stand-alone is compliant with regulatory and

procedure requirement and able to withstand audit scrutiny.

Verify effectiveness of verification and validations testing associated with the

change. Ensure V&V testing was performed according to the plan. Ensure that risk management actions relevant to the change have been addressed

and that risk management documents have been properly updated, if required.

Review design history file structure and ensure relationship links established are

correct. Ensure impact, accuracy and traceability of change with regard to Drawings,

Specifications, Calibration, Sterilization, Biocompatibility, Bio burden, Labeling, Shelf

Life, and Device Master Record.

Ensure that First article inspections have been completed and that supplier

management process is in place.



of 26


Review implementation plan and assess the impact of disposition strategy on in-

house inventory, field and return product. Ensure inspections and tests as required, are in place prior to change being

implemented and are adequate to justify change.

Update incoming inspection plans as required.

Regulatory Affairs (RA)

Consider the proposed change and assess impact to previously submitted information

with relevant regulatory agencies or governing bodies. Ensure that reason for change and supporting data meets regulatory strategy and it

is sufficient to meet the needs of necessary regulatory filings or reviews.

Review regulatory impact of implementation plan and material dispositions.

Ensure that claims made on labeling, marketing and service material are in

accordance with regulatory filings or approvals and are adequately supported by design history file.

Ensure that test protocols and reports meet requirements for proposed Regulatory

submissions and are in accordance with existing regulatory filings.

Research and Development (R&D)

Advance Engineering (AE)

Consider the proposed change and assess impact with regards to List Numbers,

Where Used, BOM and Configuration Management. Ensure that proposed change and supporting data meets SOP procedures and

requirements.

Ensure that testing completed supports product and performance specifications

and/or requirements.

Ensure that test method used was validated and adequate for the test.

Ensure that test results and conclusion are thorough and technically accurate.

Ensure that justification provided supports safety and effectiveness of the change. Evaluate the Impact to Stack-up tolerances, CTQs (assembly, inspection, and

function), material compatibility etc.

Confirm that updates to DHF links are correct.

Service

Consider the proposed change and ensure that impact to Services has been

assessed.

Ensure that test data supports field service and/or depot repair implementation

plan. Evaluate the impact of change on service/repair manuals and field service bulletins.

Ensure that changes to field service bulletin and service manuals are in compliance

with design history file and regulatory filings.

Ensure that changes to inspection procedures, reconditioning and refurbishment

procedures, MIs etc. are performed correctly.

Ensure that new part numbers and list numbers are updated in Oracle upon

implementation of change.

Supply Chain

Consider the proposed change and its impact with regards to

Supplied components, unit of measure, purchase cost.

Scheduling of production builds.

Material disposition, inventory holds etc.

Review implementation plan and assess the impact of disposition strategy on in-

house inventory, field and return product

Training

Create/update the training associated with the document release

Assign training as appropriate based on change.

Update relevant PMX upon release of new, or obsoleted documents.

3.1 Approval Responsibility



of 26


Documents in various tiers must be approved by members of appropriate designation in the organizational hierarchy. Following table provides rules governing the selection of approvers. It does not

exclude individuals with Management Responsibility from reviewing Tier IV and Tier V documents. Also, individuals with Management Responsibility may delegate approval responsibility of Tier II and Tier III

documents to members of their staff using documented transfer of authority letters.

Document Tier Approval Level

Tier – I Vice-President or higher (or their delegate)

Tier – II

Tier – III Manager or higher (or their delegate)

Tier – IV

Tier – V

Engineers, Specialist, Team Members, Subject Matter Experts, Associates or higher

Approval Matrix of Controlled documents and parts refer into Agile100190. The Approval Matrices apply

to both the electronic and manual approvals.

Changes to the approval matrix are processed upon written request and must be approved by Document Control Manager and Quality Manager.

In case, an approver is not available to review change package, he/she should send a written request to Document Control to transfer their signature authority to their designee per TI1075.

Doc control may update the approvers in Agile upon written request from the authorized approver or

their supervisor.

Process

4.1 Document Management Policy

The purpose of documentation management is to ensure that all products are built in accordance with

the Device Master Record (DMR) and that the DMR is always current. To accomplish this goal, Document Control procedures are applied to all documents that are used in the design, manufacturing, packaging,

control, and testing of products to show conformance to Quality Management System (QMS) Requirements. These documents must be available at point of use.

Quality Management system (QMS) documents carry the overarching quality requirements that govern the Design History File (DHF) and Device Master Record (DMR) elements. Haemonetics document

management system maintains control over Quality Management System documents as well as all DMR, DHF and Device History Records (DHR). These documents are managed using specific requirements and

controls based on their location in the pyramidal hierarchy. Please refer to Figure.1.



of 26


Tier Description

Tier – I Quality Manual that describes the Quality System. Quality Policy is located within Quality Manual.

Tier – II Corporate Policies which cascade from the key processes defined within the Quality Manual and in turn, define specific requirements for procedures to meet business needs and

international regulatory requirements. Policies also define departmental responsibilities of the

Corporation.

Tier - III Standard Operating Procedures that define how the requirements of the Quality Manual and

Corporate Policies are translated into action for each key process.

Tier - IV Instructional documents and Device Master Record (DMR) documents. They provide detailed work flows to ensure that processes and records generated by the process are consistent

across Haemonetics operations.

Tier - V

Constitutes all records, provide evidence of activities performed that demonstrate conformance of the finished product to specified requirements and/or the effective operation

of the quality system.

4.2 Agile Product Lifecycle Management (PLM) System

Haemonetics uses electronic documentation management system called Agile PLM to maintain and control documents. Agile PLM is a centralized system used to create, approve and retrieve documents.

Agile uses a system of roles and privileges to control access to the documents. Agile is a “read only” closed system. Only designated change analysts within the Documentation Control Department have the ability to

release, archive and obsolete documents. Authorized users can search, review, approve, request changes

and be notified on changes to the documents by logging into the Agile PLM system.

Supporting documents should be uploaded in an electronic format for use in Agile. Scanning is an

acceptable means of converting non-electronic data into electronic format. Manual items such as recorded data or testing from an outside agency also must be in an electronic format.

Quality Policy and Quality Manual

Policies

Standard Operating Procedures

Instructions, Specifications, DMR, Forms and Visual Aids

Records

Tier I

Tier II

Tier III

Tier IV

Tier V

Figure 1



of 26


4.3 Documentation Structure and Format

In order to maintain consistency in format of the documentation produced to support the quality system, it is mandatory for everyone to follow the established standard formats. Additional information may be

added to the approved templates when using them for distinct applications. Sections of the approved

templates must not be removed.

Document formats for procedures and instructions are provided in SOP02.01-A. Forms and Visual aids

associated with parent documents are their own document type independent of their parent. Forms (FRM) and Visual aids (VA) will carry their own revision number and are referenced on the DocuBoM Tab of the

parent document.

4.4 Good Documentation Practices

In a cGMP environment, documentation is used to manage requirements and demonstrate that products are designed and manufactured meet quality, safety and regulatory standards. If an instruction or record

is poorly documented, then the manufacture or Quality assurance/control of a product can be negatively impacted, potentially reducing patient safety.

Haemonetics has established good documentation practices in SOP30.05 in order to prevent the poor and

incorrect documentation practices and to define acceptable for completing or modifying documents required for regulatory compliance.

4.5 Review of Documents

Controlled documents may be reviewed and revised at any time, however, certain controlled documents

(Document Types SOP (including the Quality Manual), TI, WI, PMX, QTP) are subject to a mandatory

review every three years from the “Rev Released Date” on the documents page in Agile. A Document Review Due Date is present on several document types which require review.

Document Owners shall review their documents to assure their relevancy to the QMS, accuracy, facility and human resource names, titles, responsibilities, and compliance.

If the Document Owner determines that no changes are required, they must, using the ‘Send’ feature from the ‘Action’ drop down in Agile, send a message to ‘Document Control’ stating “Periodic Review

Update, No Change Required”. If changes are necessary, a standard change workflow must be initiated.

4.6 Document Obsolescence

Documents that are routed for obsolescence must be accompanied (included in the workflow) by changes

to the documents where they have been referenced in the Agile Record. Examples of this are Compliance Matrix, Training Matrix or other SOPs, Work Instructions etc. Training Administrators for

facilities listed on the Agile Record shall also be included in the workflow routing for informational

purposes or performing updates when required.

Documentation Management System Elements

5.1 Document and Parts



of 26


5.1.1 All parts and documents consist of identification number which is referred to as “Part

Number” and “Document Number” respectively.

5.1.2 Agile PLM system ensures that documents and parts are assigned unique number and that there is no probability of two or more documents or parts having the identical number.

5.1.3 Part and document numbers may be automatically assigned by Agile PLM system or altered

manually to add unique designator. Parts or document numbers are obtained by creating a new item from the appropriate item type category.

5.1.4 Haemonetics document naming convention consists of a document prefix, number and a revision level. Document prefix indicates a general use of a document.

5.1.5 User will select the appropriate document type when creating a new document in Agile.

5.1.6 SOP02.01 lists the document type and the prefixes that are currently in use. New prefixes may be created and added to SOP 02.01-B in Agile as necessary.

5.1.7 Parts and documents that have not gone through the change approval process will be considered uncontrolled and therefore not authorized for production use.

5.1.8 Where applicable, items will have a clear revision level defined to allow identification of sequence of changes and to clearly identify most recent revision.

5.1.9 In some instances, temporary part numbers may be used when an existing released “Production”

lifecycle item is required to undergo a change and where testing is required. Temporary part numbers will have “Prototype” life phase. Temporary part numbers must be made obsolete when

the change is released to production.

5.1.10 SOP02.01-B provides additional guidance on document numbering and control of Revisions.

5.2 Document Translations

5.2.1 The following steps describe the method for controlling translated documents.

5.2.2 All documents with the exception of Manuals shall be translated as required and added to the same agile item as the master document as an attachment.

5.2.3 In an event translations need to be performed, a master document shall be created first and then

translated into required languages. When a change is required, master document shall be updated along with other translation files.

5.2.4 Below are rules for document numbering and revision convention for a document with translated

copies.

In Agile PLM, all translation copies will be maintained along with the master document

under the same Agile part numbering the attachments tab of the document. The master document shall be clearly identified in the file description field.

If the translation is a part of a document and not the full document, the translation shall be identified in its file name as <Procedure #><Language><Page #><Revision>.<Doc

type>.

Master document and translated filename shall include the appropriate language suffix extensions (refer to SOP02.01-B for language codes) and the revision



of 26


Master document and all its translation copies shall retain the same document number and revision in Agile. e.g. <Document Type>-000396-IE (AA1): Master copy and

<Document Type>-000396-FR (AA1): Translated copy

The file description field of each attachment shall designate the language of its content

and identify the master document.

Physical paper copies of master and translated files shall bear the document number, language suffix and its revision (no sub-rev).

5.2.5 Translation process in Agile:

When an existing master document requires an update, then a master document and all

its translation copies shall undergo a revision change i.e. Master document and all its copies will be up-revved e.g. rev AB rev AC.

When an existing master document requires a translation into a new language, the

master document and all its translation copies shall undergo an administrative revision

change i.e. Master document and all its copies will be up-revved using a sub-revision scheme e.g. rev AB rev AB1. Note that numeric revision along with the alpha revision

on the document indicates that the content of the master file has not changed.

5.2.6 FRM-SOP-02.01-01 is required for internal translation and internal SME verification only.

5.3 Parts and Document Types

5.3.1 Part Types:

Part Type Description Examples

Finished Goods

(FG)

Complete final assembly constituting

of components, sub-assemblies, packaging and labeling built per

specifications for commercial sale

Disposable FG,

Equipment FG,

Software FG,

Accessories FG,

Solution FG

Subassembly Assemblies that are used in a higher

level of assembly.

Mechanical Subassembly,

Disposable Subassembly,

Packaging Subassembly

Components Any raw material, substance, piece,

part, software, firmware which is intended to be included as part of the

finished, packaged, and labeled device.

Mechanical Components

Battery, Capacitors, Chemicals,

Bags, Cups, Tubing, Packaging

Tubs, Firmware etc.

Labeling All labels and other written printed or

graphic matter, upon any article or any of its containers or wrappers or

accompanying such article.

Labels

User Manuals

Instructions or Directions for

Use (IFU or DFU)

Drawings/Specifications/Manufacturing Data:



of 26


Drawings/Specifications are used to detail characteristics and provide necessary information for parts i.e. components, subassembly, final assembly, labeling. Drawings

should be prepared in accordance with SOP02.08.

Bill of Materials (BOM):

BOM is used to organize the list of Parts i.e. components and/or sub-assemblies or documents required by product specifications to manufacture and assemble finished

goods. BOM must be maintained current in Agile.

BOMs must contain following minimum information:

o A numbered list of the names and part numbers of components, documents, and

sub-assemblies used to make the final assembly.

o The numbers on this list will correspond to the same numbers used on the

associated drawing (if applicable), and may be part numbers or other specifically assigned numbers.

o The quantity of each numbered item required to build the assembly or sub-assembly.

o A title area containing the part or assembly name and number, including the

present revision level and most current Agile flow number. Agile will indicate the most recent change transaction referencing the part.

o BOM should be revised as necessary along with the parts that are listed on the BOM.

5.3.2 Document Types:

Document Type (prefix)

Use Description

Tier - I

Quality Manual (QM) Describes the Haemonetics Quality System

Quality Policy Outlines policy objectives for and commitment to quality.

Tier - II

Corporate Policy (PLY) Defines departmental responsibilities of the Corporation.

Subtype descriptions below:

Enterprise Information

Technology

Defines Enterprise Information Technology Policies of the

Corporation.

Engineering Defines Engineering Policies of the Corporation.

Finance Defines Finance Policies of the Corporation.

Global Services Defines Global Services Policies of the Corporation.

Human Resources Defines Human Resource Policies of the Corporation.



of 26



Use Description

Legal Defines Legal Policies of the Corporation.

Manufacturing Defines Manufacturing Policies of the Corporation.

Marketing Defines Marketing Policies of the Corporation.

Quality Defines Quality Policies of the Corporation.

Regulatory Defines Regulatory Policies of the Corporation.

Sales Defines Sales Policies of the Corporation.

Supply Chain Management Defines Supply chain Policies of the Corporation.

EH&S Defines Environmental, Health, and Safety policies of the

Corporation.

Tier –III

Health Risk Assessment (HRA)

A Health Risk Assessment is used to evaluate the potential safety risk associated with product that has been distributed to

the field and which has been identified to have a potential quality issue.

Standard Operating Procedures (SOP)

Documents that define Haemonetics’ operating procedures or processes.

Tier – IV

Agile Documentation (Agile) Document to define Agile processes, configuration, training, validations, manuals and other related documentation.

Assessments (ASMT) Document used to document quality gap assessments

(evaluating new or updated procedures, or regulatory changes).

Business System (BSP)

Guidelines for operating and maintaining configuration change

management of a system (i.e. Oracle E-Business Suite (EBS)

System).

Calibration Procedure - QS

(CAL)

Details calibration instructions for inspection, measuring, and

testing equipment

Device Master Record (DMR) Records containing procedures and specifications for each type of device.

Field Service Bulletins (SB)

Bulletins that documents repair, maintenance, installation, and

preventive maintenance of Haemonetics equipment at customer sites.

Form (FRM) A formatted document with blank fields that users can fill in with data and are associated with a top level procedure and/or work

instruction.

Manufacturing Instructions

(MI and MIG)

Detail product-specific manufacturing and inspection steps, in

sequence, and general manufacturing practices.



of 26



Use Description

Process Matrix (PMX)

Lists content or documents associated with a process.

Document compliance matrix of all the sites

Quality Test Procedure

(QTP) Details standard quality test procedures.

Quality Control Procedure (QCP)

Corporate level documents that define practices and procedures specific to the Quality Systems organization.

Service Manual (SM)

Technical manuals that document repair, maintenance,

installation, and preventive maintenance of Haemonetics equipment at customer sites and/or depot repair.

Schedule (SCH) Document used to define schedules, i.e.; site audit schedule.

Standing Instructions (SI) Instructions for items such as manufacturing equipment, inspection systems, and test devices.

Specification (PROC, SDS,

SRS, SPEC)

Document used to define specifications or procedures.(for

product and/or manufacturing Equipment)

Training Instructions (TI) Document used to describe best practice and shared learning “How to”. Does not affect form, fit, function, process, and/or

entail cost.

Training Materials (TRN) Customer facing Training Material

Visual Aid (VA)

A picture, chart, table, etc., used to show an acceptable and

non-acceptable process or used to guide toward a specific or correct way to perform a step in the manufacturing process.

Work Instructions (WI)

Specific instructions on how to perform a process (i.e., system navigation).

Tier – V

Business Process Document

(BPD)

A document that describes a business process or procedure

which may include steps and tasks. This document is outside

the Quality System and should not be used to support the design, manufacture, distribution, installation, and servicing of

products.

Clinical Protocols (TP-CLN) Document that defines the process for conducting a Clinical

Investigation and Tests.

Clinical Reports (TR-CLN) Document that records findings of Clinical Investigations as a

result of the completed Clinical Protocol.

Customer Letters (CL) Letters sent to customers containing information regarding product updates and other related issues.



of 26



Use Description

Customer Response Letter

(CRL)

Letter sent to an individual customer in response to an ad hoc

customer inquiry/request.

Declaration of Conformity

(DCON or DoC)

Document issued by the manufacturer that the concerned

product meets the provision of the MDD.

Design FMEA (RISK-DF) Document to analyze the failure modes of components and subsystem, its impact on the design and end user and the

potential cause of each failure mode.

Plans (PL) Document used to describe activities of various groups and departments directed toward design/development and/or

implementation of products and manufacturing processes.

Global Change Control (GCC) A document that depicts the approval of a global design and /or process change under the Change Management Process

Hazard Analysis (RISK-HA) Document is used to identify, estimate, evaluate, control and

monitor the risk associated with system hazards.

Marketing Promotional

Collateral (COL)

Document that describes training materials, brochures, data

sheets, photos, advertising materials for our products.

Post Market Review Report

(RISK-PM)

Report generated to document periodic review of data and analysis performed to assess risk of a device in the production

and post-production phases.

Process FMEA (RISK-PF) Document to analyze the failure modes of process, its impact on the design and the end user and the potential cause of each

failure mode.

Product Requirements

Documentation (PRD)

Physical and performance requirements provided by Marketing and based on customer point-of-view that act as a set principle

for what a design is intended to do while carefully avoiding specific design solutions. Basis upon which a defined product

specification can be developed.

Project Approval (PPP) (PA) Document used to approve a project.

Quality Meeting Materials

(QMM-, CRB, MRB, CMM)

Quality meeting documentation of CAPA Review Board, Material

Review Board, and Complaints Meeting Materials.

Quality Plan (QP) Document used to define all requirements and tasks to be executed as part of the Quality planning activities.

Requirements (REQ) Document used to define various requirements. .(for product

and/or manufacturing Equipment)

Regulatory Recall Letter

(RCL)

Document used by Regulatory for Global recall updates and

recall documentation tracking.

Risk Management Plan (RISK-PL)

Plan used to document risk management activities that are planned for the new product or change to a product



of 26



Use Description

Risk Management Report

(RISK-RP)

Report is used to document the acceptability of the overall

Residual Risk for the product based on the latest set of risk management activities performed.

System BOM

Listing of all documentation (customer letter, service bulletin,

etc.) of a specific product for a given platform type (OrthoPat, CS5+, etc.).

Technical File (TECH) Documentation relating to the design of a product and its

conformity with the Essential Requirements of the MDD.

Test Protocol (TP) Document that outlines requirements, activities, resources,

documentation and schedules to be completed.

Test Reports (TR)

Document that records data obtained from an experiment of evaluation in an organized manner, describes the environmental

or operating conditions, and shows the comparison of test results with test objectives.

Use FMEA (Risk-UF)

Document to analyze the failure modes during Use, its impact on

the design and the end user and the potential cause of each failure mode.

5.4 Lifecycle Phases:

Agile PLM system uses a series of lifecycle phases to indicate the status of items. Below table describes

these lifecycle phases.

Life Cycle Phases Definition

Parts

Preliminary

The initial stage or creation of a part. Part has not been approved and

released, but the part number has been assigned in Agile.

Feasibility

Part has been released to perform feasibility analysis only and cannot be used to build devices for verification, validation or commercial sale.

Revision is controlled using alpha-numeric revision prefixed with ‘X’ (X01, X02…X99).

Prototype

Part has been released to be built prototype devices in a limited quantity

for verification and/or validation testing only and cannot be used for commercial sale. Revision is controlled using numeric revision (01, 02,

03….99).

Production Part is released for regular production. Revisions are controlled using alpha revision (AA, AB, AC ….ZZ).

End of Life (EOL) Part is no longer available for use in new designs or design changes. Part may be used to sustain Finished Goods in current production or required

http://www.businessdictionary.com/definition/document.html

http://www.businessdictionary.com/definition/record.html

http://www.businessdictionary.com/definition/data.html

http://www.businessdictionary.com/definition/experiment.html

http://www.businessdictionary.com/definition/evaluation.html

http://www.businessdictionary.com/definition/condition.html

http://www.businessdictionary.com/definition/test.html

http://www.businessdictionary.com/definition/objective.html



of 26


Life Cycle Phases Definition

Parts

for service and support of existing FG in the field. End of Life parts cannot be added to new or existing BOMs. Parts in End of Life Phase are controlled

using alpha revision (AA, AB, AC …ZZ).

Obsolete Part is no longer transactable or used.

Document

Preliminary

The initial stage or creation of a document. Document has not been

approved and released, but the document number has been assigned from Agile.

Draft

The content of the document is in draft. Document changes are controlled

using numeric revision (01, 02, 03….99).

Document

The content of the document is final. Document changes are controlled using alpha revision (AA, AB…ZZ).

Obsolete Document is no longer in use.

Note: MI and SI are categorized as documents. However, these two document types use the same life-cycle phases as parts with the exception of End of Life (EOL).

5.5 Workflows:

Agile PLM utilizes workflows as a vehicle to move parts and documents from one life cycle phase to

another or to revise documents and parts within the same life-cycle phase. Changes to the part or document life cycle phase and revision must be approved by appropriate stakeholders.

5.5.1 Workflow Process

The change initiator must obtain a workflow number from the Agile PLM system.

Change initiator must assemble the change package by filling out required forms, attaching or referencing the required information and supporting data.

Must include a Summary of Change and Reason for Change.

Updates to an existing document must show the exact change by including a marked up revision or a thorough summary of the types of changes when changes are extensive.

Affected Items submitted for obsolescence will be watermarked by Doc control so as to be identified as no longer effective.

The workflow is then submitted electronically into Agile.

Following the workflow submission, workflows are routed electronically to the appropriate

individuals for approval.



of 26


Once released, changes are considered permanent and cannot be changed unless a new change is submitted to supersede it.

It is the responsibility of each individual and department to verify the latest revision of the document in the system prior to using it.

5.5.2 Workflow Types

Haemonetics Agile PLM system encompasses series of workflows. Haemonetics workflows are

divided into three categories.

Revision controlled workflows - Used for routing changes to parts and documents which include changes to lifecycle phase and revision.

Non-revision controlled workflows - Used for routing documents for review and approval that will not be revised. As an exception, non-revision workflow (LC) is used

to change the lifecycle phase of parts from production to end of life/obsolete and vice

versa by the users. Approvers for LC workflow for obsolete lifecycle must be based on the guidance of SOP02.09. In addition, Quality and Regulatory representatives should be

notified of the change.

Approved FRM-SOP-02.09-01 must be attached to the workflow before submission.

Exceptions need to be justified and attached to the workflow.

Document control may use this workflow for making error corrections to the lifecycle of

documents when needed. Document control manager needs to approve the correction.

Temporary Change Notifications workflow – Used for routing planned temporary changes of limited scope to temporarily digress from production released product and/or

process specification for definite period of time.

Affected Items submitted for temporary change must be watermarked with expiration date by Doc control. This step shall be performed at submitted step.

Revision and non-revision controlled workflows have been identified with a specific purpose and route specific items. The following table describes the purpose of each

workflow and the documents/parts it can be used for.

Revision Controlled Workflows

Workflow Description Item Types Associated Life Phase

Changes

ECOv7

Engineering

Change Order

ECO workflow must be used for all changes to items and

their associated lifecycles

listed in this section.

Parts (All)

Preliminary Production

Prototype Production

Prototype Prototype

Prototype Obsolete



of 26


Workflow Description Item Types Associated Life Phase Changes

If an item is designated as

“Oracle item” changes have a transactional impact (Oracle).

Production Production

Production End of Life

End of Life Obsolete

Manufacturing

Instructions (MI)

Standing

Instructions (SI)

Forms (FRM)

Visual Aid (VA)

Design FMEA (RISK-

DF)

Device Master

Record (DMR)

Functional Plans

(PL)

Global Change

Control (GCC)

Hazard Analysis

(RISK-HA)

Health Risk

Assessment (HRA) Local Change

Control (LCC)

Post Market Review

Report (RISK-PM) Process FMEA

(RISK-PF)

Product

Requirements Documentation

(PRD)

Requirements

(REQ) Risk Management

Plan (RISK-PL)

Risk Management

Report (RISK-RP) Service Manual

Preliminary Production

Prototype Production

Production Production

Production Obsolete

Preliminary Feasibility

Feasibility Feasibility

Feasibility Prototype

Preliminary Document

Document Document

Document Obsolete

Preliminary Draft

Draft Draft

Draft Document

Draft Obsolete



of 26



Specification

(PROC, SDS, SRS,

SPEC) System BOM

Traceability Matrix

(IOVV)

Use FMEA (RISK-

UF) Cost Sheet (CST)

Clinical Protocols

(TP-CLN)

Clinical Reports

(TR-CLN)

Field Plan Protocols

(TP-FP) Field Plan Reports

(TR-FP)

ECO’s with

Workflow v6

ECOv6 is restricted workflow

for non-design control and administrative updates when

change shall not impact form, fit or function and as such do

not require update to DHF.

It is also used to release and

make changes to Third Party

Distribution and Contract Manufactured products. Only

Document Control has the appropriate Agile privilege

ability to initiate this workflow.

Change Originator will provide approvers to Document

Control per the requirement of Approval Matrix Agile100190

Revision changes may be documented using the sub-

revision convention per

SOP02.01-B

Parts

Documents

All Lifecycle changes enabled

MKO

MKO workflow is submitted for the release of non-inventoried

Marketing promotional

collateral and customer letters.

Marketing Promotional

Collaterals (COL) Customer Letters (CL)

System BOM

Field Service Bulletin (SB)


Document Document

Document Obsolete



of 26



Marketing

Change Order

Customer Response

Letters (CRL)

Regulatory Recall Letter

(RCL)

QSO

Quality

System

Order

QSO workflow is used to create, revise and obsolete

Tier-I, II, III and IV documents.

Agile

Documentation(Agile)

Assessments (ASMT)

Business System (BSP)

Calibration Procedure

(CAL) Corporate Policy (PLY)

Declaration of Conformity

(DCON)

EH&S Policy (EHS)

Finance Policy/Procedure

(FIN) Forms (FRM)

Human Resources Policy

(HR)

Legal

Policy/Procedure(LGL) Process Matrix(PMX)

Quality Control Procedure

(QCP)

Quality Meeting Material

(QMM, CRB, MRB, CMM)

Quality Manual (QM)

Quality Plan (QP)

Quality Test Procedure

(QTP) Schedule (SCH)

Standard Operating

Procedure (SOP)

Technical File (TECH)

Training Instructions (TI)

Validation Master Plan

(VMP) Work Instruction (WI)


Document Document

Document Obsolete

DCO

A DCO workflow is for Business Process Document

(BPD) only.

Business Process (BPD)


Document Document



of 26



Document Obsolete

Non-Revision Controlled Workflows

Workflow Description Item Types Lifecycle

Change

TPR

Test Protocol/

Test Report

An ad-hoc workflow to route Test

Protocols, Test Reports, Engineering

Investigations and Justifications for approval.

Test Protocol (TP)

Test Report (TR) Justifications (JST)

Investigations (INV)


DR

Design or Document

Review

A workflow to approve design reviews,

technical reviews, and document reviews.

Design Review (DR)

None

TCN

Temporary

Change Notification

A workflow to approve all temporary

changes made to product or process.

Parts

MI, SI

SOP, WI

None

LC

Product Lifecycle

Change

A workflow to change an item’s lifecycle without changing its revision.

Parts & Documents

Production

End of Life

(EOL)

Production

Obsolete

End of Life (EOL)

Production

MLD

Mold Approval

Workflow used to validate and approve

a new mold for production or document modifications consisting of alteration or

replacement of mold components to

change part geometry, improve yield, or otherwise change the mold’s design.

Test Protocol (TP)

Test Report (TPR) None



of 26


Workflow Description Item Types Lifecycle Change

OPEC

Oracle Part Enrichment

Change

A workflow to add specified items to

specified organizations (Orgs) in Oracle. This workflow can also be used with a

cost sheet for previously released items that were not released into Oracle and

need to be released in Oracle at the

current revision.

Parts None

5.6 Agile Date Fields:

Agile “Date Released” Field and “Rev Release Date”: These fields reflect the date on which the

applicable change is released in Agile and release date is considered as the effective date of the change on the QSO Workflow.

The effective date of affected items routed on ECO is identified as the Implementation Date within the

Oracle system. The Agile system only retains the approval and release date.

Impacted sites may have different effectivity date based on their disposition plans.

5.7 Changes routed on QSO workflow will be released at the end of assigned training period (typically 30 days) unless specified by the submitter.

Examples of these exceptions are as follows

5.7.1 FDA response

5.7.2 Audit response

5.7.3 Changes that do not require training (administrative changes)

All documents on QSO workflow will become effective on the same day.

Exceptions to Procedure:

6.1 Agile PLM System Interruptions

In the event of a system interruption, Haemonetics may revert back to the manual documentation control

process. Forms found in the current revision of SOP02.01-A can be obtained from Documentation Control

and will be routed manually by the Change Initiator and later added into the Agile PLM system.

6.2 Documentation Integration due to Acquisitions and Product Purchase Agreements

Documents that need to be integrated into the Documentation Control System as a result of a corporate

acquisition or contractual agreement will follow a modified procedure.

6.2.1 At a minimum, any new document type will be defined in SOP02.01-B.



of 26


6.2.2 Formats that vary from existing standards may be grandfathered in upon Haemonetics release. If a document is grandfathered into the system, the document will retain its current revision upon

initial Haemonetics Documentation system release.

6.2.3 At the next Haemonetics revision, the document will be brought into compliance with

Haemonetics documentation standards, if appropriate.

6.2.4 If the document requires revision prior to initial Haemonetics release, it will be brought into

compliance with Haemonetics standards prior to initial release at the discretion of Documentation

Control.

6.2.5 Documentation acquired from a product-only acquisition will be integrated into the

Documentation Control System by initiating a change order.

6.2.6 Transfer of documentation will require signatory authorization from Regulatory/QA of the seller

company verifying the documents being transferred represent the current specifications of the products being acquired. This will be filed as supporting documentation with the initial release

change package.

6.2.7 In the event that the seller provides an electronic copy, the seller must also provide hard copy for

inspection and acceptance by Haemonetics.

6.3 Standalone Software Documentation (HSS)

All procedure type documents (e.g. BSP, SOP, WI, etc.) are required to follow this SOP. All non-procedure type documents (e.g. design documentation, etc.) are not required to follow this SOP. Non-procedure

type documents must be created/maintained as required within the applicable standalone software

procedures.

6.4 Document Control Authorized Changes

Document Control is authorized to make minor correction type changes to documents before the

document is released. These minor correction changes must not affect the intent of the item change. No content changes are allowed after documents have been released and distributed.

Document Control authorized changes may include:

Formatting adjustments such as fixing layout, page numbering, table etc. within document.

Fixing typographical errors e.g. ‘adn’ should be ‘and’

Adding missing workflow relationships

Updates to Agile Cover Page administrative information (Document Owner, Affected Facilities etc)

Changing incorrect revision

Removing track changes, accepting redline, deleting comments existing in released document.

Upload legacy documents into Agile.

Bringing legacy or a new site’s documentation into Agile.

Inclusion or update of reference documents in the reference section of the SOP.

Re-distribution of the updated documents is not required.



of 26


Revision History

Please consult the Document Management system for the revision history.