| ||||||||||||||
|
|
|||||||||||||
Department of Anesthesiology and Critical Care Medicine, Hadassah - Hebrew University Medical Center, Jerusalem, Ein Karem, POB 12000, Jerusalem, 91120, Israel
| Abstract |
|---|
|
|
|---|
| Introduction |
|---|
|
|
|---|
The challenge was to collect data for a multicenter study of ethics and decision-making in intensive care units (2). The study was expected to continue for 2 years and include between 3000 and 5000 patients. Realizing that it could be impossible to cope with vast amounts of data using classic data acquisition methods, we built an Internet site to facilitate data entry and communications with the participating centers.
This article examines the problems and issues faced during the design, implementation and operation of this Internet data collection scheme. The aim was to identify problems that arose during this endeavor and propose solutions for future use of the Internet for data collection.
| Methods |
|---|
|
|
|---|
Building a Web site for data entry requires client-sided (e.g., a browser program on the users computer) and server-sided (on the computer where the site is hosted and connected to the Internet) programming technologies (for example Java-Script, Perl, Active Server Pages). Microsoft FrontPage (Versions 97 and 2000, Microsoft, Redmond, WA), a web authoring tool with built-in scripting functions, was chosen for building the Web site. Client-sided built-in JavaScript functions were used for basic data validation and to assure that certain required fields are filled in before transmitting the data. The server-sided scripting functions were used for data forwarding by e-mail to the coordinating center.
The site was hosted at Verio (http://www.verio.com), one of the worlds largest web hosting companies.
Data were imported to the database (Microsoft Access 97) and reviewed and validated manually by the study-coordinating center. Investigators were contacted by e-mail to request correction or clarification of data. The investigators were to send corrections or clarifications through the Web site or by e-mail.
| Results |
|---|
|
|
|---|
Data entry was performed directly onto the Web site through different web pages with 19 detailed questions. These pages incorporated 194 different data entry fields, such as text form fields, combo boxes (predefined selection lists), radio buttons (only one option of several can be chosen), and check boxes (checked or unchecked) (Fig. 1).
|
The data entered into the combo box, the radio button, and the check box were coded and only the code was sent, whereas with the free text field the actual text was sent.
FrontPage has built-in JavaScript functions for basic client-sided data validation. These functions checked that the right data type was entered in the free text field (e.g., number and not text in the patients age field) and to assure that certain mandatory fields (e.g., patient number) were filled in before the data could be sent. A message box informed the user of incorrect or missing data. The number of free text fields was kept as small as possible so that efforts were directed at using combo boxes with predefined values to reduce improper data entry and to improve the Web sites ease of use.
Security was an important consideration. Entrance to the web site was username/password protected and the site was not published in any Internet search engine. The patients were identified only with a unique number. The key identifying the patients was kept with the centers. After data entry, the built-in server-sided FrontPage functions generated an e-mail message containing the data and sends it to an account on the research server at Verio. Those e-mails were periodically automatically downloaded to the research computer at the Hadassah University Hospital, which was connected to the Internet through a firewall program protecting the Hadassah local area computer network.
After downloading to the research computer, the e-mails with the patient data were saved as text files and imported to the database (Microsoft Access 97). The data were then reviewed and validated manually by members of the research group. Also, data sent as free text (e.g., patient diagnosis), was coded manually for later statistical analysis. The centers were contacted by e-mail to clarify questionable or missing data. The corrected and completed data could be returned by the investigators to the coordinating center either by e-mail or via the Web site.
Newsletters were published regularly on the Web site informing the investigators about study related issues. On the FAQ (Frequently Asked Questions) page answers to common problems were provided.
At the end of the study, 24 (65%) centers answered an anonymous survey we performed to evaluate the design and usability of the Web site (10 = best to 1 = worst) (Table 1). Overall satisfaction was high (median 8, interquartile range 89).
|
| Discussion |
|---|
|
|
|---|
The overall performance of this data collection system was as planned. The participating investigators used the Web site successfully with minimal training. Acceptance was high and data from large number of patients were entered. Newsletters published regularly on the Web site maintained communication between the coordinating center and the investigators.
In the following in-depth analysis of this data collection system, we discuss a number of important issues that should be of concern when planning and implementing such a system.
Data entry should be as easy as possible using predefined data fields (list fields, radio-button fields, check boxes). Free text files should be avoided to prevent incorrect data entry and to reduce the amount of data that has to be coded manually. This design appeared to reduce the amount of incorrect or questionable data entry.
Data validation may be accomplished in four different ways:
|
|
|
|
Remote-sided databases lack interactivity and are less user-friendly compared to server-sided databases. On the other hand, security is easier to handle on a remote-sided database (i.e., a computer behind a firewall program or even without direct connection to the Internet) than server-sided ones (i.e., a computer connected to the Internet). Server-sided databases may be prone to hacking, which is less possible with a remote-sided database. Backing up data is easier and safer for remote-sided than server-sided databases. When backing-up a server-sided database to a local backup system the data have to be transported over the Internet (with encryption technology). Depending on the speed of the Internet connection, this can be time consuming.
It is possible to set up ones own server, which resides physically in the coordinators location. This allows the study coordinator to have more control over a server-sided database. But this approach requires considerable experience and investment in hardware, software, and manpower.
Microsoft FrontPage allows building and designing Web site without any knowledge in HTML. With its "What you see is what you get" approach, the user can easily design a webpage and Microsoft FrontPage immediately creates the corresponding HTML code. Furthermore, no knowledge in any programming language is needed to use the built-in client and server-sided scripting functions for data validation and handling. Microsoft FrontPage is an inexpensive, easy-to-learn, and easy-to-use web-authoring tool.
The web site implemented in the current report had one-way data flow and combined client-sided and remote data validation. Although FrontPage has built-in functions for server-sided database handling, for security reasons we preferred to choose a remote-sided database approach and to have the database reside physically on a computer at Hadassah.
The lack of interactivity between the user and the database resulted in a large workload, as for every incorrect or missing piece of data that slipped through the initial client-sided check, the investigators had to be contacted by e-mail and the corrected data had to be entered manually. To reduce the workload, the use of free-text fields should be minimized or even avoided.
After the data were entered through the Web site, server-sided FrontPage functions (so called "FrontPage Server Extensions") sent the data by e-mail to an account on the server. Although the e-mails were then downloaded automatically to the research computer at Hadassah, the rest of the data importing process (opening the e-mail, saving it as a text file, and importing the data into the database) was done manually. This was a very time consuming process, which can now be done automatically using various commercially available add-in programs for automatic e-mail handling.
During implementation and use of the system, several problems were encountered. Among the main problems was the web sites lack of interactive features.
Security, next to user friendliness, is the most important issue when building a web site for data entry (1,9). Although there are several techniques to ensure data safety (e.g., usernames, passwords, data encryption, firewall programs), no system is foolproof. Besides technical issues, other precautions have to be considered, e.g., patient data should be depersonalized using a coding system to prevent patient identification by unauthorized persons.
For data safety reasons we decided to use a remote-sided database concept. Our database resided on a personal computer connected directly to the Internet and protected by a firewall program, and it was therefore "invisible" to the Internet community and potential hackers. The down side of this security feature is lack of interactivity between the person entering data and the database. This led to a large workload for the coordinating center, which had to manage and validate incoming data. With the technologies for data encryption available today, secure database management can be done over the Internet, probably as safely as with older paper systems (1).
Transport of the data (from the client to the server and from the server by e-mail to the coordination center in Jerusalem) was done over the Internet in an unsecured manner (without data encryption). It was assumed that the chance of somebody hacking these e-mails (which contained almost only numbers without any information about the nature of the data or details identifying the patients) and breaking confidentiality was very remote.
The results of the anonymous survey of investigators showed a very good acceptance of this Web site design (Table 1). Only the interactivity of the Web site was rated lower (median 6, interquartile range 58) than the overall satisfaction (median 8, interquartile range 89). As discussed above, the lack of almost any interactivity is the major drawback in choosing a one-way data flow system with remote data validation. Unfortunately only 65% of the centers replied to the survey, so it is possible that some nonresponders disliked this design. Oral feedback received at several meetings with the investigators was generally very positive.
| Conclusions |
|---|
|
|
|---|
| Footnotes |
|---|
Accepted for publication July 26, 2004.
Address correspondence to Alexander Avidan, MD, Department of Anesthesiology and Critical Care Medicine, Hadassah - Hebrew University Medical Center, Jerusalem, Ein Karem, POB 12000, Jerusalem, 91120, Israel. Address e-mail to alex{at}avidan.co.il.
| References |
|---|
|
|
|---|
This article has been cited by other articles:
![]() |
B. M. Ilfeld, V. J. Loland, J. C. Gerancher, A. N. Wadhwa, E. M. Renehan, D. I. Sessler, J. J. Shuster, D. W. Theriaque, R. C. Maldonado, E. R. Mariano, et al. The Effects of Varying Local Anesthetic Concentration and Volume on Continuous Popliteal Sciatic Nerve Blocks: A Dual-Center, Randomized, Controlled Study Anesth. Analg., August 1, 2008; 107(2): 701 - 707. [Abstract] [Full Text] [PDF] |
||||
![]() |
J. H. van Oostrom Web-Based Data Collection: Security Is Only as Good as the Weakest Link Anesth. Analg., December 1, 2005; 101(6): 1888 - 1888. [Full Text] [PDF] |
||||
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|