Computer Systems Validation and Data Integrity › wp-content › uploads › 2019 › 12 › DMB... · Requirements to qualification and operation of IT In different GxPs 10 Design,

Computer Systems Validation and Data IntegrityRegulatory Expectations and Findings

24th Annual Conference, Data Management Biomedical Association, Paris

Ib Alstrup, Medicines Inspector GxP IT, Danish Medicines Agency

Ib AlstrupMedicines Inspector, GxP IT

2

• Medicines Inspector GxP IT, DKMA (since 2017)

inspecting CSV in GLP, GCP, GMP, GDP and GVP

• PIC/S DI Guideline

• OECD GLP DI Guideline

• EU GCP eGuidance

• EU GMP Annex 11

• Electronic Engineer (SW design and test)

• Novo Nordisk: ITQA and Supplier Auditor (14 yrs)

• Philips & Ericsson: SW Designer and Tester (12 yrs)

IB ALSTRUP, MEDICINES INSPECTOR, GXP IT

Presentation Topics

3

• Paper vs Electronic Records

• Different GxPs

• ICH GCP E6 R2

• Further Guidance

• Expectations

• Findings


Paper vs Electronic Records

Paper vs Electonic RecordsBatch Record (or BMI Calculation)

5 IB ALSTRUP, MEDICINES INSPECTOR, GXP IT

GxP corrections

• Who

• What

• When

• Why


Paper vs ElectronicThree representations


Paper vs Electronic

Why should we accept

the electronic version?


Paper vs Electronic Records

Electronic documentation from systems without

validated key functionalities, e.g. audit trail,

is like GxP documentation

written by a pencil

You don’t know what was there before

Different GxPs

Requirements to qualification and operation of ITIn different GxPs

10

Design, validation and operation of IT systems described in very different depths

• GLP: 20+ pages

• GMP: 3½ pages

• GCP: 1 page

• GVP: < ½ page

With a few exemptions, no objective reason why our expectations should be different

The more detailed regulatory requirements are (GLP), the less we have to interpret

The opposite is also true ☺


ICH GCP E6 R2

ICH GCP E6 R2 5.5.3about Computer Systems Validation

12

ALCOA+

”Data Integrity”


ICH CGP E6 R2

13

1. GLOSSARY

ADDENDUM

1.9 Audit Trail

Documentation that allows reconstruction of the course of events.


Who entered or changed data?

What* was entered or changed?

When was it entered or changed?

Why was it changed?

*) New and all previous values

14

1.65 Validation of Computerized Systems

A process of establishing and documenting that the specified requirements of a computerized

system can be consistently fulfilled from design until decommissioning of the system or

transition to a new system. The approach to validation should be based on a risk assessment

that takes into consideration the intended use of the system and the potential of the system to

affect human subject protection and reliability of trial results.


ICH CGP E6 R2

Validation should prove that URS

requirements are fulfilled

Validation based on risk

assessment of URS requirements

ICH CGP E6 R2

15

4.9 Records and Reports

ADDENDUM

4.9.0 The investigator/institution should maintain adequate and accurate source documents

and trial records that include all pertinent observations on each of the site’s trial subjects.

Source data should be attributable, legible, contemporaneous, original, accurate, and

complete. Changes to source data should be traceable, should not obscure the original

entry, and should be explained if necessary (e.g., via an audit trail).

4.9.1 The investigator should ensure the accuracy, completeness, legibility, and timeliness

of the data reported to the sponsor in the CRFs and in all required reports.


ALCOA principles

Audit trail incl. all previous values

Who did what, when and why

Data (and audit trail) recorded in

true time

ICH CGP E6 R2

16

5.2.1 A sponsor may transfer any or all of the sponsor's trial-related duties and functions to a

CRO, but the ultimate responsibility for the quality and integrity of the trial data always

resides with the sponsor. The CRO should implement quality assurance and quality control.


Sponsor always responsible for

integrity and quality of data

(and for related IT systems)

ICH CGP E6 R2

17

5.5.3 When using electronic trial data handling and/or remote electronic trial data systems,

the sponsor should:

(a) Ensure and document that the electronic data processing system(s) conforms to the

sponsor’s established requirements for completeness, accuracy, reliability, and

consistent intended performance (i.e., validation).

ADDENDUM

The sponsor should base their approach to validation of such systems on a risk assessment

that takes into consideration the intended use of the system and the potential of the system

to affect human subject protection and reliability of trial results.


Validation according to URS

Sponsor should create (or adopt)

URS

Validation should be based on risk

assessment of URS requirements

