implementation of electronic signatures and records in a clinical cro: a case study

Key WordsCCRROO;; ee--ssiiggnnaattuurreess;; ee--rreeccoorrddss;; bbiioommeettrriiccss;; ee--mmaaiill;; eennccrryyppttiioonn;; 2211 CCFFRR PPaarrtt 1111

The prevalence of e-communication and e-records within the pharmaceutical industry

has focused the attention of the quality unit inour facility (a specialist Phase I clinical CRO[Contract Research Organization]) on security aswell as the compliance aspects of the GxPs. Inorder to address these issues, we set about evaluating commercial solutions and we also

considered customized options. This paperdescribes some of the steps we have taken to meetthe technological challenges.

Electronic Communication

In electronic communication, e-mail itself is notthe real problem – it is the fact that most peopledo not provide the information as ASCII textwithin the body of the e-mail messages but usuallysend it as a word-processed and formatted document file, such as MS-Word™. Further, thereis a trend to move away from facsimile transmis-sion for draft study plans and protocols, proba-bly because it’s easier to work directly from theuser’s own PC rather than printing out the docu-ment, which adds the extra burden of a walk tothe printer and then to the fax machine. However,attaching a signature to such an e-document,which would be acceptable in a court of law, onlyrecently came under EEC legislation (1999) [1]although the situation was addressed earlier inother countries such as the USA (1996) [2] andItaly (1997) [3]. An international summary of thelegislation regarding e-commerce in variouscountries is available [3].

The problem of security with e-mail is compounded by the fact that the recipient maynot have the correct program to open a file. Also,binary files always increase the risk of macrovirus infection so there must be a simple solutionto this part of the problem as well. A CRO mustdeal with external clients, each of which may havetheir own policies which probably do not matchwith the CRO’s policy and thus the CRO is in amuch more difficult position in this regard thanthe large pharmaceutical company which can dic-tate an internal company-wide software policy.

Implementation of Electronic Signatures and Records in a Clinical CRO: A Case Study

Graham D. Ogg*

DDS Medicines Research Ltd, Ninewells Hospital & Medical School, Dundee DD1 9SY, UK

Copyright © 2002 John Wiley & Sons, Ltd. Qual Assur J 2002; 66, 227–233.DOI: 10.1002/qaj.196

*Correspondence to: Graham D. Ogg, DDS Medicines Research Ltd,Ninewells Hospital & Medical School, Dundee DD1 9SY, UK.E-mail: [email protected]

Summary

IImmpplleemmeennttaattiioonn ooff eelleeccttrroonniicc ssiiggnnaattuurreess aannddrreeccoorrddss iinnccuurrss ssppeecciiaall pprroobblleemmss iinn aa ssppeecciiaall--iisstt PPhhaassee II cclliinniiccaall uunniitt wwhheerree rraappiidd ccoommmmuu--nniiccaattiioonn,, rraappiidd rreeppoorrttiinngg,, ccoommpplliiaannccee wwiitthhaapppplliiccaabbllee rreegguullaattiioonnss aanndd hhiigghh qquuaalliittyy aarreeooff ppaarraammoouunntt iimmppoorrttaannccee.. BBootthh tthhee bbuussiinneessssnneeeeddss aanndd tthhee rreegguullaattoorryy ccoommpplliiaannccee iissssuueessmmuusstt bbee ccoonnssiiddeerreedd iinn aannyy ppoossssiibbllee ssoolluuttiioonnssaanndd tthhuuss ssoommee ffoorrmm ooff aauutthheennttiiccaattiioonn ooffrreeccoorrddss aanndd ccoommmmuunniiccaattiioonnss iiss rreeqquuiirreedd.. IInnoouurr ffaacciilliittyy,, tthhee rreeqquuiirreemmeennttss ooff 2211 CCFFRR PPaarrtt1111 ddiidd nnoott ggoo ffaarr eennoouugghh rreeggaarrddiinngg aauutthheennttii--ccaattiioonn aanndd wweerree ddiiffffiiccuulltt ttoo iimmpplleemmeenntt bbyymmeeddiiccaall ssttaaffff ccoolllleeccttiinngg ddaattaa.. BBiioommeettrriiccaauutthheennttiiccaattiioonn ooff ddaattaa eennttrryy aanndd eennccrryyppttiioonnooff ccoommmmuunniiccaattiioonnss aappppeeaarreedd ttoo bbee tthhee bbeessttssoolluuttiioonnss.. CCooppyyrriigghhtt ©© 22000022 JJoohhnn WWiilleeyy &&SSoonnss,, LLttdd..

