Summary of the Label Approval System (LAS)

Tech. Report

The LAS allows:

• users to manage the creation, review and approval of the label related MELT, Regulatory Review, Translation and Label Approval processes electronically. • permissioned users to view reporting and forecasting information for all services provided within the system.• the repository/archiving of all processes managed within the system.

The following were configured to meet the requirements of Almac Clinical Services and are used for the purpose of Label Generation and Approval:

• Digital Asset Management• Workflow Management• Online proofing • Single Sign On (SSO)

Almac Clinical Services Approach to Validation in General

While it is a regulatory requirement that appropriate measures of validation be performed on computerised systems that are impacted by GMP, Almac Clinical Services believes that validation provides such benefits as: • increasing reliability• decreasing latent errors • reducing long-term maintenance and rework costs.

In line with industry expectation, Almac will scale validation activities according to risk, complexity and novelty while focusing on patient safety and product quality. The role of validation within a project at Almac Clinical Services starts in the planning phase of a project and continues right through to system retirement. This lifecycle approach requires that Validation personnel work collectively with all interested parties involved in the project in order to ensure that the system released into operational use meets the requirements of the business and that it complies with relevant regulations. This collaborative effort helps to ensure that quality is maintained throughout the lifecycle of the system.

The Almac Clinical Services Global Validation Policy exists to describe the type and extent of validation activities required to validate systems that are impacted by GMP. It outlines the approach and commitment of Almac towards performing validation activities within the Company. Global validation procedures exist to define how validation activities will be completed by applying a prospective risk based approach throughout the lifecycle of the computerised system.

• LAS was validated by Almac personnel from within the Validation Department.

• The below documents were generated during validation of the system:

Validation Plan (VP)

Design Qualification

(DQ)

Cutover Qualification

(CQ)

Validation Release Certificate

(VRC)

Validation Summary Report

(VSR)

Installation/OperationalPerformance Qualification

(IOPQ)

User RequirementsSpecification

(URS)

Configuration Design

Specification(CDS)

TraceabilityMatrix

(DQTM)

RiskAssessment

(RA)

RegulatoryReview

(RR)

OQ Testing -Verification of

the execution of the Suppliers OQ

PQ Testing -Requirements-

basedverification

IQ Testing -HW/SW

verification for PQ Environment

HW / SWVerification for

Live Environment

CQ TestingRepresentative

Live Environment Verification

Summary of the Label Approval System (LAS)

The Label Approval System (LAS) is a cloud based system, using the Software as a Service (SaaS) model, and was purchased from BLUE Software. The system is hosted on a private cloud that provides security and business continuity for Almac Clinical Services and our customers. The implementation of the Label Approval System within Almac Clinical Services utilised the predefined BLUE System Implementation Life Cycle (SILC); SILC is a waterfall methodology.

The Label Approval System is a commercial off the shelf (COTS) system and is categorised as GAMP category 4. The Label Approval System consists of various functional components such as Digital Asset Management, Workflow Management, Copy Management, Text Compare, Soft Proofing and Business Intelligence.

Almac’s Approach to Validation of LAS

almacgroup.com

• BLUE employed a standard system lifecycle approach to testing to ensure that the configuration of Almac‘s user requirements were met. The test focus was on verifying that the configuration met the user requirements identified in the approved URS. BLUE generated and executed an:

- Automated Build Protocol and Configuration Test Protocol – the purpose of this protocol was to verify that the configuration documented in the Configuration Design Specification had been accurately and completely applied to the LAS.

- Operational Qualification (OQ) – the purpose of this protocol was to verify that all features, functions and security elements in the LAS were operating properly, as defined in the Configuration Design Specification. The OQ also contained performance testing to verify that the responsiveness of the system was at the level expected.

• The Almac Clinical Services Validation team were responsible for overseeing the generation and execution of PQ functional test scripts to challenge the relevant requirements within the URS as well as the applicable test scenarios identified through the RA. This testing was executed by experienced business representatives and challenged all relevant global processes and SOPs to simulate everyday scenarios in the system. PQ testing was executed across the Craigavon, North Carolina, Pennsylvania and Singapore sites.

• All functional testing of the LAS was managed within HP Quality Center, a test management tool. Hard copies of the executed PQ test scripts and test evidence were printed and are appended to the IOPQ protocol.

• Any test defects encountered during functional testing were managed via the defect management process within Quality Center as defined by Almac SOPs.

• Security Testing – BLUE performed Security and Penetration Testing on the LAS solution to ensure the overall security and integrity of the data stored and used within the system. In addition to this, a security assessment was performed by Almac’s Network & Security Specialist with no notable findings identified.

• Periodic Review will be performed on the system on an annual basis. This will include a review of:

- Additional validation protocols executed since the

previous validation exercise

- The Regulatory Review

- Availability of training material that is fit for ongoing use

- Helpdesk queries

- Change Requests

- Incident Reports

- System Users and their associated access rights

- Data Integrity Verification Activities

• Any changes implemented to the system following go-live are implemented in accordance with defined procedures. Such changes will be acknowledged within the Periodic Review Report.

• VP - provides a roadmap of the validation effort for the project. It also describes what is in and out of scope for the validation of the system.

