Handwritten Signature:

A scripted name or legal mark created by an individual that is unique to that individual and is used to authenticate something in writing.

The act signing with writing or marking instrument is preserved.

The scripted name or legal mark, while conventionally applied to paper, may also be applied to other devices that capture the name or mark.

Digital Signature:

A type of electronic signature that includes a way of verifying the identity of the signer, the validity of their signature, and the integrity of the record they signed.

Digital Signature means an electronic signature based upon cryptographic methods of originator authentication, computed by using a set of rules and a set of parameters such that the identity of  the signer and the integrity of the data can be verified (21 CFR 11.3(5)).

Electronic Signature:

A set of symbols that is as unique and legally binding as a handwritten signature, but that is used to sign records in a computer system. Any time an electronic record is signed.

Following information must be visible and associated with the signature:

• Printed name of signer,

• Date and time of signature,

• Meaning of signature (e.g., content is accurate, format is correct, data calculations were verified) each person must have a unique electronic signature his/her identity must be verified.         

Where a paper or pdf copy of an electronically signed document is produced, the metadata associated with an electronic signature should be maintained with the associated document.

User IDs & Password:

For electronic signatures that make use of identification codes (i.e., user IDs) and pass codes/passwords, the following controls need to be in place

No two users can have the same combination of user ID and password – each combination must be unique.

Passwords must be checked, recalled, or changed from time to time. unauthorized attempts to access user IDs or passwords/pass codes must be detected and reported.

To Access full content we recommend you to download our Free “Data Integrity“ App which Contains most important Pharma IT Compliance tricks & techniques.

Data Integrity App for Complete pharma Compliance Reference

Electronic Signatures Components and Controls.

(a) Electronic signatures that are not based upon biometrics shall:

(1) Employ at least two distinct identification components such as an identification code and password.

(i) When an individual executes a series of signings during a single, continuous period of controlled system access, the first signing shall be executed using all electronic signature components; subsequent signings shall be executed using at least one electronic signature component that is only executable by, and designed to be used only by, the individual.

(ii) When an individual executes one or more signings not performed during a single, continuous period of controlled system access, each signing shall be executed using all of the electronic signature components.

(2) Be used only by their genuine owners; and

(3) Be administered and executed to ensure that attempted use of an individual’s electronic signature by anyone other than its genuine owner requires collaboration of two or more individuals.

(b) Electronic signatures based upon biometrics shall be designed to ensure that they cannot be used by anyone other than their genuine owners.

Electronic Signature & Handwritten Signature Linking.

Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means.

System Access and Security.

Any computer system that is used in a GMP environment must have a secure user log on and password to prevent unauthorized use

Requirements for Electronic Signatures (ES)

Electronic signatures following functionality will be included in the requirements specifications.

A. Electronic Signature Components

i. Electronic signatures must have at least two distinct identification components which together uniquely identify the authorized user. At least one of these components must be only known by, or accessible only to, the user & other is secure password.

B. Security and Controls

i. Signature manifestation information should be subject to all controls required for electronic records and should include the following information:

I. Printed name of signer.

II. Date and time signature was executed.

III. Meaning associated with signature.

C. Non-Biometric Identification

i. Unique User Identification

          1. Access to non-biometric electronic signature systems will be controlled using a unique user ID/password combination.

          2. To eliminate the necessity of tracking passwords as well as user IDs, and to ensure accurate understanding of who executed tasks in historical records. User ID must not be duplicated for any other user of the system, and must not be re-issued after the employee leaves the company or otherwise discontinues using the system. The use of domain based security system is preferable.

ii. Passwords

          I. Passwords are an important part of the security of computer systems that use them, and are therefore crucial to the control of electronic signature systems. Passwords for electronic signature systems are confidential. Under no circumstances is it permissible for a user of an electronic signature system to share or otherwise reveal his password. Violation of this principle is a serious breach of security.

          II. Passwords for electronic signature systems must be assigned an expiry period as per security policy on Passwords or as specified in the application specification document. Password complexity rules should be enforced as per Security Policy on Passwords Password re-use rules should be enforced as per security Policy on Passwords

iii. Unauthorized Access

1. Procedures must be developed and implemented to detect and prevent unauthorized use of electronic signature systems. This might include audit procedures designed to detect violations such as sharing among otherwise authorized users of user IDs, passwords.

Unauthorized access attempts must be reported in an urgent manner to the system security unit, and, as appropriate, to the business function owner.