Internal e-mail can be controlled by the use ofstandardised e-mail clients e.g. Pegasus Mail™,Eudora™ or Outlook™, etc. and an office soft-ware suite e.g. Microsoft (MS)-Office™ within theorganisation. Each company’s own anti-viruspolicies should ensure that there is no internaltransmission of infected material. These policiesalso ensure that the recipient can open anyattachments. As the MS-Office suite is almost aglobal standard, externally sent attachmentsusing this system should be able to be safelyopened. However, there is a potential problemwith earlier versions of such suites in that attach-ments to later versions cannot be opened as thefile structures may not be understood by theolder software. There is also the problem that therecipient may not be using the same platform e.g.Apple Mac™, Sun Sparc™, etc.

Another problem with e-mail communication,perhaps the most serious and most difficult, isauthentication of who sent the e-mail. With inter-nally sent e-mail, the authentication is carried outby the network operating system such as MS-Active Directory™ or Novell e-Directory™.Identification is implicit within such a system asno other public networks are involved. However,external e-mail moving across the internet is much more problematic in that there is no sim-ple way to prove who sent the message or to deter-mine that it had not been intercepted and tam-pered with en route.

There are therefore two e-communicationproblems to be addressed: the ability to readattachments and authentication of senders. Wecan solve both by using attachments which aredigitally signed. From the discussion above, it isclear that what we require is a standardisedportable document format. Fortunately, one suchsoftware package that fits the task is AdobeAcrobat™: it also has the benefit of accepting dig-ital signatures that can be indelibly linked to thedocument using third party software from vendors such as PenOp [4], Motion Touch [5],Cyber-Sign [6] and Approve IT [7]. These soft-ware packages allow the insertion of single ormultiple digital signatures, along with the reasonfor signing - essential when dealing with contractsand protocols. Further, if a document is tampered

with in any way, the signature is crossed out, visi-bly indicating a problem. The packages can alsobe used to provide secure access to a network andthat was an important reason for our organiza-tion to go this route.

All of the above-mentioned software packagesuse biometric authentication [8] of the users signature, which must be pre-enrolled (analogousto the network administrator providing an initialuser name and password). The enrollment is carried out by collecting sample signatures fromthe users using a graphics tablet and stylus.Normally a sample of three or four signatures istaken and the software averages these to producea unique ‘biometric token.’

From a QA and security point of view, it mustbe confirmed that a biometric token is never sentacross a network in native format. This conditionmust be determined by reference to the softwaremanufacturer and the product specification. Theenrolled signature sample is stored on the serverin a secure area and is never transmitted over thenetwork for the authentication. The software onthe users’ workstation accepts the signature fromthe graphics pad. The signature is then interpret-ed and converted, using a proprietary algorithm,into a calculated ‘hash value’ (number). The hashvalue is transmitted to the server and comparedwith the hash value generated on the server fromthe stored biometric token. If both values matchthen access is granted to the network resource:conversely, if the values do not match, access isdenied. The hash value is converted to the realname of the owner of the biometric token and thatis what is written to the database file, making iteasy for humans to read.

Bruce Schneier [9] has provided us with a con-venient definition of biometrics, which is relevantto this discussion of security: ‘Biometrics workgreat only if the verifier can verify two things:one, that the biometric came from the person atthe time of verification, and two, that the biomet-ric matches the master biometric on file. If thesystem cannot do both, it’s insecure.’ The theft ofa biometric such as a retinal scan or finger printwill have serious consequences for the user as itcan never be replaced. Again, as stated by BruceSchneier [9]: ‘Imagine that Alice is using her

228 G. D. Ogg

Copyright © 2002 John Wiley & Sons, Ltd. Qual Assur J 2002; 66, 227–233.

thumb print as a biometric identifier and some-one steals the scan. Now what? This is not a truedigital certificate, where some trusted party canissue her with another one. This is her thumb.She only has two. Once someone steals your biometric. It remains stolen for life: there’s nogetting it back.’

