Manual – 074 Electronic Records and Electronic Signatures

This guideline is directly applicable to any function, department, or site that operates to US FDA GLP, GCP and/or GMP standards, or that generates records or data that are submitted electronically to FDA. It will be useful in meeting the expectations of other regulatory authorities worldwide and so further references to GLP, GCP and GMP are not explicitly restricted to the FDA.

2.1 General

This guideline applies to any computerised system that creates, modifies, maintains, archives, retrieves or transmits records required by the predicate rules of GLP, GCP, GMP or submitted records, electronically in whole or in part in place of paper records. It does not currently apply to systems that were in operation before 20 August 1997 and met the requirements of the predicate rules, provided those systems continue to satisfy the predicate rules despite changes made to their architecture or functionality. It also does not apply to systems which have their records transferred to paper for all regulated purposes. It is applicable to any computerised system that uses electronic signatures in place of hand- written signatures but only for purposes of compliance with GLP, GCP, GMP or regulatory submission requirements.

2.2 Faxes

An ordinary fax is outside the scope unless it is generated or received by a computerised system which falls within the general scope.

2.3 Documents

Some documents which are principally text and do not contain ‘live’ data, such as SOPs, validation documentation, computer system documentation, laboratory test methods, deviation reports, etc. may be created using proprietary software, but used only on paper. In this situation the electronic version is not within the scope of ER/ES if the original electronic document is used only by the author for the sole purpose of creating a paper copy and only the paper copy is made available for general use. If the documents are required by predicate rules and are signed, maintained, distributed or otherwise made available electronically, ie the electronic version is used for regulated purposes, then they become electronic records within the scope of ER/ES. Note that the risks associated with their use, particularly if ‘read-only’, should be considered in defining the approach to take. A validated document management system is nonetheless the preferred way to achieve a compliant state for these documents (see Section 5.4.1).

2.4 Transient Data

Transient Data (see Section 3.2.3) is not generally in the scope of ER/ES if a printout is produced which meets predicate rule requirements and is used for all subsequent regulated purposes. Most data of this type is generated from small data capture systems, for example scales, tablet weighing systems, and lab equipment such as titrators or stand-alone integrators. Alternatively the data may be transmitted directly to another system, such as a Distributed Control System (DCS), Supervisory Control and Data Acquisition (SCADA) or other storage device, then this receiving system will need to comply assuming the data is maintained electronically and used for regulated purposes. The ‘system’ should be considered to include the components creating the data and its transfer to the storage device and the whole should be validated.

5.2.3 Audit Trails 