FDA’s electronic records and electronic signatures rule offers companies the chance to take advantage of the efficiencies offered by electronic recordkeeping. The rule also presents its own challenges, and taking all the necessary steps to ensure compliance with the requirements will be demanding and expensive.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

• Current Regulatory Agencies thinking on Data Integrity.
• Importance of Mock Inspection & its tricks and techniques how to conduct.
• Checklist for Inspection
• Best Practices for CSV.
• Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

Background:

On March 20, 1997, FDA published a final rule on electronic records and signatures a document that will have a profound effect on device companies. This rule (21 CFR 11) establishes the criteria under which FDA will deem electronic records and electronic signatures equivalent to paper records and traditional handwritten signatures.

 If electronic signatures and associated electronic records meet the requirements of the regulation, FDA will consider these electronic signatures equivalent to handwritten signatures, initials, and other general signings, unless specifically exempted on or after August 20, 1997 (21 CFR 11.1(c)).

If data or records are stored electronically, you cannot avoid compliance with Part 11 by simply printing the data on paper and handwriting a signature.

If an electronic system is used to create, modify, maintain, archive, retrieve, or distribute data or records, those records and their related systems are required to comply with Part 11.

However, there are no regulations that require sites to use electronic records. It is totally acceptable for a site to use solely paper records and handwritten signatures, but it is not acceptable to use electronic records without the electronic signature component.

ERES regulations apply to:

•Source documents that are created in hardcopy and then entered into a computer system.

• Direct entry by a human into a computerized system.

• Automatic, computerized entry into a database, and

• The electronic signatures affixed to these electronic records.

To Access full content we recommend you to download our Free “Data Integrity“ App which Contains most important Pharma IT Compliance tricks & techniques.

Data Integrity App for Complete pharma Compliance Reference

What is Electronic Record:

Information in a digital form that is created or used in some way by a computer system.

Electronic Records means any combination of text, graphics, data, audio, pictorial or other information presentation in digital form that is created, modified, maintained, archived, retrieved, or distributed by a computer system.

Records generated using the software being assessed should be analyzed to classify the records into Electronic Records or Transient Data.

If the records generated using the software under assessment is classified as “Electronic Records”, then it should be complies with all the requirements.

If the records generated using the software in assessment is classified as “Transient Data”, then it would not be applicable to that data. But if the system has the capability of storing the data, then the data constitutes an electronic record, and cannot be considered transient data.

Requirements for Electronic Records (ER)

The following sets of requirements are recommended for inclusion in the User Requirements Specifications document(s) for computer systems intended to comply with requirements.

A  General Requirements:

i. System must have the ability to discern invalid or altered records.

ii. System must be able to generate accurate and complete copies of records in both printed hardcopy and electronic format suitable for inspection, review, and copying by the agency.

iii. Electronic records should be protected to enable accurate and expedient retrieval throughout   the required retention period.

B. Security of Electronic Records:

i. Security measures must be established which permit only authorized individuals to access electronic records. This includes restricting the ability to enter, move, edit; delete, or otherwise alter a record.

ii. The electronic audit trail must be protected from deletion or alteration of any kind

iii. Electronic records must be protected from unauthorized alteration or deletion, both intentional and inadvertent. It must be possible to discern invalid or altered records. Records must not be overwritten unless it is possible to accurately reproduce the old data as part of an independent audit trail.

iv. Authority checks should be used to ensure appropriate access levels (e.g. browse, update are implemented and should be logically linked to operator identification.

v. When identification codes and passwords are utilized as authority checks, the system should be designed such that:

A) Identification codes and passwords are will be periodically checked, recalled, or revised to prevent events such as password aging.

B) Transaction safeguard will be used to prevent, detect, and report in an immediate manner any attempts of unauthorized system access.

vi. Operational system checks should be used as appropriate to enforce the logical sequencing of steps and/or transactions.(Operational Checks should be based on system functionality and should be specifically documented in the appropriate functional requirement section of the requirement specifications.)

vii. It is recommended to have only limited number of users with system administrator privileges.

C. Audit Trail Requirements

i. Audit trail records must be automatically generated at the time of the transaction documenting all activities which create, modify, or delete electronic records.

ii. All data fields, including meta-data, should be audit trailed. Documented justification/explanation should be provided as part of the requirement specifications for any data fields (including meta-data).

