The OECD Draft Advisory Document No. 10 THE … eventi/Presentazione-BauerR.pdf · 1 Österreichische Agentur für Gesundheit und Ernährungssicherheit GmbH The OECD Draft Advisory

1

Österreichische Agentur für Gesundheit und Ernährungssicherheit GmbHwww.basg.gv.at

The OECD Draft Advisory Document No. 10

THE APPLICATION OF GLP PRINCIPLES TO

COMPUTERISED SYSTEMS

Dr. Ronald BauerHead of Institute Surveillance

AGENCY FOR HEALTH AND FOOD SAFETY

FEDERAL OFFICE FOR SAFETY IN HEALTH CARE

Traisengasse 5

1200 Vienna, Austria

[email protected]

Disclaimer: The content of this presentation is the author‘s personal opinion.

It does not stand for official views of OECD or the Austrian Federal Office for Safety in Health Care.

www.basg.gv.at 2Ronald Bauer - GLP Round Table Rome, 21.03.2016

Document

Development

2012• IT guideline 17 years old

• The OECD GLP working group

established an IT sub group

• To draft a reworked guidance

document

• Involved countries: AT (lead), BE,

IR, IT, CH, USA/EPA

2013• Presentation of version 1

• Member countries were invited to

comment

2014• Presentation of version 2

• Member countries were again

invited to comment

2014/15• The draft document was published

on the OECD website for a global

public hearing.

• This was a new type of public

hearing

2


Results of the global public hearing

1. A total of approximately 900 comments were received.

Responding countries: AT, BE, CH, DE, DK, ES, FR, IT, JP, MY, PL, NL, UK, US

Responding organisations: ISPE, DGGF (DE), DRQA (NL)

4. Responses were processed within the IT subgroup.

5. Final version was presented to the OECD WG in Paris, April 2015.

6. Document was finally checked for clearity and readability.

7. Document was again sent to all members for final comments.

8. Submitted to OECD by the subgroup for declassification on 14.03.2016.

9. Final and published within a few weeks from now.


Lessons learned from the global public hearing

1. Worked well and was highly effective

2. Valuable contributions from many countries

3. More time to respond and collate would reduce time pressure

3

www.basg.gv.at

The new text considers elements of the PIC/S 11-3 Good Practices for

Computerised Systems in Regulated GxP Environments

The new text considers the systematics of EU GMP Guideline Annex 11

All elements of the currently effective version on Computerised Systems

[OCDE/GD(95)115], that are not out dated were included into the new

version.

Current draft document

Ronald Bauer - GLP Round Table Rome, 21.03.2016 5


General aspects Validation PhaseValidation Phase Operational PhaseOperational Phase

• Life cycle

• Risk assessment

• Scaleabilty

• Personnel, roles,

responsibilities

• Facility

• Inventory

• Supplier

• COTS products

• Change and

configuration

control

• Documentation

• Retrospective Val.

• Prospective Val.

• Change Control

• System description

• User requirement sp.

• QMS

• Customized systems

• Testing

• Data Migration

• Exchange of data

• Accuracy checks

• Data storage

• Print outs

• Audit trails

• Change / config. man.

• Periodic review

• Security / data integrity

• Incident management

• Electronic Signature

• Data approval

• Archiving

• Business continuity

• Retirement

4


Applicability

Applicable to all types

computerized system

regardless of complexity

When to validate

Validation is required, if

systems or data are

• directly relevant for regulatory

submission or

• indirectly support GLP-relevant dataSimple devices: Ballances, Automatic

Pipettes, Refridgerators etc.

Complex systems: Chromatography

Management Systems, Laboratory

Information Systems, (direct / indirect) Data

Capturing Systems, Archiving Systems,

Environmental Monitoring Systems etc.


Qualification

Commercial Off the Shelf

products(COTS) or

automated equipment of low

complexity or small systems

Validation

Prospectively

Excemptions: scope changed or an existing

system becomes GLP relevant; (otherwise NO

retrospective validation)

Life cycle based

Any kind of LC (scaling based on risk

assessment)

… because validity of the incorporated

software can be assumed in case no

customization is performed (e.g. like

electronic pipettes, balances, photometers

and storage devices like refrigerators,

freezers etc.)

5


OperationKey roles: support an,maintenance, use (SD,

study personnel) compliance monitoring (QA,

TFM)