Some of you might ask, why bother with bio-metrics when you can use a ‘secure’ user nameand passwords? In fact, the latter is all that isrequired under 21 CFR Part 11 [10]. However,who of us can confidently state they have never shared a password, written it down or useda family member’s name or other familiar identi-fier as part of the password. The sharing problemalso applies to smart cards and ‘dongels’ (a secu-rity device that plugs into a serial, parallel orUSB port on your computer), etc. Passwords canbe ‘cracked’, using dictionary algorithms, easilyobtained via the internet.

Authentication is the key issue here. In orderto clarify this, refer to the following definitionprovided by Julian Ashbourn [11]:

The distinction between authentication (verification) and identification is relativelystraight forward:

Authentication refers to the authentication orverification of a claimed identity. In other words,the user wishes to log on to a network or service,and claims to be a certain person. The authenti-cation process seeks to verify this claim via thebiometric token and comparison with a storedsample. This allows for the one to one matchingprocess as the characteristic in question ismatched against the reference associated with the claimed identity, according to predefinedthreshold criteria.

Identification seeks to identify a user fromwithin a population of possible users, accordingto a characteristic, or multiple characteristicswhich can be reliably associated with a particularindividual, without an identity being explicitlyclaimed by the user. This is a one to many match-ing process against a database of relevant data e.g. MS-Active Directory™ or Novell e-Directory™.

Although an e-mail attachment may contain a digitally-signed document, we still cannot be

certain that it was actually sent by the person itpurports to be from. However, we can eliminatethis problem by the use of encryption and thirdparty digital certificates, such as those developedand provided by trusted third parties such asVerisign™ [12] and Chamber Sign™ [13]. In myexperience, it has been noted that some e-mailclients and versions do not necessarily supportthis technology: in those cases, a digital ID in freetext format within the body of the mail messageleaves the recipient wondering about the authen-ticity of the ID. Getting a sponsor company to usethe same mail client as the CRO, such that infor-mation exchange is transparent and authenticated,is highly improbable.

Perhaps the way forward is to use a public keyinfrastructure (PKI) [14] as e-mail is authenticat-ed upon receipt, and any attached documents aredigitally signed. Using a system of private andpublic keys ensures that there is no doubt aboutwho sent what. This type of system was also pro-posed by John Spotila, (Administrator, Office ofInformation & Regulatory Affairs, USA) [15]:‘Cryptography-based digital signatures hold greatpromise for ensuring both authentication andprivacy in networked interactions and may be theonly technology available to foster interoperabilityacross numerous applications.’

[How is a hand-writing biometric token pro-duced? This was outlined previously but perhapsa little more detail would help in clarifying theconcept. It is necessary to equip each work sta-tion (e.g. small notebook PC) with a pressure sen-sitive graphics tablet such as an e-pad™ which isused to collect signatures. The software on theworkstation processes the pressure informationfrom the signing process into a biometric token.The token is further processed and the hash valueproduced is sent to the server for authenticationagainst a previously enrolled sample, which hasalso created a hash value used for the comparison.If a match is found, the signer is given access tothe system: if the signature is rejected, the signermust try again. The threshold of acceptance orrejection must be chosen carefully to preventfalse positives (determined in the Test Plan). Falsepositives can lead to the assignment of an e-record to the wrong individual and thus it is


Implementation of Electronic Signatures 229

imperative that the QA unit considers this possi-bility in planning and conducting audits.]

Electronic Records

The authentication process for electronic recordsintroduces other problems. Our company wantedto speed up production of clinical trial reports inorder to provide a fast service for our sponsorsand therefore resolution of problems with elec-tronic records was a top priority.

The Phase I clinical trial is one of the mostcritical as it is the first stage after the pre-clinicalphase of the drug development process and fromsuch trials information is gained to help in decid-ing whether to proceed with further development.Any delays at this early clinical trial stage preventa candidate drug moving to later stages of drugdevelopment. As some of these stages are carriedout in parallel, rather than serially, a timely trialconclusion is vital to cost savings or profit.Consequently, the faster we are at reporting trialresults, the faster to market, should all tests meetthe expected outcome.