Any requirement for an audit trail will be defined by the relevant predicate rule but also by the need to be able to assure the trustworthiness and reliability of a record. The latter will vary according to the potential for impact on patient safety/product quality and a decision on the course to be taken should be justified and documented in a risk assessment. Note that the course of action can include physical and procedural measures ie. manually created and maintained logs, as well as logical security measures, again depending on the level of risk involved. Particular consideration should be given when users have to create, modify or delete regulated records during normal operation. System level logs (and similar) are generated for most systems. These are activity logs typically at the operating system level that track activities such as logons/logoffs, changes to security settings, system shutdown/startup, and the like. This is different from the electronic record audit trail, which is generated at the application level and logs users actions performed to a specific electronic record. The low level of inherent risk in these system logs suggests that although they need to be maintained and kept according to a retention schedule it is unlikely that ER/ES controls are required. Systems which hold critical (or high severity of impact) electronic records, such as batch records, laboratory records, certificates of analysis or clinical patient data, should have a date and time-stamped, computer generated audit trail that ensures that changes to previously recorded values are not obscured. Electronic records should typically be audit-trailed throughout their life cycle, although depending upon the record’s life cycle phases, audit-trailing may begin at some point after initial creation (e.g. when moved from “draft” status) although if this is the case it should be defined in the system documentation. Systems should also have the ability to record the reason for change directly into the system if required by the relevant regulation or guideline (GXP). Where an electronic audit trail is considered necessary the following provisions apply. User transaction logging including create, modify and delete as a minimum, should be built in at the application software level to provide an audit trail. Testing during validation should confirm that the audit trail functionality has been implemented properly and that audit trails can be maintained and reviewed as required. It must not be possible to change the audit trail after creation. Ideally, the audit trail is written in a binary format by the application and access is controlled using application functionality and security. If the audit trail is stored in an easily editable format such as ASCII or Word, then it should automatically and immediately be written to a protected location such as a secure location on a server. Deletions should only occur under controlled circumstances by personnel with adequate security when the underlying data has reached its destruction date, according to record retention schedules. The audit trail should be automatically generated by the computer and be date and time stamped. It is acceptable to record time either as local time or as a reference time zone such as GMT, as long as it is unambiguous in the context of the application. Recording time to the nearest minute may be acceptable although to the second is more conventional. The audit trail includes information on records that were newly created, or deleted, including who added/deleted them and when. A unique user ID is acceptable as identification in an audit trail. Audit trails for modified records should include, in addition, the new and previous values. In some cases, the reason for change should be included in the audit trail, but this will depend on the relevant GMP, GLP, or GCP requirements. It should be apparent from viewing an electronic record that a change has been made. The retention period for the audit trail should directly parallel that for the underlying records. The retention time will not be dictated by ER/ES requirements, but by GMP, GLP, or GCP. This should be documented in the records retention schedules. Audit trail records should be readily accessible during a regulatory authority inspection. The process for doing this should be well known and documented. It may be necessary to provide a paper copy but an electronic copy of the audit trail on a durable medium such as CD-R may be offered to the inspector to take away. In this case the format of the data may vary, but it must be readable using readily available software such as Word, Acrobat, or Excel. The process for creating such an electronic copy should be documented.

5.2.4 Validation 

All GXP regulated systems particularly those including electronic records and/or signatures must be validated according to their potential impact on patient safety, product quality or record integrity. Computer systems determined to have regulatory impact will be developed/acquired, validated, and maintained following a structured approach. The validation activities ensure accuracy, reliability, and consistent intended performance of the system.

5.2.5 Presentation and Copying of Records 

Where electronic records are kept in place of paper, the ability to present the record in a human readable form is required with the content and meaning (data and metadata) of the original preserved. Ideally the system should have the ability to produce a printout that contains an accurate and complete representation of the original electronic record (including audit trail and metadata). Nonetheless it should be possible to generate an electronic copy in a common format (e.g. PDF, XML, SGML) and with the records content and meaning preserved for review by regulatory authorities. Basic manipulation of the copy i.e. search, sort or trend analysis should be possible with the copy where the original allows this.

5.2.6 Retention and Archiving

Just as paper records must be retained and archived for defined periods, electronic records, together with their metadata, should be available for the time period specified in the retention schedule for the specific record. In addition to the record itself, any associated audit trail information should be stored for the same time period, since the audit trail contains the details behind any changes that may have been made to the record. It is also acceptable to transfer electronic records to paper or other traditional medium provided that the content and meaning (i.e. data and metadata) of the records are preserved. The decision on how to retain or archive records should consider the risks associated with the potential loss of the record and the changing value of the record over time. Where a record is to be archived electronically there should be procedures in place for regular back-ups and refreshing/transferring of media as necessary. A regularly tested disaster recovery plan would be expected as added assurance that the data is protected over its lifetime. There will be situations where computerised systems are replaced by newer ones, even if only hardware or software upgrades. When this occurs it is desirable for the data from the old system to be compatible with processing by the new system. If this is not feasible, then a properly documented and validated migration of data into the new system is acceptable if it can be shown that the new record is an accurate and complete copy of the original. Relevant audit trail data should be included in the migration process. Another option, particularly where the system has become obsolete from a hardware/software architecture standpoint and will not be replaced by a newer system, may be to transfer the complete electronic records (including metadata and audit trail) to a more generic format for retention and restoration (e.g. PDF/XML/SGML).