Adequate training to use systen GLP

compliant

Adequate system access privileges

GLP quality management system

Adequate use verified by QA

ValidationKey roles: TFM, QA, IT, validation personnel

[SD involvement if apropriate])

Personnel sufficiently trained to understand

roles, responsibilities and tasks (in house or at

the vendor site)

Verification of capability by TFM [vendor

assessment]

Adequate quality management system (non-

GLP) and assessed by the TFM

Activities

Roles / responsibilities defined

Close cooperation required

www.basg.gv.at 10Ronald Bauer - GLP Round Table Rome, 21.03.2016 10

Local Test Facility Management

Ensure that computerised systems provided

within the company are operated and

maintained locally in accordance with the

Principles of GLP.

Written internal agreements required

Test Facility Management

Overall responsibility to ensure validated

systems

Defines roles and responsibilities for

development, validation, operation and

maintenance of computerised systems

Delegation of responsibility fully or partly to

adequately trained personnel

Evaluate any supplier activity based on risk

assessment and complexity (Keep evidence)

Functions

Incompatibilities of roles and responsibilities during operation should be considered

6


Quality Assurance

Aware of GLP-relevant CS

Verify if standards are met in validation,

operation and maintenance of a CS (own

expertise or by delegation to experts)

Verify adequate use: Sufficient training to

understand the relevant procedures

Inspections of data: Direct read-only access

to the data if only available within a CS

Study Director

Responsibility for GLP compliance does not

depend on technology (e.g. electronic

recording / paper based recording)

If a CS is relevant: Provides sufficient training

to understand the relevant procedures of

adequate use

Global system use: study director should

confirm the validation status of the system(s)

Functions

Incompatibilities of roles and responsibilities during operation should be considered


Services

Supplier

A supplier may be: Third parties, vendors, internal IT departments, service providers

including hosting service providers etc.

Typical supplier activities: e.g. provide, install, configure, integrate, validate, maintain,

modify, decommission or retain a computerised system or related service for data

processing, data storage, archiving or cloud service etc.

Written agreements: clear statements of the responsibilities of the supplier as well as

clear statements about data ownership

