Krav til IT Systemer og Validering

Krav til IT Systemer og ValideringDansk Selskab for GCP, 12 september 2018, København

Data Integrity

Ib Alstrup, Medicines Inspector GxP IT, Danish Medicines Agency

Data Integrity, why it is Important

2

ALCOA+

Attributable

Legible

Contemporaneous

Original

Accurate

Complete

Consistent

Enduring

Available

It’s all about whether we can we trust the data

Who performed an action and when, link to source data?

Is data is readable and recorded permanently, cannot be deleted?

Is data recorded at the time the work is performed?

Is it the first recording of data or a “true” copy preserving its meaning?

Is it free from errors and has any editing been documented?

Does it contain all data including any repeat or reanalysis data?

Is it according to good documentation practice?

Is it recorded on controlled worksheets or electronic systems?

Is it available/accessible for review throught the lifetime of the record?

:

:

:

:

:

:

:

:

:

IB ALSTRUP, MEDICINES INSPECTOR, GXP IT

Ex: Batch Record

3

Three representations


4 IB ALSTRUP, MEDICINES INSPECTOR, GXP IT

A good old

paper record

(incl. GxP

corrections)

Ex: Batch Record


A print from a dedicated and (supposedly) validated computer system

Ex: Batch Record


A print from

another

computer

system

Ex: Batch Record

7

Which one do you prefer?


Ex: Batch Record


Ex: Batch Record

Why should we accept

the electronic version?


Ex: Batch Record

Accepting electronic documentation without

verifying the validation of key functionality,

e.g. audit trail, is like accepting GxP

documentation written

by a pencil

You don’t know what was there before

Guidance on data integrity


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


What ICH GCP says about IT Systems


Requirements to validation and operation of ITLarge difference in detail between the GxPs

2

• Requirements to design, validation and operation of IT systems is described in very different depths ranging from GLP (20+ pages) to GCP (<1 page + EMA reflection paper )

• With a very few exemptions, there is no objective reason why our expectations should be different across the GxPs

• The more detail we find in regulatory requirements, the less we have to interpret

• The opposite is also true


ICH GCP E6 R2 5.5.3

3

ALCOA+

”Data Integrity”


4

1. GLOSSARY

ADDENDUM

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.


Validation should prove that URS

requirements are fulfilled

Validation based on URS

ICH CGP E6 R2about Computer Systems Validation


5

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 intendedperformance (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 reliabilityof trial results.


Validation according to URS

Sponsor should create (or adopt)

URS

Validation based on risk assessment

Risk assessment should include URS

6


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.


Should have SOP on

System systems validation and testing

etc.


7


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).


To (only) permit changes in this way

New and all previous values

Who did what, when and why

Audit trail review (in Reflection Paper)

ICH CGP E6 R2about Audit Trail functionality

8


the sponsor should:

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


Access control,

Authentication methods,

Firewall management,

Platform management,

Security patching,

Security incidents,

Penetration testing,

Virus protection,

Intrusion detection,

Use of USB devices,

Physical security

ICH CGP E6 R2about Security and Access

9


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,

Authentication methods (incl. remote

Authentication),

Password management

ICH CGP E6 R2about Authorization

ICH CGP E6 R2about Backup and Restore

10


the sponsor should:

(f) Maintain adequatebackup of the data.


Backup procedures,

Restore procedures,

Archival procedures,

Media rotation procedures,

Redundancy,

Physical separation

ICH CGP E6 R2about Blinding (Access)

11


the sponsor should:

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

processing).


Specification and corresponding

qualification of related functionality

(e.g. encryption)

Access control

Access review

Authentication procedures

ICH CGP E6 R2about Data Intergity

12


the sponsor should:

ADDENDUM

(g) 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 operation

(plus all of the above)






Technical and Procedural Controls to ensure Data Integrity


Technical and Procedural Controls

2

• Assurance of Data Integrity in electronic systems is tightly connected to technical and procedural controls associated with the systems

• Like all other functionalities, the technical controls need to be validated by the regulated company

• The procedural controls (SOPs) need to be trained and above all, executed, by the regulated company

• Both will be verified during inspections – we cannot take them for granted


Risk ManagementExpectations

3

• Risks in relation to ensuring data integrity are continuously identified and analysed

• Significant risks are effectively mitigated and brought down to an acceptable level

• Mitigating actions are monitored for continued effectiveness

• Work (incl. brain storm) should involve a cross functional group

• Should follow a described process


Risk ManagementExample: FMEA


Risk ManagementDeviations