5.2.7 Security

If records are maintained electronically, there should be assurance that only authorised people can access the systems and authority checks should be built-in such that individuals can only perform functions within the system for which they have authorisation. Controls should include the following:

* Appropriate system and procedural controls over user IDs and passwords in order to protect against unauthorised access to system records, operations, or input/output devices.

* Procedures to clearly indicate the groups of users who may use the system, electronically sign a record, alter a record or perform other tasks related to the system.

* Technical architecture that includes safeguards against and facilitates the detection/monitoring of, unauthorised system use.

* Procedures for system administration that address access privilege granting/retracting and the periodic review of authorisations. System- specific SOPs or Operations Manuals should address the administration of internal security hierarchies within the system.

* Group access only available for read-only accounts. System administrators routinely require privileges above and beyond those that are granted to users. Although it is recognised that the capability to intervene at any level in a system is likely to exist, those with this capability must be limited in number and identified, with documented evidence of their competence made available. In addition, evidence of change control of system and records together with an audit trail, system generated where feasible, should be kept. Access should be through an account that can be associated with an individual. The use of generic, highly privileged accounts, such as “sysmgr” should be avoided wherever possible. Actions done under such an account must be well documented and justified. can only perform functions within the system for which they have authorisation. Controls should include the following:

5.2.8 Personnel Qualifications 

Any staff who use, develop, or maintain a computerised system which includes electronic records or signatures should have adequate education, training, and experience to perform their job. Documentation of suitability for a role is considered a GXP activity and any electronic records of such, if maintained electronically, should comply with the principles of ER/ES requirements, although in this context the risk associated with the records is considered low.

5.2.9 Open and Closed Systems 

Open systems by their nature have greater security challenges than closed systems, and therefore require more stringent controls in order to comply with the regulation. Careful consideration should be given to the implications before implementing an open system. Transmission of proprietary or classified data over an open system (such as those that employ Internet communications) without additional controls such as encryption and digital signature is not an acceptable practice. Dial-in access from a remote location does not change the nature of a system from closed to open as long as there are additional controls in place such as access tokens, dial-back authentication, dedicated modems, or other methods of assurance of authenticity. Many systems are used on a multi-departmental and even multi-site basis. As long as persons responsible for the data/records (ie Site and its contracted partners) control access to the system, the system can be considered closed. Where named individual consultants, contractors, and partners are retained to provide services under contract they can be considered to be part of the access-controlled group of people who are responsible for the content of the system and the system remains closed. Of course, there may be other characteristics of the system architecture that cause it to be defined as open (e.g. use of public domains for data transmission/storage, etc).

5.2.10 Hybrid Systems 

In some cases, a copy of an electronic record may be printed and used for further data capture and/or signed using wet ink whilst the electronic version continues to be used for regulated activities as well. Systems such as these are considered hybrid, and can be problematic unless the electronic record and the hand-written data/signature are linked together in a completely unambiguous manner. Measures to be adopted for these systems should include validation of the system, retention of the electronic record, appropriate audit trail capabilities, and security measures and procedural controls to ensure signature-record linking. This linking can be accomplished, for example, by including specific document or file name references on the signed printout. It is up to the operational organisation to prove that the link between the electronic record and the paper version, with any hand-written signature, is maintained and that the electronic record cannot be changed without its being reflected in the paper version or vice versa. There may be instances where the operator writes down values from the screen onto a paper record (e.g. batch records) and at the same time the system logs those values to an electronic record. This is not strictly a hybrid system because it doesn’t produce both electronic and paper records. However, even if the system is not a hybrid the regulatory authorities may inspect the electronic record if it continues to be used for regulatory activities. For instance, if a process control system is used to control and log data, and the operators write the data by hand into a batch record, the logged data could be considered as the raw data if it was subsequently used for investigations, trend analysis or evidence for process revision for example, and would be an inspectable record.

5.3 Electronic Signatures