Supplier`s Quality System:

Any documented quality system; should be verified by TFM with input from QA

7


Vendor supplied system

Documentation about

validation at vendor’s site

Regulate availability of

documentation by contract

Formal acceptance testing by

the test facility

Written agreements if

validation or operation

requires interfaces to a vendor

Hosted Services

Treated like any other service

Evaluate the relevant service

Estimate risks to data integrity

and data availability

Internal IT department

If part of a GLP facility

reporting to the TFM required

or

treated the same way as a

contracted supplier

Services


Spread sheets

Spreadsheet applications

should be regarded as in-

house developed.

The underlying COTS product

will require an appropriate

form of qualification and

documentation to support the

computerised system.

Qualification of the

underlying COTS product

alone is not sufficient.

COTS

Depending on how a COTS is

used …

• without modification

• after limited

configuration

• after heavy configuration

or even

• customised coding

… a risk based validation like

any other type of software is

required (URS minimum)

Special systems

Mixed systems

Used for both, GLP and non-

GLP studies:

• Validation is required

• Impact of the non-GLP

activity on the GLP quality

should be assessed

• Clear differentiation of

data (what is non-GLP /

what is GLP)

8


Bespoke systems

Made for a trial facility’s specific use: e.g. data capturing systems, spreadsheet templates with

formulas or macros, queries, statistical applications or data evaluation systems

• Highest intrinsic risk / no market experience, no reputation to be asked for

• Supplier assessment / written agreement between the supplier and the TFM is of

paramount importance

• Consider all quality relevant activities of the supplier even at the supplier's business

location

• Any outsourced activities or in-house supplier activities should be part of the computerised

system’s life cycle

• Source code (or all software) in some OECD member countries should be retrievable by the

TFM (escrow arrangements, written agreements)

Hosted System: should be addressed both as customised and vendor-supplied

Special systems

www.basg.gv.at 1616Ronald Bauer - EU QA Conference, 27.04.2016

Inventory

• Up-to-date listing of all GLP-relevant computerised systems and their functionality

• Study relevant computerised systems should be traceable from the study report or the

study relevant method to the inventory.

9

www.basg.gv.at

Example

Data Management

Example

Deviation Management

CAPA

Example

Change Management

Configuration Management

Example

Validation

Risk Management

Focus on the quality of study results to define the

appropriate and most effective (scaled) validation strategy

Should embrace all relevant procedures

Should embrace all relevant procedures

Identifi cation,

assess ment,

mitig ation,

control of risks


www.basg.gv.at

Validation

Operation

retirement

Configuration and change control in all phases


Consider

• Roles, responsibilities

• Hardware and software

• Procedures (review, approval, testing, risk assessment, etc.)

• Software categorization according to GAMP5

10



• Life cycle

• Risk assessment

• Scaleabilty


responsibilities

• Facility

• Inventory

• Supplier

• COTS products

• Change and

configuration

control

• Documentation



• Change Control



• QMS


• Testing

• Data Migration


• Accuracy checks

• Data storage

• Print outs

• Audit trails

• Change / config. man.

• Periodic review




• Data approval

• Archiving


• Retirement

www.basg.gv.at

A validation strategy should be based upon20Ronald Bauer - GLP Round Table Rome, 21.03.2016 20

Scaled validation approach

risk assessment system assessmentsupplier assessmentintended use, complexity

software categories

Justification of strategic decisions (life

cycle, downscaling, testing approach etc.)

and

validation deliverables (validation plan,

protocolls, acceptance criteria)

based on risk assessment

Example: The validation may be limited to the user

requirements specifications, a validation plan, user

acceptance testing and a validation report if it can be

justified based on RA.

11

www.basg.gv.at

A validation strategy should be based upon21Ronald Bauer - GLP Round Table Rome, 21.03.2016 21

Scaled validation approach

risk assessment system assessmentsupplier assessmentintended use, complexity

software categories

Justification of strategic decisions (life

cycle, downscaling, testing approach etc.)

and

validation deliverables (validation plan,

protocolls, acceptance criteria)

based on risk assessment

Example: The validation may be limited to the user

requirements specifications, a validation plan, user

acceptance testing and a validation report if it can be

justified based on RA.

Quality Management Systems:

Development and the validation process should be governed by a

suitable quality management system.

Test facility management should evaluate the vendors development quality

management system risk based.

Operation in accordance with GLP only.


User requirement specifications

Are required regardless of the system`s complexity (incl. provided systems)

• Describe the business process from the user’s point of view

• Associated with an initial risk assessment

• Identify GLP-relevant functions

• Traceable to any further specification document and to the complete testing

documentation

If a provided system has more functions than needed:

• Identify and test all GLP-relevant functions

• Validate even non-GLP-relevant functions if interference with the use of the

computerised system in GLP-studies can not be excluded

12


Testing

Key elements

• Understand the need for testing

• Based upon business process knowledge

• Decision on depth and breadth risk based

• Proper testing procedures (planned / evaluated / reported)

• Roles, responsibilities, documentation standards

• Consider method specific testing (e.g. PQ in a chromatographic system)

• Supplier testing may supplement or replace testing by the TFM

• It is the TFM's responsibility to have evidence of proper testing regardless of

whether the testing is done by the TFM or by a supplier.

• Interface to change control procedures should exist

Might not be limited to areas where GLP data integrity is at risk


Data migration

Example

Migration from a source to a target

system.

Example

Data conversions (from one database

to another; from one data format to

another; from e-records to paper;

software upgrade related change of

format).

Example

Same system migration (moving

application; data from one server to

another)

Example

Version upgrades

13


Data migration

• Risk assessment should be a key instrument of migration

• Should be part of the TFM's validation scope if GLP relevant data is affected

• Data should not be altered during the migration process in value / meaning

• Value and/or meaning of any meta data (e.g. system audit trail) should be ensured

• Data integrity should be verified after migration

• Where data is transferred to another medium it must be verified as an exact copy

prior to any destruction of the original data.

• Electronic signatures should remain valid



• Life cycle

• Risk assessment

• Scaleabilty


responsibilities

• Facility

• Inventory

• Supplier

• COTS products

• Change and

configuration

control

• Documentation



• Change Control



• QMS


• Testing

• Data Migration


• Accuracy checks

• Data storage

• Print outs

• Audit trails

• Change / config. manag.

• Periodic review




• Data approval

• Archiving


• Retirement

14


Accuracy checks

May be required if data are entered manually into an electronic systems

• Risk assessment