ICH CGP E6 R2

18


the sponsor should:

(b) Maintains SOPs for using these systems.

ADDENDUM

The SOPs should cover system setup, installation, and use. The SOPs should describe

system validation and functionality testing, data collection and handling, system

maintenance, system security measures, change control, data backup, recovery,

contingency planning, and decommissioning. The responsibilities of the sponsor,

investigator, and other parties with respect to the use of these computerized systems should

be clear, and the users should be provided with training in their use.


SOPs for system validation,

data collection (data integrity)

system maintenance, security,

backup, recovery and contingency

Roles described, training provided

ICH CGP E6 R2

19


the sponsor should:

(c) Ensure that the systems are designed to permit data changes in such a way that the

data changes are documented and that there is no deletion of entered data (i.e.,

maintain an audit trail, data trail, edit trail).


Qualification should ensure no real

deletion of data (only marked as such)

Captured by audit trail

ICH CGP E6 R2

20


the sponsor should:

(d) Maintain a security system that prevents unauthorized access to the data.


Physical access control

Logical access control

Authentication method

Firewall management

Platform management

Security patching

Security incidents

Penetration testing

Virus protection

Intrusion detection

Use of USB devices

etc

ICH CGP E6 R2

21


the sponsor should:

(e) Maintain a list of the individuals who are authorized to make data changes (see 4.1.5

and 4.9.3).


User management

Review of accesses

Segregation of duties

Least privilege rule

Authentication methods

(incl. remote authentication)

Password management

ICH CGP E6 R2

22


the sponsor should:

(f) Maintain adequate backup of the data.


Data centre

- replication

- physical separation

Backup

- type (incremental or complete)

- frequency (hour, day, week, month)

- retention (day, week, month, forever)

- logical separation (not same server)

- physical separation (media)

Restore test

Disaster recovery

Archival

ICH CGP E6 R2

23


the sponsor should:

(g) Safeguard the blinding, if any (e.g., maintain the blinding during data entry and

processing).


Specification and qualification of

functionality designed to safeguard

blinding, e.g.

- data entry

- audit trail

- edit checks

ICH CGP E6 R2

24


the sponsor should:

ADDENDUM

(h) Ensure the integrity of the data including any data that describe the context, content,

and structure. This is particularly important when making changes to the computerized

systems, such as software upgrades or migration of data.


Qualification and safe operation

(all of the above)

Data migrations should be qualified

(incl audit trail)

Changes should be qualified

(incl upgrade of operating system)

Further Guidance

Further Guidance

26

EMA GCP Q&A

• No. 8: Pitfalls regarding contractual arrangements with vendors of electronic systems

• No. 9: Level of qualification to be performed by sponsor when using electronic systems qualified by a provider / Documentation required to be available during inspection

www.ema.europa.eu/human-regulatory/research-development/compliance/good-clinical-practice/qa-good-clinical-practice-gcp

EMA GCP Reflection Paper

www.ema.europa.eu/en/documents/scientific-guideline/reflection-paper-good-clinical-practice-compliance-relation-trial-master-files-paper/electronic-management-audit-inspection-clinical-trials_en.pdf

EU GCP eGuidance (coming)IB ALSTRUP, MEDICINES INSPECTOR, GXP IT

http://www.ema.europa.eu/human-regulatory/research-development/compliance/good-clinical-practice/qa-good-clinical-practice-gcp

https://www.ema.europa.eu/en/documents/scientific-guideline/reflection-paper-good-clinical-practice-compliance-relation-trial-master-files-paper/electronic-management-audit-inspection-clinical-trials_en.pdf

Expectations

(excerpt)

Access ControlExpectations

28

• Systems should restrict logical access to authorised individuals

• Physical access to data media should be restricted for normal users

• System accounts should be unique (not just a name)

• Normal users should have no admin access to systems (incl. PCs) hosting critical data

• Access roles should be assigned according to the least-privilege rule

• Systems should be able to generate a list of users, to be used for review of users

• Systems should be able to generate a list of login attempts, to be used for review

• All users should have individual accounts, shared accounts should be prohibited

• Access based on segregation of duties, admin users should not conduct normal work

• User reviews should be made at suitable intervals to ensure only approved accesses


Inactivity LogoutExpectations

29

• A system and domain appropriate inactivity logout is defined, shorter rather than longer

• Re-authentication, required after inactivity logout

• Deactivation or change of inactivity logout settings, not possible for normal users


Time SettingsExpectations

30

• System clock and time zone non-editable for normal users (segregation of duties)