5

“There was no procedure for management of risks of using computerised systems and there was no evidence that risks, including those related to accidental or deliberate loss of data integrity, had been identified, analysed or mitigated for any of the 7 systems inspected.”

”The ███ system had recently been expanded with a number of new interfaces to other systems and instruments, including some which were designed in-house, but it could not be documented that risks associated with transfer of data (i.e. data integrity) had been had been considered.”


Access ControlExpectations

6

• Systems should restrict logical access to authorised individuals

• Physical access to servers and 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


Access ControlPhysical access

7

• Physical access to servers and media should be restricted for normal users


Access ControlUser reviews - typical mistakes

8

Should verify that all current users should continue to have their current access (role)

• Not that users who once have been given access still have access

Reviews should be conducted by the user’s manager or someone responsible

• Not by the user himself or by a system manager who doesn’t know the user

Should include users on all access levels, incl. privileged users

• Not only normal users


9

• All accesses should be personal (attributable)

• No shared accounts should be allowed

• Accounts should be unique


Ex: Access ControlSee any challenges?

Access ControlDeviations

10

“The list of users on the ███ for pharmacovigilance and clinical safety case management included many non-personal and presumably shared accounts. Shared accounts are a direct contradiction to data integrity.”

“It was not verified, that the “read only” setting in the configuration file did not give access to write or change data.”

“The procedure for user reviews, ███, was insufficient in that it only described a review of users who had left the company. It failed to include a review that everyone with access to the system had the correct privileges.

Without effective reviews of user accesses it cannot be ensured that accesses are limited according to the to the least-privilege rule and data integrity may therefore be jeopardized.”


Access ControlDeviations

11

“There was insufficient documentation of periodic reviews and review of user accesses to the ███.”

“It was explained that employees had administrative rights to PCs, whereby they could install programs and modify data.”

“For ███ [an automated haematology analyser], it was explained that there was a group account with admin rights with a password that everybody knew.”

”There was no procedure or practice for periodic review of users.”


AuthenticationExpectations

12

• Authentication method should positively identify users (just a smart card is not sufficient)

• Organisations should have strong password rules (e.g. complexity, expiry, attempts, reset)

• Systems should include password rule enforcement

• Confidentiality of passwords should be maintained, sharing of passwords prohibited

• Systems should enforce users to change password upon having been granted access

• For remote authentication to systems containing critical data available via the internet (e.g. cloud solutions); strong authentication should be employed, requiring at least 2 of the following 3 factors:

– Something you know (e.g. user ID and password)

– Something you have (e.g. token or pass card)

– Something you are (biometrics)


AuthenticationDeviations

13

“Clinical research subjects [who are to enter GCP data in a system], login on tablets only by means of their CPR number [a social security number], without any further authentication.

As the CPR number is known and used by and is widely accessible to health care professionals, the authentication process was not sufficiently strong and it could not be proven that data could be attributed to the subjects. Data integrity was therefore not adequately ensured.”

”When a password expired, it was possible to chose the old password and the ███ admin had access to all passwords [in clear text].”

”According to SOP ███, the number of unsuccessful login attempts was set to 3, but in reality, it was seen that the system would allow an indefinite number of attempts.”


Audit TrailsExpectations

14

• Recording who, what, when and why for manual entries, changes and deletions

• New and all previous values must be available

• Audit trail recorded in true time, not only at the end of a long process

• Audit trail non-deactivatable, at least for normal users, de-activation 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


Ex: Qualification of Audit Trail Functionality

15

Should include

• Who did what, when and if not obvious, why

• New and all previous values

• Not just that something has been recorded in the audit trail

• It should be possible to verify the recorded data from the preceding test steps

• Any screen shot must bereadable


Audit TrailsDeviations

16

“There was no audit trail functionality for 6 out of 6 inspected GMP critical IT systems for control of, or acquisition, analysis and reporting of data from various analytical equipment and chromatographic technologies used by the ███ QC laboratory, ███.

Further, the practice of printing data to paper did not support the necessary documentation and approval of changes, e.g. of re-analyses and manual integrations. Prints from several of the systems did not contain information about who had made which changes, when and why.

Hence, data integrity had been compromised (EU GMP Annex 11.9, 11.12.4).”



17

“There was no or insufficient procedures for audit trail reviews for each of the 7 inspected IT systems and there was no evidence that any such reviews had been conducted. For several of the systems, an audit trail functionality had not been implemented, activated or qualified, see Deviation █.