It is estimated that a single day’s delay in gettinga drug to market can cost between US$1million toUS$13 million in lost sales [16]. In an article byGiles Wilson [17] he presented some interesting statistics such as: the average pharmaceutical company produces approximately 50 drugs peryear. Wilson also speculated that the importance of electronic records, especially e-CRFs, will becomemore pressing with the completion of the mappingof the human genome. He estimated that this willresult in an increase in the number of new drugsproduced, up to 200 per year by 2001. Up to 4000new drug targets per year could be identified.Therefore, any systems for speeding up delivery ofscientific information must be considered essen-tial, especially for the contract research side of theindustry which will most likely host this projectedexplosion in new drugs.

In most Phase I trials, pharmacodynamic andpharmacokinetic data are collected on paper casereport forms (CRFs) and record sheets: 95% ofall clinical trials in the world currently use this

method [17]. The objective of the CRO and thesponsor is to remove as much of the paper as pos-sible and collect data electronically, so as to speedup the process of decision-making. Our QA unitparticularly saw this change as problematicbecause dealing with electronic records was a newprocess in our operations. We still operated a sys-tem where raw data consisted of signed and datedpaper records.

Changing to e-records brought about our QAunit’s first experience of software project designand implementation, and required extensiveresearch. First, an important point to note wasthat the QA unit was consulted at the planningstage of the project, resulting in a good relation-ship with the external contracted programmer.This relationship allowed us to deal efficientlyand effectively with any quality or complianceissues as the project progressed. Any existingstandard operating procedure (SOP) require-ments were also included within the projectdesign such that little change to normal opera-tions was necessary.

The main objective of the project in our com-pany was to prepare a customised, server-baseddata collection program, compatible with WWWstandards. The interface used by our nursing andclinical staff was part of a simple web browserand was familiar in that it was based on a con-ventional CRF, typically produced internally. Allclinical instruments (such as cardiological tele-metric monitoring and blood pressure, as far aspracticable) provided output directly to a ‘closed’network (i.e. no connections to public networks)and the output information was picked up by the server and displayed on the browser. Somemanual measurement was still required and someform of manual input to the browser-based CRFwas also provided.

Standard methods (user name and password) ofnetwork access were not suitable for our systemdue to several factors such as the speed requiredfor data entry and the fact that multiple personswere making simultaneous entries. The system wastherefore designed to verify the user before storingthe data, reversing the normal trend to authenticateusers before using network resources.

230 G. D. Ogg


The conduct of a pharmacokinetic study,where there are, perhaps, 12 subjects and 15 minsamples/measurements to be taken, may involvemany people putting information into the systemand different people using the same workstations.Initially, our workstations were required to bephysically plugged in and out of the networkpoints at each bed in the clinical ward and thiscaused delay in collection of data and frustrationamongst staff during the trial phase. This prob-lem was overcome by the use of an encryptedwireless network access node and by equippingeach workstation with a wireless Ethernet card.

Requiring staff to log on and off the network,along with script processing and application loading, takes much time and could spoil theworkflow, perhaps leading to missed data capturetime points. At this point, the biometric signatureoption becomes invaluable, as only one serveraccount is required since the data captured andsent to that account is attributable to the signer. In order to be assured of optimal securityand authentication of the electronic signaturesattached to the records, a system of biometrics of handwriting was used in our project, mainlybecause it is unobtrusive and natural. It also reduces the amount of training required fornursing staff that were already used to signingCRFs. As with e-communication, use of biometrics rather than conventional user nameand passwords or swipe cards overcomes the problems of sharing of confidential informa-tion and possible intentional or unintentionalfraud.

In our situation, other methods of biometricauthentication were considered but they wererejected for several reasons. Iris scanning was tooobtrusive and slow. Finger prints were not con-sidered to be practical due to the use of gloveswhen taking blood samples or other invasive pro-cedures or even a sticking plaster over a cut in thefinger used for sampling. As the nursing staffwere used to signing for every measurement,using signatures was thought to be a natural pro-gression of technology. (Our company chosePenOp™ after extensive review, but before wecould add the system as a front end to our server

software it was removed from sale and reincar-nated into Motion Touch™! It is important to notethat our system implementation took more thantwo years from the first idea to a working system.The QA unit must try to ensure that the softwarevendor is not going to change things rapidly sothat your validation goes out the window beforeyou can really get started.)