5.3.1 General

Where electronic records are used and a signature is required by regulation it is desirable to use an electronic signature. The use of an electronic signature that is linked to the electronic record and cannot be cut from or pasted to the record gives added assurance to the integrity of the record. Electronic signatures may acceptably be used wherever there is a requirement for a signature, initials, or a more general requirement such as approval or review. The original signatures on signed records should not be able to be overwritten in any case. Any requirement to sign a record is defined in the applicable GXP regulation, not in Part 11. The predicate rule may require a ‘full handwritten signature’, a ‘signature’, or ‘initials’. In addition, there are numerous sections of the regulations that imply that signatures are required. Some examples are: The GMP requirement that SOPs are approved by the Quality Control Unit The GLP requirement that the Study Director approves study plans These implied signature requirements are called “general signings” and their requirements are exactly the same as for any other electronic signature. GLP regulation 21 CFR Part 58 130 (e) states: “In automated data collection systems, the individual responsible for direct data input shall be identified at the time of data input”. This does not necessarily fall into the category of a “general signing”. However you must be able to demonstrate adequate system controls to prove that the person “identified…” was indeed the person who entered the data. This precludes a group log-on, and implies controls such as time-outs that ensure that people cannot enter data into a computer unless they themselves have logged on. In other words similar controls must be adopted for the “identifier” as those that are required for an electronic signature. The only difference is the act of signing itself. An electronic signature can achieve compliance in this instance and with other sections in GLP calling for signatures that must be compliant, the same approach is recommended in each situation. This is in contrast to the identifier within an audit trail (see Section 5.2.3) It is not unusual for a record or document to require more than one signature. The record/document ownership is unaffected by the number or identity of the signatories and should remain in line with the local system/data/document ownership policies/definitions.

5.3.2 Types of Signatures 

Biometric electronic signatures can be executed using a device such as an iris scan, fingerprint detector, or similar. These devices are less prone to be compromised (but not easily replaced if they are) than processes using identifiers such as passwords, so controls for this type of electronic signature are less strict than for non-biometric electronic signatures. Biometric devices should be adequately validated, as would be expected for any other piece of equipment used for GCP, GLP or GMP. Sufficient data for the device or software must be available from the vendor and within the site to demonstrate the suitability of the device for its intended purpose. Hand-written signatures may be captured electronically and executed to electronic records through the use of a stylus or similar device, in which case the image of the signature is saved either as part of a document or linked to a document.. It is also possible to sign a paper document and later scan the signed copy into a computer system. In most cases, it is necessary to link this signed page with a larger document that is also stored electronically. In either case there should be linkage between the signature and document, and system controls should be such that the signature cannot be cut or copied from the record or pasted into the record. There should also be controls to either prevent a signed document from being changed after signing or to clearly indicate that the document has been changed. Such hand- written signatures maintained electronically should not be confused with true electronic signatures, although both can have the same legal significance. Non-biometric electronic signatures are executed by entering a User ID and password. If the operator is at the computer for a continuous time period, electronic signatures may be executed by entering only the password for each signing. The requirement for entry of User ID and password is satisfied during the initial logon to the system and it is possible to consider this an electronic signature, so that a password alone can subsequently be used for signing, if other requirements are met. In particular these should include controls to prevent impersonation such as remaining in close proximity to the workstation, inactivity auto-delogging and strict password security. In order to assure that the individual was continuously at the computer, there should be controls in place such as automatic time-outs or other appropriate measures. If operator activity is not continuous then each signing should be performed by entering both the User ID and password. This may be the case if the operator leaves the computer between entries to perform other functions.

5.3.3 User ID and Password Controls 