A qualified audit trail functionality and an effective review of recorded data according to a system specific procedure is essential for ensuring data integrity in electronic systems.”

”There was no procedure for audit trail reiviews and no documentation that such reviews had been conducted for the ███ system. Instead, it was explained that the provider of the system which was provided as Software as a Service (SaaS), conducted reviews of an access log. However, this is quite insufficient and cannot replace a proper audit trail review.”



18

For the ███ system, there was no user requirements specification and no related system qualification. With regards to regulatory requirements, there was no evidence of qualification of 2 out of 2 inspected requirements from OECD Guidance 17:

• OECD 17.80 (Audit trail)“[...] Any change to electronic records must not obscure the original entry and be time and date stamped and traceable to the person who made the change.”Der was no qualification of the audit trail functionality

• OECD 17.81 (Change of audit trail settings)“[...] The ability to make modifications to the audit trail settings should be restricted to authorised personnel. Any personnel involved in a study (e.g. study directors, heads of analytical departments, analysts, etc.) should not be authorised to change audit trail settings”. The requirement had not been tested and the system did not have any audit trail functionality



19

“The ███ suite had been qualified by the provider in the Pre-Validation Package, which had been shared with ███. […] [However], the test case addressing the following requirement had not been sufficiently documented, as the test evidence (screen shot) documenting that certain activities had been captured by the audit trail, was unreadable (scanned in too low resolution):

• Requirement RR_ESM_CFR_ER_02:Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify and delete electronic records [11.10(e)”

“The audit trail does not show original data entry, only subsequent changes made. Audit sequence number starts with 2”


Electronic SignaturesExpectations

20

• The must be an unbreakable link between the signature and its respective record

• At least same expectations to passwords and as for authentication

• Execution should create audit trail entry, as all other changes


Electronic SignaturesUnbreakable link

21

• Any change to an already signed document must render the document un-signed

or

• It must not be possible to change an already signed document (version)


Electronic SignaturesDeviations

22

“It had not been validated that a record already approved by one user in the LIMS system could not later be changed by another user, without rendering the record unapproved.

In fact, a test was made during inspection showing that this was indeed possible and that a previous approval would still seem to cover the changed record.”


Time SettingsExpectations

23

• System clock and time zone non-editable for normal users

• System clock synchronized with connected systems or standards


Inactivity LogoutExpectations

24

• 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


Platform Management and Security PatchingExpectations

25

• 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


Ex: Security Patching

26

WannaCry

• Preyed only on un-supported and un-patched systems

• Spread with user interaction (just one user clicking on link)

• Encrypted data and left them inaccessible

• Microsoft had released securitypatch 8 weeks before attacks

• So, patching must be very timely..!


Virus ProtectionExpectations

27

• An effective virus shield is kept updated and activated at all times


Virus ProtectionDeviations

28

“The virus shield was found to be de-activated during day-time, in order to improve performance”

“There was no evidence that the virus protection was kept updated, i.e. it had not been updated for more than six weeks”


USB Devices (Windows Environment)Expectations

29

• It should be prohibited to use private USB devices on company computers and vice versa

• USB ports should be default de-activated on most critical equipment, e.g. un-patched PCs


Backup, Restore and Disaster RecoveryExpectations

30

• Backups should be made regularly and should include system, data and meta data

• The backup process and frequency of backups should be based on a risk assessment

• For critical data, the storage of backup media storage should include off-site location

• Restore tests should be conducted regularly, or when changes have been made to the backup process

• Restore tests should demonstrate a complete restore of the system, including its data and meta-data

• 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


Backup, Restore and Disaster RecoveryDeviations

31

“It could not be documented that a restore test had ever been conducted using backup media”

“There was no documentation that testing of restore of systems and their data had been conducted for 6 out of 7 inspected IT systems (OECD 17.77d). Without and effective backup and restore process, the data integrity cannot be ensured and it cannot be documented that systems and data can be restored in case of a break-down.”


Management of FirewallsExpectations

32

• 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


Management of FirewallsDeviations

33

“It could not be documented why the specific ports ███, ███ and ███ in the firewall were found to be open. Apearantly, they had been opened due to the request of a service technician more than 2 years before, but no one had remembered to close them again.

Further, there was no procedure for recurrent reviews of firewall settings and there was noevidence that such reviews had been conducted.

Without recurrent reviews of firewall settings against approved firewall rules, it is possible that unsafe ports may accidentally be left open and data integrity may consequently be at risk.”


Guidance on Data Integrity






Documents

Krav til IT Systemer og Validering