• System clock synchronized with connected systems or standards


Audit TrailsExpectations

31

• Record who (incl. role), what, when and why for manual entries, changes and deletions

• Contain new and all previous values must be available

• Recorded in true time, not at end of process; change after critical info is aggravating factor

• Audit trail non-deactivatable, at least for normal users, deactivation should create entry

• Audit trail non-editable, for normal users and preferably for privileged users

• Possible to print and obtain electronic copy, e.g. for regulatory use

• Readable and understandable for normal users, auditors and inspectors

• Reviewable, accommodating an efficient audit trail review

• A procedure for audit trail reviews should exist, incl. what to review, when and by whom

• Audit trails should be reviewed according to the procedure and appropriate actions taken

• Audit trails should be included in backup, restore and archival proceduresIB ALSTRUP, MEDICINES INSPECTOR, GXP IT

Audit TrailsNot required but…

32

• Searchable, e.g. user, parameter, value, date and time interval, reason

• Sortable, e.g. to block out alarms, events and other non-audit trail information

• Exportable (e.g. to Excel), in lack of proper built-in search or sort functionality


Platform Management and Security PatchingExpectations

33

• Operating systems are updated timely according to vendor recommendations

• Operating systems are security patched timely according to vendor recommendations

• Un-patched or unsupported systems are isolated from the internet and remaining network


Cyber Attacks

34

WannaCry (May 2017)

• Preyed on un-supported and un-patched systems

• Spread with user interaction

• Encrypted data and left themunavailable to users

• Recovering from attack is expensive and uncertain

• Microsoft had released securitypatch only 8 weeks beforeattacks exploded

• So, patching must be very timely..!


Cyber Attacks

35

• In June 2019, a large GxP regulated company, informed the DKMA that a facility had“detected a form of ransomware that has caused disruption to some of our IT systems. Neither data integrity [!!] nor client confidentiality has been impacted by the incident” and“we do not have access to information in many of our systems, so we cannot provide live updates on sample progress or details on testing of samples ████”

• In August 2019, a large clinical research facility informed the DKMA that “the database and backup [!!] belonging to a specific GCP study had been hacked and all original data had disappeared” and had been “replaced with bitcoin codes” [Sic.]


Management of FirewallsExpectations

36

• Firewalls should carefully designed only allowing traffic on necessary ports to be opened

• Firewall rules should be documented and approved and should be available for reviews

• Firewall settings should be periodically reviewed against their specifications


Backup, Restore and Disaster RecoveryExpectations

37

• Backups should include all data and meta data (audit trail), may also include the system

• Backups should be made frequently based on risk, e.g. hourly, daily, weekly and monthly

• Retention of backups should be based on risk, e.g. a day, a week, a month, forever

• Backups should not be stored on the same server as original data (logical separation)

• Backups should not be stored on the same location as original data (physical separation)

• Restore tests should be made when making changes to the system or backup process

• Restore tests should verify complete restore of system data and audit trail

• A disaster recovery plan should be in place for systems hosting critical data, especially where data is stored on only one data center without replication to another


Findings

(selected)

Finding related to System QualificationEdit Check

39

There was no or insufficient documentation for qualification of 5 out of 7 inspected systems

and interfaces.

For the eCRF system ███, there was a critical lack of system qualification of 12 out of 13

inspected requirements from the User Requirement Specification for ███ eCRF:

• URS 6.2.2: “The system must allow creating edit checks which fire when a user moves the cursor to another field (when leaving a field)”Test cases were presented, both from ███’s own user acceptance test (UAT) and from the SaaS provider ███’s qualification test, but none of the test cases verified the specified functionality, as they did not include the key element of a test user moving the cursor to another field.


Finding related to System QualificationEdit Check

40

• URS 6.2.6: “The system must allow a privileged user to define which edit checks fire during data entry, which fire during scheduled batch validations, and which edit checks fire on demand”The requirement was not tested and it was explained that the functionality was not implemented. However, the requirement had not been removed.


Finding related to System QualificationAudit Trail

41

• Requirement 8.9.7.1 from the eCRF system ███ 1.1.0:

Modified Forms display the following Audit Trail report:

- Field Name

- Old value (Blank for original entry)

- New value

- Modified Date/Time

- Modified By

- Reason

While some elements captured by the audit trail functionality (when and why) had been

covered by a test case, other important elements of the requirement were not qualified,

as the user (who) and the activity (what) could not be verified.


Finding related to Audit TrailAudit Trail not capturing changes after Edit Check notification (1/2)

42