No major problems were noted during initialtrials and good acceptance values were obtainedfrom a small set of five staff ‘volunteers.’ Thesevolunteers submitted three samples of their sig-natures into the system and the total number ofacceptances and rejections was recorded against aTest Implementation Plan where our acceptancecriteria for the product were defined. In order toproduce such a test plan it was necessary tosearch for advice on how to validate a biometricsolution. The best source of advice we found wasa document entitled Best Practices in TestingBiometric Devices, by the Biometrics WorkingGroup [18]. This provided us with the criteria toinclude in the Test Implementation Plan.

To this point, we had shown that the authenti-cation worked to provide access to the server butthis did not cover the data capture capabilities orthe attachment of e-signatures to the records. Wenow required a further Test Plan to ensure thatdatabase records were being created and assignedto the ‘signer.’ To carry out the plan, six healthyvolunteers agreed to be ‘wired’ up so that wecould obtain some real data under normal andstressed conditions. We also had to prove that thefiles were secure from interference with a recordbeing kept of any such actions. The original data,collected live and recorded in the database, aretreated as sacrosanct and could not be modified:only the ‘create/ write’ rights are given to users.

Data are recorded in the database as a simplecomma delimited ASCII file, which allows theimportation into a database management programsuch as MS-Access™ to create queries and reports. This type of generic system without specific file type provides a common format,which should still be accessible in the next 3 – 5years [19]. To correct an erroneous record, a copyis made of the original file automatically when the



file is opened for editing. Nominated individuals,such as the system administrator, are the onlypersons able to delete or copy the original file forarchiving to compact disc recordable (CD-R) ordigital versatile disk recordable (DVD-R). Allactions to the copy file are recorded in a parallelaudit file, which contains the changed data, oper-ators’ name, date and time. For comparison of theoriginal with the copy and the audit trail, no soft-ware is needed except for a simple text viewer:this should provide a complete audit trail to satisfy the QA personnel and the regulatoryauthorities.

The auditing of e-records requires QA person-nel to confirm that the following are available:

1. Documentation of the system and its valida-tion records.

2. Software change control documentation.3. Protocol and the browser template (for

audit).4. E-signatures, attached to the records

(CD-R), providing indelible evidence of whodid what and when.

5. Full audit trail covering any changes to thedatabase and electronically signed.

6. Source code (either held by the company orunder an escrow agreement).

7. Appropriate training records.8. CD-R containing the database.9. Reports containing valid e-signatures.

In order to finally accept the system as a replace-ment for the old paper-based method, a small testclinical trial including six volunteers wasemployed. The trial was carried out using paperand the e-CRF system in parallel so that QA per-sonnel could make a direct comparison (100%checks, audit and inspection) between the paperand electronic records. If the results from such atrial were acceptable then the e-CRF systemcould be used as a complete replacement of thepaper system.

The results from this trial were successful andthe system is now in operation within the companywhere the study requirements permit. At this time,no e-reports have been supplied to sponsors but itis still our intention to complete this part as well.

Concluding Comments

Using e-signatures and e-records should result inless work for the QA unit as source data verifica-tion is minimized and validated systems are inplace. There will be fewer requirements for QCchecking and less transcription, speeding up theproduction of the final report. Also, from an oper-ational point of view, less archive space isrequired and there is much less photocopying todo for sponsors, which all lead to considerablecost savings. The sponsor can be provided withaccurate interim real time data summaries (e.g. adhoc reports) and be provided with a complete‘original’ copy of the raw data along with the finalreport. This was not normally possible previously.

Using a combination of an e-report with the e-mail recommendations and e-signatures suggested in the discussion above, sponsors canbe provided with a signed report in Acrobat™format, suitable for submission to regulatoryauthorities, almost instantly via e-mail. The CROcould even include the e-invoice for e-payment!The administration savings using e-methods areconsiderable, but the availability of ‘off the shelf’compliant systems is proving a real headache forthe pharmaceutical industry as explained in a let-ter sent to the FDA by the PharmaceuticalResearch and Manufacturers of America [20].The FDA was asked to consider the implicationsregarding cost (estimated at US$100M per com-pany) and time frames for the total implementa-tion and compliance with the regulations (21 CFRPart 11). Hopefully, the FDA will listen to such aplea and treat it favourably so that the generalsoftware industry has time to get its act togetherand produce the goods for us all to use.