The nature of non-biometric signatures is such that strict controls are necessary to ensure their integrity and authenticity. In order to ensure that an electronic signature can only be executed by a unique individual there should be a policy that User IDs should be unique and never reused or reassigned to another person. If the system is accessible over the company wide area network, the combination of User ID/Password needs to be unique across the entire company. If, however, the system is, for example, only accessible within a site’s local area network the uniqueness need only be proven within the coverage of that network. The identity of an individual should be established upon issuance of a new User ID. A procedure should be in place to ensure that access is requested and authorized appropriately and that when a person leaves a department or changes responsibility their security authorisation is re-examined. Similarly, when a person leaves the site their account should be disabled immediately upon termination. Lists of users and their security levels should be periodically reviewed to ensure that only authorised staff have access to computerised systems. Password control is also crucial for non-biometric electronic signatures. It is essential that the password be known only by the individual who owns it. System managers, owners, vendors, or other technical staff may have the ability to reset the password in the event that it is forgotten or compromised but password maintenance by a user’s peer or colleague is not an acceptable practice. When an individual forgets their password it should be necessary to establish the identity of the person prior to resetting it. Upon first use of a newly issued or reset password the system should force the user to change to one known only to them. For systems that lack this functionality procedures should be in place to achieve the same result. If a User ID or password has been compromised, there should be a procedure to promptly de- authorise it. Passwords should have a defined lifetime and require periodic changing by the owner. There should be a system in place to detect repeated incorrect attempts at entering a password. If it appears that these attempts are from an unauthorised person, there should be an investigation. If the attempts are serious, or if there is a pattern of repeated attempts, functional management of the individual whose password is involved should be notified. In that case, the function should instigate an investigation in order to determine how the incident occurred.

5.3.4 Tokens and Cards 

In some cases, devices such as tokens and cards may be used to store User ID or password information, but not both. In such instances there should be adequate control over issuance and retrieval of these devices to ensure that they are used only by their authorised owners. Written procedures should be in place to electronically de-authorise cards that are lost, stolen or potentially compromised. When an individual leaves a department or the site, a procedure should exist which ensures that the card will be returned prior to the person’s departure. Procedures should describe practices for the issuance of temporary and permanent replacement of lost or stolen cards. Tokens or cards should be tested initially and periodically thereafter to ensure that they continue to function as designed, and have not been altered.

5.3.5 Display of Electronic Signatures 

There are specific requirements for the display of the elements of an electronic signature both on screen and when printed, during and after signing. The name of the signer must appear on screen before completion of the signature. The reason for this is to emphasise the importance of the act of signing to the signer. At any time after signing the meaning of the signature must also be displayed together with the date/time of signing so that it is immediately clear to anyone who sees the human-readable form of the record who signed it, when it was signed and what the signature meant. Display of a User ID is not an acceptable substitute for the name of the signer although, since names are not necessarily unique, it may be helpful to display the signer’s user ID in addition to the name to avoid potential ambiguity. The meaning of the signing may simply consist of “Approved”, “Reviewed”, “Agreed” or a similar ‘action’ word.

5.3.6 Falsification of Electronic Signatures 

Hand-written signatures have a long history of acceptability and are universally recognised as a means of recording an individual’s identity. Electronic signatures do not have the benefit of this history, so it is important that people be made aware that they are the legally binding equivalent to hand-written signatures. Staff should understand that they are accountable and responsible for actions performed under their electronic signature. Procedures and training should reinforce the necessity to keep passwords private and to avoid recording passwords in a way that others can discover them. In the event that falsification is discovered, there should be a formal investigation to determine the source of the security breach. If the individual whose security was violated was also found responsible for the violation through negligence or by sharing a password with another person, appropriate action, including possible disciplinary action, may be necessary. If the violation was outside of the person’s control, then the cause of the violation should be addressed in order to prevent recurrence.

5.3.7 Individual Certifications 

For systems that utilise electronic signatures, each user of the system who will execute an electronic signature must sign a certification declaring that his/her electronic signature is the legally binding equivalent of his/her hand-written signature, prior to being granted the authority to perform electronic signings. This serves to confirm that the signer accepts the significance of the electronic signature, besides being a specific regulatory requirement. There should be documented training of these individuals to indicate that they understand the significance of the certification. This certification need not be submitted to FDA, but should be retained and available in the event of an FDA or other authority request.