During a demonstration of the eCRF system, it was seen that Edit Checks notifies the user of deviating inputs already when data has been entered into a field and you move on to the next input field, either by pressing Tab or by moving the cursor with the mouse. It was explained that data is not registered in the system and that the audit trail functionality will not capture any changes to the data before the user hits Save.

Yet, it means that until the Save button is hit, the user can make changes to the data, even after being warned by the system about a deviating input, e.g. an inclusion criteria not being met.

The functionality is considered a significant violation of data integrity, as it cannot be seen if and why data may have been corrected as a result of Edit Checks […].


Finding related to Audit Trail Audit Trail not capturing changes after Edit Check notification (2/2)

43

The audit trail functionality of the eCRF system was insufficient, as it did not capture changes made to data after edit checks or notifications that would have warned the user about a previous ‘deviating’ input.

A recent enhancement to solve this had been implemented in ███ (Change Control no. 20): The system now tracks eCRF data submission before the user confirms data. Any modifications at the data entry level is recorded.

However, it was understood during the inspection, that after receiving a notification, it would be possible ‘to bail’ out of the system, come back in and make a new input as suggested by a notification; and that the whole thing would not be captured by the audit trail.

It is expected that the audit trail functionality captures both initial data entries, changes and deletions and especially, that it captures changes to data made because of edit checks or notifications.


Finding related to Audit Trail Audit Trail not showing correct Timestamp (1/2)

44

For the ███ eCRF system, a serious deficiency with the audit trail functionality was observed, as timestamps, recorded by the audit trail were not (as expected) based on when an activity actually occurred, but rather when the eCRF page was opened.

For the same system, no password policy had been defined and there was no evidence that such policy even including an inactivity logout, had been enforced by the system during the conduct of the ███ study.

The implication of the above is that the system may have been open for a prolonged time and the difference between recorded and actual time of occurrences could easily have gone into hours or even days. This is regarded a critical lack of control and raises concern about data integrity.


Finding related to Audit Trail Audit Trail not showing correct Timestamp (2/2)

45

In lack of sufficient qualification of the eCRF system’s audit trail functionality, it was requested to see a demonstration of the functionality in a live test system. […].

All timestamps recorded by the audit trail functionality of the eCRF system ███ were incorrect, as the audit trail did not capture the actual time (and date) of the activities conducted, but instead, the time (and date) when the corresponding eCRF page was opened (i.e. the time recorded by the audit trail was before the activity actually occurred) […].

If the system for other reasons had been kept from going into screen lock, the difference could in principle amount to hours or days.

Audit trails are supposed to record events in true time and not recording the correct time is seen as a breach of data integrity (and ALCOA principles).


Finding related to IT SecuritySecurity Patching

46

Critical and major security patches had not been timely applied to data and application

production servers running Microsoft operating systems for any (100%) of the five inspected

systems and resources.

Microsoft recommends security patching on a monthly basis. However, out of the 15-20

applicable critical and major security patches released by the vendor for the platform of one

of the systems the last 18 months prior to the inspection, only one had been applied in less

than 60 days. The remaining patches for this system and for all other systems and resources

had only been applied after several months, some only after 207 days. For one of the

systems, it was even explained that there was a half yearly patching cycle.

Not applying applicable critical and major security patches in a timely manner as

recommended by the vendor of the platform, is a major risk to data confidentiality, integrity

and availability.


Finding related to IT SecurityPassword Policy

47

There was quite insufficient knowledge about and implementation of password policies for

the following 2 out of 4 systems, both of which had a substantial number of external users

and both of which were provided as software-as-a-service (SaaS) over the internet. Without

strong password policies implemented by systems, data confidentiality, integrity and

availability cannot be ensured:

• IRTFor the IRT system, in addition to normal password policy elements like a length of 8 characters and a complexity consisting of lower case, upper case, numeric and at least one special character, the system had other weak password policies including but not necessarily limited to a 180 days expiry (specific for trial ███), 30 minutes logout reset and it allowed the reuse of passwords.

• eCRFFor the ███ eCRF system, the password policy for normal users were not known and could not be presented during the 5-day inspection.


Thanks for your attention

For questions:Ib Alstrup, Medicines Inspector GxP IT, Danish Medicines [email protected], www.linkedin.com/in/ib-alstrup-baa2542

mailto:[email protected]

http://www.linkedin.com/in/ib-alstrup-baa2542

Documents

Computer Systems Validation and Data Integrity › wp-content › uploads › 2019 › 12 › DMB... · Requirements to qualification and operation of IT In different GxPs 10 Design,