References

1. Directive 1999/93/EC of the European Parliament and of the

Council of 13th December 1999 on a Community Framework for

Electronic Signatures. europa.eu.int/comm/internal_market/

en/media/sign/Dir99-93-ecEN.pdf.

2. Legal Infrastructure for Certification Authorities and Secure

Electronic Commerce, Information Security Committee

232 G. D. Ogg


Electronic Commerce and Information Technology Division

Section of Science and Technology American Bar Association.

www.abanet.org/scitech/ec/isc/dsg.pdf (1996).

3. Digital Signatures: a review of the international legislation.

www.webcom.com/~pjones/digital.html.

4. PenOp PenOp Ltd. Vallis House, 57 Vallis Road, Frome,

Somerset BA11 3EG, UK. WWW.Penop.com.

5. Motion Touch P.S. Communications Ltd, PSC House, Jessamy

Rd, Weybridge, Surrey, UK. www.motiontouch.com.

6. Cyber-Sign Cyber SIGN Europe SAS, 1 Traverse des Brucs,

06560 Sophia Antipolis, France. www.cybersign.com.

7. Planet PDF-PR: Silanis Approve-It 1.1 and ApproveIt Desktop

5.1. www.planetpdf.com/mainpage.asp?wepageid=1553.

8. The Role of Biometrics within Document Security Dr. Stewart

Hefferman TSSI, Swindon. www.afb.org.uk/downloads/pisec.pdf.

9. Schneier B. Secrets & Lies: Digital Security in a Networked

World, Wiley: New York, 2000, ISBN 0-471-25311-1.

10. Enforcement Policy 21 CFR Part 11: Electronic records;

electronic signatures Compliance Policy Guide 7153.17. Federal

Register 1999; 64: 41 442–41 443. www.fda.gov/ora/compliance_

ref/part11/ FRs/updates/cpg-esig-enf.pdf.

11. Ashbourn J. 2000, Biometric Definitions. homepage.ntlworld.

com/avanti/authenticate.htm.

12. VeriSign, the leading certificate authority providing public-key

infrastructure (PKI) security solutions. www.verisign.com/.

13. ChamberSign Creating Trust in Electronic Commerce. www.

chambersign.co.uk/.

14. The PKI page, provides lists of links to certification bodies and

PKI sources. www.pki-page.org/.

15. Spotila J. www.contracts.ogc.doc.gov/cld/ecomm/65fr25508.html.

16. Inqui J. Integic Corporation Europe, European Pharmaceutical

Contractor. (EPC), Autumn 2001; 56–60.

17. Wilson G, The Hidden Truth about e-Clinical Trials, European

Pharmaceutical Contractor (EPC), Autumn 2001; 106–112.

18. Biometric Working Group, 12/01/2000, Best Practice in Testing

of Biometric Devices. www.cesg.gov.uk/technology/biometrics/

media/ Best%20Practice.pdf.

19. Smith K. Analytical Data Management and Archiving, 21 CFR

Part 11 Compliance and Beyond. Pharmaceutical Technology

Europe, December 2001; 55–60.

20. Letter to John Taylor, Director Office of Enforcement, Office of

Regulatory Affairs, FDA. Rockville, MD. www.21cfrpart11.com/.

October 2001.

Web-based resources

21 CFR Part 11 details. www.fda.gov/ora/compliance_ref/part11.

Guidelines for Information Security Education Programs.

www.cpri-host.org/resource/docs/e-sig.html.

TSSI, VerID, finger print biometrics. www.tssi.co.uk/prod_ verid.htm.

Intercede, UK. www.intercede.co.uk/.

Biometric domain, lists of software/hardware sources. www.

biometricdomain.com/developers.htm.

21 CFR Part 11 Resource Home Page. pw1.netcom.com/~jlboet/

esiglinks.html.

Portal site for 21 CFR Part 11 information. www.21cfrpart11.com/.

Electronic Signatures in Europe, Denis Pinkas. Integris Ltd.

www.ivap.com/cast/cursos/fe_pinka.PDF.

Computer law and legislation in European countries.www.eurocert.

net/legislature.html.



implementation of electronic signatures and records in a clinical cro: a case study

Documents