5.4 Interpretation for Specific Types of Systems

While general guidance is included in this document for the use of electronic records and electronic signatures, specific guidance is given here for various classes of computer systems. The guiding principle in arriving at these interpretations is the question of whether the system keeps records that are required by a law or regulation. It is important to note that although there may be instances where systems need not comply with the requirements for electronic records any system used for GMP, GLP, or GCP activities must be validated. Not all systems will fall cleanly into one of the categories listed below. In these cases it is not possible to provide specific interpretation here and additional advice may be sought.

5.4.1 Document Management Systems

Document Management Systems accept electronic or scanned documents as input and facilitate management of them through various phases of their life cycle. These documents may be SOPs, reports, change control forms, regulatory submissions or any of a host of document types that must be maintained. Some systems have electronic signatures, while some use the hybrid approach, where a hand-written signature is used to authenticate a printout of an electronic document. Whether or not they use electronic signatures, Document Management Systems that hold regulated documents and are used for more than merely maintaining and reissuing paper reference versions must comply with the requirements for electronic records. If electronic signatures are used for regulated purposes they must also comply.

5.4.2 Real Time Systems (eg. PLCs)

These systems, typically used in manufacturing operations, generally collect data directly from equipment. The PLC itself does not need to comply with the electronic record requirements if there is no permanent storage of an electronic record in the device i.e. it is transient data. However, if the data is transmitted to another system such as SCADA or DCS, that system becomes a repository for the data, and, where the records are required by regulation, needs to comply with the requirements for electronic records. In many cases there may be a set-up or configuration file, which, rather than being only to set options in the software, is a set of parameters that may be stored in non-volatile memory, for example on a hard drive or floppy disk. These files can be uploaded or downloaded to/from the PLC or a lab instrument and therefore should be considered to be a record, although physical controls could then be applied which reduce the risks associated with use of that record to a level which requires only relatively routine additional logical and procedural controls such as validation and access and change control. Hard-coded production recipe parameters should be avoided as this may cause the PLC software to be considered an electronic record. In that case a risk assessment should be done to establish the extent of measures needed for compliance.

5.4.3 Remote Data Entry Systems

These systems are typically used at clinical investigators sites or Clinical Research Organisations (CROs). Patient data is entered directly into a computer system either by the patient, investigator or study co-ordinator and uploaded to site’s system for storage and eventual uploading into a permanent database for storage. These systems fall within the scope of this guideline.

5.4.4 Statistical and Modelling Programs

These systems are often used in the clinical and pre-clinical areas. Typically they take input data and perform calculations that are either printed or transmitted to another system such as LIMS. If the sole purpose of a program is the mathematical manipulation of data that is permanently stored elsewhere, then it is not necessary for the manipulating program to be in compliance with the electronic record requirements. However, regulated applications do need to be validated.

5.4.5 Electronic Data Capture Systems

Systems in this category capture data directly either by keyboard entry or through an interface with a piece of equipment or a sensor. The data is then stored within the system. Diverse types of data may be stored in this type of system, including laboratory data, warehouse temperature readings, or any other type of data or measurement that may be required by GMP, GLP, or GCP. These systems need to comply with the requirements for electronic records wherever the stored records are subsequently to be used for regulated purposes. If regulated electronic signatures are used, they also need to comply.

5.4.6 Tracking Systems

These are systems used only to track or index, not to store regulated records. In effect they are of secondary importance to quality attributes. There are many systems whose main focus is to track information. Examples of such systems are those training systems that only track due dates, calibration or maintenance reminder systems not storing actual performance data, or SOP indexing systems not storing actual SOP text. Such systems are not actually maintaining regulated electronic records, and do not need to comply with the requirements for electronic record and electronic signatures. For example, in a system used for calibration tracking, the calibration schedule may be an electronic record, although in the low risk category, while the actual tracking messages that create alerts that the calibration is due, may not be. Of course, there must be adequate paper or electronic records to document the activities that are being tracked, such as actual training records or calibration records.