• Identify potentials of erroneous data entry

• Evaluate the criticality and consequences of incorrectly entered data

Risk mitigation strategies should be described and implemented

Ensured by adequate documentation to reconstruct the efficacy of entry control

procedures.


Data and storage of data

1. TFM should have an overview of how data is stored and how storage

requirements are met.

2. Distinguished and defined requirements for both, back-up and for archiving

purposes.

3. Stored data should be verified for accessibility, readability and accuracy

periodically and risk based.

4. Hardware and software system changes must allow continued access

5. Aspects of data storage should be considered within each computerised

system during the study phase and in the archiving period.

15


Data and storage of data

Storage for back-up purposes

• Allow recovery following any failure

• Ability to restore the backed-up data should be checked during validation

and monitored periodically

Storage for archiving purposes

• Store data for the retention period by protecting the integrity of data

• Archive the complete supporting information (e.g. maintenance logs,

calibration records, configuration etc.) if essential to verify the validity of

raw data or to reconstruct a whole study or parts.


Electronic records

Test facility management should

• identify any study relevant ER (raw data, derived data and any other study

relevant electronic data).

• assess the criticality of the ER for the quality of study results

• assess potential risks to the ER and mitigation procedures

• manage the effectiveness of risk mitigation throughout the life cycle

16


Print out

If electronic records are migrated to paper records

• ALL electronic data (including any relevant raw data and derived data) as

well as metadata (including information about data changes) should be

printed.

• to allow reconstruction of data validity.

Otherwise relevant electronic records should be verifiable on screen in human-

readable format.


Audit Trail

1. The audit trialing system should be understood to activate and use it

adequately

2. Audit trail policies

3. Modifications to the audit trail settings should be restricted

4. Personnel involved in a study should not be authorised to change settings

5. Periodic risk based review of the audit trail content (interface to the CAPA

system) and based upon an understanding of the use of the system

6. Any recorded information (e.g. log files) may be considered in addition to an

audit trailing system to identify all activities relevant to reconstruct events

relevant for content and meaning of electronic records

17

www.basg.gv.at

Example

Data Management

Example

Deviation Management

CAPA

Example

Change Management

Example

Configuration Management

Risk Management

in operation

Ensure data integrity

Configuration known at any point of the LC

Version traceability: from a preclinical study to the relevant system configuration to permit

the verification of settings as provided by the study plan or the relevant method

Should embracerelevant procedures

Should embracerelevant procedures

Identifi cation,

assess ment,

mitig ation,

control of risks

Ronald Bauer - GLP Round Table Rome, 21.03.2016

33


Periodic review

1. Frequency and depth determined based on a risk assessment considering complexity and

GLP criticality

2. Include the current range of functionality, deviation records, incidents, problems,

unexpected events, upgrade history, performance, reliability, security and reports about

the validated status

3. Involvement of qualified as well as GLP relevant personnel justified

4. Interaction between the periodic review activities and the incident reporting system

• Systems of less criticality / complexity may be excluded from the review (justified risk

based)

• COTS may be excluded from the review if no unexpected events that may have affected

the validated status were reported

18


Physical and logical security and data integrity

1. Documented security procedures

2. Appropriate / maintained authorization concepts

3. Authorisation records periodically reviewed (based upon the criticality of the supported

process or relevant organisational changes)

4. User privileges defined / maintained for OS / applications (incl. roles, responsibilities);

administrator rights not given to study personnel

5. Personnel aware of the importance of data security

6. Methods: Use of keys, pass cards, personal codes with passwords, biometrics,

cryptographic controls or restricted access to specific computer equipment

• Routine surveillance of system access.

• Qualified and approved versions of software

• Introduction of data or software from external sources controlled


Incident management

1. records maintained of any problems or detected inconsistencies

2. study director, test facility management, quality assurance and, if appropriate, the

sponsor should be informed about incidents requiring remedial action

3. study director responsible to define the criticality of incidents for the impact to the study

4. root cause identified and forms the basis of CAPA

5. Trace both ways: from the CS affected by incident to the GLP studies

from a GLP study to the CS affected by incident

6. Incident records should be maintained with the system documentation

7. incident management interfaced with, or integrated with change management,

configuration management, periodic review and training. Incident review part of a

periodic evaluation.

19


Electronic signatures

1. Records that require a signature should be identified (hand-written or ES)