• DQ - verifies that the design solution is capable of meeting business needs (as per the User Requirements Specification (URS)) and regulatory requirements. The following documents were generated to support the DQ:

• DQTM – the DQTM demonstrates traceability between business requirements (as per the URS) and functional responses (as per the Configuration Design Specification);• RA – generated against the features identified in the URS to identify potential risk scenarios and determine subsequent appropriate mitigations. The RA was used to assist in determining the scope of functional testing; the risks were re-evaluated following execution of functional testing and rescored accordingly.• Regulatory Review – provides an assessment of how the system will comply with pertinent regulations.

• IOPQ – provides a documented record of:

• the installation of the software and hardware relating to the validation testing environment (IQ);

• functional challenging of the system against the Configuration Design Specification (OQ);

• functional challenging of the system against the URS and in line with the risk based approach determined via the RA (PQ);

- traceability of the URS to functional PQ tests is documented in the form of a Trace Matrix. The Trace Matrix was revised following test execution to include the overall test statuses and detail any noteworthy observations, such as test defects, identified during test execution.

• CQ – provides a documented record of the installation and hardware relating to the live production environment and demonstrates the Company’s readiness to go-live.

• VRC – a one page document to release LAS into live production use following post-approval of the above detailed Qualification protocols.

• VSR – provides a summary of the executed qualification documents (refer to the Validation Summary Report which contains a synopsis of the VSR).

Approach to Testing the System

Post go-live Validation Activities

almacgroup.com

• Addressing the regulatory requirements and expectations:• The URS was generated using a Risk-based Requirements Generator (RRG) in accordance with Almac procedures.•The URS specifically detailed relevant requirements necessary to ensure that the system complies with pertinent regulations. This includes requirements required to ensure compliance with 21 CFR Part 11 ‘Electronic Records, Electronic Signatures’ and Annex 11 ‘Computerised Systems’ (EUDRALEX Volume 4 EU Guidelines for Good Manufacturing Practice for Medicinal Products for Human and Veterinary Use). As previously detailed, the focus for PQ testing was on challenging the relevant URS requirements – therefore, it can be confirmed that these regulatory requirements were robustly challenged during functional testing of the system.

- Each requirement, within the URS, was assessed to determine if it was a business need (GxP = N) or if it fulfilled any of the pertinent regulations or was determined to be impactful to patient safety, product quality and data integrity (GxP = Y). - Requirements are included to specify the GxP critical activities that require the entry of electronic signatures. Specifically, there are user requirements specifying that:

• The system requires input of both a unique use ID and a password when entering an electronic signature• Electronic signatures are linked to their respective electronic records.

- The URS also includes requirements for the generation of audit trail reports for GxP critical activities.

These requirements specify that:• The audit trail must record the identity of the operator that creates, modifies or deletes a record.• The audit trail must record the date and time of the activity (time zoned).• The audit trail must record the reason for change – when applicable. The system provides a prompt for entry of a reason for change upon making a change to a critical GxP record.• GxP critical portions of audit trails must be readily available via the user interface and accessible to Quality Assurance and printable.• The audit trail must be protected from being disabled and from intentional or accidental modification.

- The system will ensure that records are protected from unauthorised change through the retention period to enable their accurate and ready retrieval. - The system clock is protected from unauthorised change so that date and time stamps cannot be manipulated.

• Security and Access Controls are specified whereby:• Access to areas of functionality is restricted on the basis of user responsibility. • The system is protected by logical controls to prevent access by unauthorised persons.• The system will log the user out after a period of inactivity.

• Furthermore, protecting the data within the system has been at the forefront of the design solution:

- Where appropriate, data validation rules and drop down lists have been applied to data entry fields to prevent entry of invalid data. - Backups are the responsibility of BLUE. Backups will be performed daily and will be retained for 30 days. In addition, data will be replicated to the DR location on a daily basis.- The network operating system prompts users to change their passwords every 60 days and a user’s previous 24 passwords cannot be reused. The accounts are locked after 3 consecutive unsuccessful login attempts.- BLUE will perform a DR test exercise once every 12 months. BLUE will maintain a Production and DR environment for each BLUE site in separate physical data centres mirroring the data between the two locations. The data centres are located in different cities to ensure that a single disaster does not impact our delivery. They are equipped with fully redundant power, HVAC and networking, along with numerous security measures. BLUE’s Disaster Recovery Time Objective (RTO) is 24 hours and the Recovery Point Objective (RPO) is 24 hours.- The Label Approval System will be protected against unauthorized access. BLUE partner with Equinix to provide a world class hosting service. Equinix provides the physical security and space for BLUE owned and managed equipment to support BLUE’s private cloud hosting offering. Equinix provide advanced physical security with 24/7 on-site security personnel and also provide video surveillance. Equinix also provide advanced fire detection and suppression.

Data Integrity and Compliance with 21 CFR Part 11 and EU GMP Annex 11

© Almac Group Ltd. All rights reserved AM5090

GET IN TOUCH

Global HQ+44 28 3836 2436

EU HQ+353 42 932 0718

Asia HQ+65 6309 0720

Japan+81 367 218720

US HQ+1 215 660 8500

Durham, NC, USA+1 (919) 479 8850

clinicalservices@almacgroup.com

almacgroup.com