5.4.7 Material Management Systems

Material Management systems are used for a wide variety of functions. These systems are so diverse in design that it is impossible to make a generalisation that would always include or exclude them from needing to comply with ER/ES requirements. These systems need to comply when, as is usually the case, the records are stored and used for regulated purposes. Electronic signatures required by regulation must be in compliance.

5.4.8 Process Control Systems

Process control systems (for example SCADA and DCS) not only control process equipment, but also frequently capture data related to the process. These systems are often hybrid systems, and can include electronic signatures in some cases, where for example they form part of a batch record. Unless the system is used only to generate a print of data for inclusion in a regulated record, then, since these systems capture data from production, they may need to meet the requirements for electronic records where any of these are kept for regulatory purposes, and for electronic signatures if used and required by regulation.

5.4.9 Laboratory Information Management Systems (LIMS)

LIMS are frequently used by regulatory agencies as examples of electronic record systems, and are within the scope of the rule, both for electronic records, and for electronic signatures where used and required by regulation.

5.4.10 Laboratory Instruments/Equipment

Laboratory equipment must comply with ER/ES requirements if it stores records, which are subsequently used in electronic form for regulated purposes. Equipment that has the capability of storing such data electronically, especially if that data can be modified or deleted by an operator, is likely to need to comply. Some laboratory equipment only stores transient data and prints out the results directly or passes them to a supervisory system. As with any system, it is permissible to take a print of any record and make that the raw data provided it is verified as complete and accurate and the electronic version is not used for any further regulated purpose. When equipment is connected to an information gathering or supervisory system, such as a LIMS, then the decision as to whether it is necessary for the equipment to comply with ER/ES requirements will be dependent upon its design. If the data (both raw and derived) is automatically uploaded to the LIMS and the data on the host system represents an accurate and complete copy of the record from the instrument, then the computer on the instrument can be considered to be storing only transient data and need not comply with ER/ES. In some cases, the LIMS or host system may not be able to upload an accurate and complete copy of the data, for example in a chromatography system, where a paper version may also not meet business needs. In that case, it may be necessary to store the chromatograms on the individual instrument that must comply with ER/ES. Some instruments interface with LIMS. For these instruments, the link to LIMS must be validated as well as the instrument itself, and the regulated records transferred from the instrument to LIMS must be considered electronic records within the context of the LIMS.

5.4.11 Interactive Voice Response Systems

Systems in this category not only capture data but also control clinical studies via telephone, typically using telephone keypad entries and voice commands. The data is then processed and stored within the system. The systems are often used to control stock and record patient data and statistics. These will be electronic records and may include electronic signatures.

5.4.12 Spreadsheets

Spreadsheets are used for a wide variety of purposes, from facilitating calculations in the laboratory to managing lists in a manner similar to a database. The use of the spreadsheet is the determining factor as to whether it needs to comply with ER/ES requirements. If the spreadsheet is not modifiable by the user except to enter data and the final spreadsheet is printed and not stored for further regulatory purposes, then it should not need to be in compliance with ER/ES. However, for regulated uses, the spreadsheet must be validated and good change control practices in place. The use of a secure, validated document management system to manage spreadsheets is encouraged. Where a spreadsheet is used as a database, such as for tracking training, calibration, or other GXP activities, then its need to comply with ER/ES requirements should be considered. If records are being stored for later use, then the ER/ES requirements for the spreadsheet are in principle no different from any other regulated application, with due consideration for the level of risk being taken into account.

5.4.13 E-mail

Any system used to transmit regulated electronic records is within the scope of ER/ES. The use of e-mail for transmission of regulated information is generally discouraged due to the difficulties in complying (for example, the need to validate). However if e-mail is used for this purpose, the business owner of the process using e-mail as a means of transmission must be aware of and own the accountability for the associated risk. Controls must be put in place to alleviate the risk and enable compliance.