2. Use of ES is at the discretion of the TFM

3. Should have the same legal consequences as a hand-written signature at least within the

boundaries of the test facility

− Should be permanently linked to their respective record

− Should include the time and date that they were applied

− Allow the identification of the signatory and the meaning of the signature.

4. Authenticity is undisputable at least within the boundaries of the test facility

5. Records that are signed electronically and personnel authorized to sign electronically

should be identified (a role in an GLP study should be reflected by the meaning of the

corresponding ES).

6. ES function of a CS should be addressed in the system requirements and validated

7. Changes to an ES record or to the applied ES should be detectable


Electronic signatures

8. Stringency of an ES should be based on risk assessment (Password re-entry should be

considered as a minimum)

9. Metadata which are associated with the electronically signed record should be clearly

identified (method settings and system configuration if relevant for the electronically

signed analytical result)

10. A paper based procedure may be applied to sign records that are printed from the

electronic version.

− Based upon a risk assessment printing has to be done on a clear understanding of the process and the

information that will not be captured in the printout.

− The hybrid solution should be described clearly to identify all additional electronic records or supporting

metadata which are represented by the printed and signed version of a record.

11. If a complete set of electronic records and its printed analogue are maintained in parallel,

TFM should specify the regulated record type.

20


Data approval

An electronic data approval process requires

• documentation in detail

• an electronic signature

and should be part of computerised system procedures and validation of electronic data

approval functionality


Archiving

This advisory document supplements OECD GLP Advisory Document Number 15

1. The GLP Principles for archiving must be applied consistently to both electronic and non-

electronic data.

2. Archiving should be regarded as an independent procedure which should be validated

appropriately. Risk assessment should be applied

3. Electronic data is stored with the same level of access control, indexing and expedient

retrieval as paper based data

4. Long-term integrity of data stored electronically must be ensured

5. Accessibility and readability of data must be maintained.

6. If data media, data formats, hardware or software of archiving systems (not the data

collection systems) change during the archiving period, the TFM should ensure that

there is no influence.

21


Archiving

7. The complete information package should be identified and archived (e.g. raw data,

meta-data necessary to understand the meaning of a record correctly or to reconstruct its

source, electronic signatures, audit trails etc.).

8. In case data conversion is needed before archiving the requirements for migration should

be met

9. It may be considered to archive electronic data in an open format that is independent

from proprietary file format

10. The archivist holds the sole responsibility, may delegate tasks during the management of

electronic data to qualified personnel or automated processes

11. Risk assessment, change control, configuration management and test management are

relevant


Archiving

12. If an electronically signed record is archived electronically, its integrity should be ensured

for the relevant time period (the verification of the integrity of the signed record, the

supporting metadata and the electronic signature should be possible).

13. No electronically stored data should be destroyed without TFM’s and, if applicable,

sponsor's authorisation and relevant documentation.

14. Viewing electronic records without the possibility of alteration or deletion of the

archived electronic records or replicating within a or to another computerized system

does not constitute “retrieval” of records. The archivist should be able to control the

assignment of "view only" access.

15. Any data held in support of GLP-relevant computerised systems, such as source code,

development, validation, operation, maintenance and monitoring records, should be held

for at least as long as study records are associated with these systems.

22


Business continuity and disaster recovery

1. Ensure the continuity of support in case of breakdown

2. Contingency plans need to be well documented and validated

3. Data integrity and study should not be compromised

4. Time required to bring the alternative arrangements into use should be based on risk

assessment (automatic alternatives should be validated)

5. Original or back-up copies of all software in the version relevant for the validated

computerised system are maintained, escrowed, or available by service level agreement

(Procedures should depend on the criticality of the system).

6. If an alternative data capturing procedure is applied, the circumstances of any manually

recorded data subsequently entered into the computer should be clearly identified as

such (manually captured raw data should be retained as the original record).


Retirement phase

1. Should be sonsidered as a system life cycle phase

2. Should be planned risk based and documented

3. If migration or archiving of GLP relevant data is necessary risks to data should be

excluded and the requirements of this guideline apply

23


Questions?

Documents

The OECD Draft Advisory Document No. 10 THE … eventi/Presentazione-BauerR.pdf · 1 Österreichische Agentur für Gesundheit und Ernährungssicherheit GmbH The OECD Draft Advisory