iii. Systems that make use of stored electronic records must include a secure, time-stamped, computer-generated audit trail, which accurately and independently tracks operator actions and subsequent changes to the data. The point at which the audit trail is activated should be defined based upon the nature of the system. In cases where the trail is not activated immediately at raw data entry, documented justification must be provided.

The minimum requirement for the audit trail includes the following:

I. The identity of the person making the change.

II. The time and date that the change was effected.

III. The action that creates modifies and / or deletes a record.

IV. The reason for modification to a record

V. The change may not delete or obscure the previous data. It must be possible to obtain the record as it existed prior to modification, and it must be possible to ascertain the value for the record at any given point in time following the initial data entry.

Vi. The audit trail must be maintained as long as the data is retained Migration of subject record(s) to a new database must include migration of associated audit trail records.

vii. Audit trail records must be accessible (read-only) in a manner that allows logical searches and reconstruction of database transactions. In order to fully reconstruct all transactions, tabula relationships may need to be maintained in audit trail records for relational databases.

D. Electronic Record Retention

l, Electronic records, including corresponding audit trails are to be retained as long as Electronic data is required to be retained.

ii. During the retention period, records must be readily accessible for inspection

E. Inspection of Electronic Records

i. It must be possible to generate accurate and complete copies of electronic records at the request of regulatory or internal auditors in a form suitable for inspection, review, and copying the records must be available in both human-readable and electronic form. Electronic copies do not have to be in the original format as long as all data is intact and human readable. If a decision is made for business reasons not to maintain electronic records on-line, provisions must be made to ensure that true and accurate copies, whether electronic or paper, are obtainable within a reasonable time period for a regulatory inspection.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

• Current Regulatory Agencies thinking on Data Integrity.
• Importance of Mock Inspection & its tricks and techniques how to conduct.
• Checklist for Inspection
• Best Practices for CSV.
• Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

Data Transfer / Migration:

Data is one of the most important assets that a company owns. Data is collected and analyzed to create information for decision making. Data influences patient safety or product quality in Life Sciences

Data migration performed for many reasons: like mergers & acquisitions (many sources to many targets), new business models or processes, to keep pace with technical progress or consolidating applications, replacement for the old legacy system. Almost all migrations involve data transformations to get the data from one model to another model.

Data migration implementation will always create accurate and complete copies of the records when they are moved to a new system.

Data transfer is the process of transferring data between different data storage types, formats, or computerized systems.  

Data Migration performed in three basic options:

1. Manual Migration: Re-enter all case data from the source system into the target
2. Automated Migration: Use a third party tool to Extract the data from the source, Transform it into the proper format for the target, and Load it into the target system.
3. Mixed Method migration techniques: Use a combination of manual and automated system.

In general, manual migrations tend to introduce human clerical errors not typically seen in ETL efforts. This could be seen as lowering the Quality aspect of the iron triangle.  However, there could be distinct cost and time savings since an ETL tool license wouldn’t be purchased (cost saved) nor configured (time/cost saved).

In automated efforts, the quality of the transfer is arguably higher since often a 100% data mapping effort is performed between the source and target system thus allowing all data to transfer. This increase in quality is often worth the increased cost and time associated with the use of an ETL tool.

Finally, the mixed method migration technique is something that might be especially unique to the safety world

Challenges and Risks Associated with Safety Data Migration

The challenges or issues, which sometimes may lead to migration failure, may depend on some of the following parameters:

• Inappropriate data migration planning
• Lack of system knowledge or functions
• Wrong interpretation of business rules or logic applied in the safety database architecture
• Improper data structure designing
• Technical aspects related to field character limits and type, which vary from system to system
• Inconsistent or inaccurate data availability
• Data mapping across both the systems
• Handling of duplicate or follow up records
• Lack of standardization across systems and processes
• Handling of the source documents and other related documents
• Iterative data cleaning process
• Inadequate data checking and validation – randomization of data check and the validation approach that needs to be adapted, prior to production
• Reconciliation of entire migration activity

Post-Data Migration Testing

Once a migration has been executed, additional end to end testing can be executed.

Expect a significant sum of errors to be identified during the initial test runs although it will be minimized if sufficient pre-migration testing is well executed. Post-migration is typically performed in a test environment and includes:

• Test the throughput of the migration process (number of records per unit time). This testing will be used to verify that the planned downtime is sufficient. For planning purposes, consider the time to verify that the migration process was completed successfully.
• Compare Migrated Records to Records Generated by the Destination System – Ensure that migrated records are complete and of the appropriate context.
• Summary Verification – There are several techniques that provide summary information including record counts and check sums. Here, the number of records migrated is compiled from the destination system and then compared to the number of records migrated. This approach provides only summary information and if any issue exists, it does not often provide insight to an issue’s root cause.
• Compare Migrated Records to Sources – Tests should verify that fields’ values are migrated as per the migration specification. In short, source values and the field level mappings are used to calculate the expected results at the destination.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

• Current Regulatory Agencies thinking on Data Integrity.
• Importance of Mock Inspection & its tricks and techniques how to conduct.
• Checklist for Inspection
• Best Practices for CSV.
• Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz

Data Integrity:

“The extent to which all data are complete, consistent and accurate throughout the data lifecycle all its forms, i.e. paper and electronic.”

Data integrity arrangements must ensure that the accuracy, completeness, content and meaning of data is retained throughout the data lifecycle.

It can describe the state of data E.g. data valid or invalid or the process of ensuring and preserving the validity and accuracy of data, Error checking and validation.

Systems and processes should be designed in a way that facilitates compliance with the principles of data integrity.

Data integrity is the degree to which data are complete, consistent, accurate, trustworthy, reliable and that these characteristics of the data are maintained throughout the data life cycle.

The data should be collected and maintained in a secure manner, so that they are attributable, legible, contemporaneously recorded, original (or a true copy) and accurate.

Assuring data integrity requires appropriate quality and risk management systems, including adherence to sound scientific principles and good documentation practices

The Principles of Data Integrity 

1 The organization needs to take responsibility for the systems used and the data they generate. The organizational culture should ensure data is complete, consistent and accurate in all its forms, i.e. paper and electronic.  

2 Arrangements within an organization with respect to people, systems and facilities should be designed, operated and, where appropriate, adapted to support a suitable working environment, i.e. creating the right environment to enable data integrity controls to be effective. 

3  The impact of organizational culture, the behavior driven by performance indicators, objectives and senior management behavior on the success of data governance measures should not be underestimated. The data governance policy (or equivalent) should be endorsed at the highest levels of the organization. 

4  Organizations are expected to implement, design and operate a documented system that provides an acceptable state of control based on the data integrity risk with supporting rationale. An example of a suitable approach is to perform a data integrity risk assessment (DIRA) where the processes that produce data or where data is obtained are mapped out and each of the formats and their controls are identified and the data criticality and inherent risks documented.  

5 Organizations are not expected to implement a forensic approach to data checking on a routine basis. Systems should maintain appropriate levels of control whilst wider data governance measures should ensure that periodic audits can detect opportunities for data integrity failures within the organization’s systems. 

6  The effort and resource applied to assure the integrity of the data should be commensurate with the risk and impact of a data integrity failure to the patient or environment.  Collectively these arrangements fulfill the concept of data governance.  

7  Organizations should be aware that reverting from automated or computerized systems to paper-based manual systems or vice-versa will not in itself remove the need for appropriate data integrity controls.  

8  Where data integrity weaknesses are identified, companies should ensure that appropriate corrective and preventive actions are implemented across all relevant activities and systems and not in isolation.  

9  Appropriate notification to regulatory authorities should be made where significant data integrity incidents have been identified.  

10 The guidance refers to the acronym ALCOA rather than ‘ALCOA +’.

ALCOA being Attributable, Legible, Contemporaneous, Original, and Accurate and the ‘+’ referring to Complete, Consistent, Enduring, and Available.

ALCOA was historically regarded as defining the attributes of data quality that are suitable for regulatory purposes.

The ‘+’ has been subsequently added to emphasize the requirements. There is no difference in expectations regardless of which acronym is used since data governance measures should ensure that data is complete, consistent, enduring and available throughout the data lifecycle.  

Source: MHRA GXP Data Integrity Guidance and Definitions; Revision 1: March 2018.

Across the internet, there are millions of resources are available provide information about almost everything.

Here all useful Pharma IT Compliance & Inspection preparation information is available in your hands for your ready reference.

We recommended you this “Data Integrity” App which contains most important Pharma IT Compliance tricks & techniques which help you to understand

• Current Regulatory Agencies thinking on Data Integrity.
• Importance of Mock Inspection & its tricks and techniques how to conduct.
• Checklist for Inspection
• Best Practices for CSV.
• Useful Resources & References

So, let’s try this Free “Data Integrity” app & stay updated in world of Pharma IT compliance.

Team Innovative Appz