Generalized Electronic Interviewing System (GEIS): a program and scripting method for conducting interviews in multiple modes.
ABSTRACT A program called the Generalized Electronic Interviewing System (GEIS) was developed for conducting interviews, using computer-assisted telephone interview (CATI) and interactive voice response (IVR) modes without the need for a programmed interface. GEIS questionnaires were prepared using a common script syntax in all supported modes. Scripted development allowed for rapid interview development without the need for programming. A GEIS script specified the following: question texts, including variable texts; answer option texts; numeric codes for answers; range check information; logical question-branching information; interview status information; do-loop information; and IVR information, such as key codes and voice messages. GEIS thoroughly checked scripts for logical or syntactical errors. GEIS required SAS Version 8.0, and survey data were accumulated within SAS data sets. An application of GEIS to conduct a survey involving CATI, IVR, and a combined hybrid method is described. The CATI results deviated in the direction expected for sensitive questions, whereas IVR obtained a small sample size, rendering the results unreliable. However, the hybrid method was found to provide more accurate telephone survey data on alcohol consumption than did CATI alone. The program may be downloaded from the Psychonomic Society Web archive at www.psychonomic.org/archive/.
- SourceAvailable from: oxfordjournals.org[show abstract] [hide abstract]
ABSTRACT: Motivation: The eXtensible Markup Language (XML) is an emerging standard for structuring documents, notably for the World Wide Web. In this paper, the authors present XML and examine its use as a data language for bioinformatics. In particular, XML is compared to other languages, and some of the potential uses of XML in bioinformatics applications are presented. The authors propose to adopt XML for data interchange between databases and other sources of data. Finally the discussion is illustrated by a test case of a pedigree data model in XML. Contact: Emmanuel.Barillot@infobiogen.frBioinformatics 03/2001; 17(2):115-25. · 5.32 Impact Factor
- [show abstract] [hide abstract]
ABSTRACT: Collection of sensitive data with the use of video-enhanced, computer-assisted, self-administered interviews (V-CASI) has the potential to reduce interview bias and improve the validity of the study. The purpose of this study was to compare responses to sensitive questions elicited by V-CASI and by face-to-face interview (FTFI) methods. Women attending a New Orleans, Louisiana, public family planning or sexually transmitted disease clinic from July 1995 to July 1996, diagnosed with a Chlamydia trachomatis infection responded to eight close-ended behavioral questions (four socially undesirable, two socially desirable, and two neutral behaviors) using both FTFI and V-CASI techniques in a randomized crossover design. Of the 280 women included, the mean age was 23 years, 95 percent were African American, and 71 percent felt comfortable using computers. While kappa scores indicated good-to-excellent agreement between interview techniques, women tended to admit to socially undesirable behaviors more often on V-CASI compared with FTFI. Thirty percent of the women gave a discrepant response between V-CASI and FTFI toward social desirability. Women who reported a socially undesirable behavior in V-CASI (i.e., more than two sex partners and infrequent condom usage) were more likely to have a discrepant response. Utilization of the same logistic regression model to predict condom use yielded different results when data from V-CASI were used compared with data from FTFI. The V-CASI technique can reduce social desirability bias and improve validity in research requiring information on sensitive sexual behaviors.American Journal of Epidemiology 06/1999; 149(10):950-4. · 4.78 Impact Factor
- [show abstract] [hide abstract]
ABSTRACT: Many claims are being made about the advantages of conducting surveys on the Web. However, there has been little research on the effects of format or design on the levels of unit and item response or on data quality. In a study conducted at the University of Michigan, a number of experiments were added to a survey of the student population to assess the impact of design features on resulting data quality. A sample of 1,602 students was sent an e-mail invitation to participate in a Web survey on attitudes toward affirmative action. Three experiments on design approaches were added to the survey application. One experiment varied whether respondents were reminded of their progress through the instrument. In a second experiment, one version presented several related items on one screen, while the other version presented one question per screen. In a third experiment, for one series of questions a random half of the sample clicked radio buttons to indicate their answers, while the other half entered a numeric response in a box. This article discusses the overall implementation and outcome of the survey, and it describes the results of the imbedded design experiments.Public Opinion Quarterly 02/2001; 65(2):230-53. · 2.25 Impact Factor
Copyright 2004 Psychonomic Society, Inc.784
Behavior Research Methods, Instruments, & Computers
2004, 36 (4), 784-796
In previous work, this research team found that inter-
active voice response (IVR) showed promise as a survey
and research tool but was yet to be fully explored (Corkrey
& Parkinson, 2002b). Other commonly used modes of
data collection include computer-assisted telephone in-
terview (CATI; Nicholls, 1988), paper questionnaires
(Cannell & Fowler, 1963), and touch screen computers
(Kissinger et al., 1999).
The potential scope for research projects will expand
as additional communication methods appear. These may
include mobile telephones (Alemagno et al., 1996), short
message service (Hansen & Dørup, 2001), Web pages
(Couper, Traugott, & Lamias, 2001; Smith, 1997), and
e-mail (Schaefer & Dillman, 1998; Sheehan & Hoy, 1999).
Currently, interview scripts are often prepared by com-
mon office software, specialized telephony programs, or
in-house custom applications. For example, a paper ques-
tionnaire may be prepared using a word processor. Such
methods may not provide any means of checking the
logic structure of the instrument and may not provide
consistency, so that documents will differ in style and
content between research teams, and the software used
may incorporate programming errors that can be diffi-
cult to disentangle from questionnaire errors. In addition,
the expanding range of communication methods may be
challenging for limited research budgets and may reduce
comparability between modes.
As new communication methods arise, they are quickly
adopted by researchers in order to exploit their new fea-
tures and advantages. In order to maintain comparability
of results over time, a uniform approach to interview
specification is required. For example, an interview script
for a paper questionnaire should be transferable to a tele-
phone interview with minimal changes. The script should
be supported by a single well-tested program, so that any
errors remaining can be attributed to the questionnaire.
As new communication methods appear, the supporting
software may be modified, but the script should ideally
remain constant, although the reliability and validity of
the modes will need assessment. Scripts also serve as
project documentation. We suggest that these require-
ments are best achieved by an open-scripting and open-
source software (Hansen & Dørup, 2001), avoiding pro-
prietary formats that may be restrictive, dependence on
programs that eventually become obsolete, and rapid
elimination of programming errors (da-Silva, Rodrigues,
Leite, & Milan, 2003).
This project was funded by grants from the Hunter Medical Research
Institute and the University of Newcastle and formed part of the doctoral
studies of R.C., which were supported by an Australian Postgraduate
Scholarship. Correspondence concerning this article should be addressed
to R. Corkrey, School of Biological Sciences, University of Aberdeen,
Lighthouse Field Station, George Street, Cromarty, Ross-shire IV118YJ,
Scotland (e-mail: email@example.com).
Generalized Electronic Interviewing System
(GEIS): A program and scripting method for
conducting interviews in multiple modes
University of Aberdeen, Aberdeen, Scotland
University of Newcastle, Newcastle, New South Wales, Australia
A program called the Generalized Electronic Interviewing System (GEIS) was developed for con-
ducting interviews, using computer-assisted telephone interview (CATI) and interactive voice response
(IVR) modes without the need for a programmed interface. GEIS questionnaires were prepared using
a common script syntax in all supported modes. Scripted development allowed for rapid interview de-
velopment without the need for programming. A GEIS script specified the following: question texts, in-
cluding variable texts; answer option texts; numeric codes for answers; range check information; log-
ical question-branching information; interview status information; do-loop information; and IVR
information, such as key codes and voice messages. GEIS thoroughly checked scripts for logical or syn-
tactical errors. GEIS required SAS Version8.0, and survey data were accumulated within SAS data sets.
An application of GEIS to conduct a survey involving CATI, IVR, and a combined hybrid method is de-
scribed. The CATI results deviated in the direction expected for sensitive questions, whereas IVR ob-
tained a small sample size, rendering the results unreliable. However, the hybrid method was found to
provide more accurate telephone survey data on alcohol consumption than did CATI alone. The program
may be downloaded from the Psychonomic Society Web archive at www.psychonomic.org/archive/.
GENERALIZED ELECTRONIC INTERVIEWING SYSTEM (GEIS)785
As a first step, a program was written, the Generalized
Electronic Interviewing System (GEIS), to create and
run electronic interviews without the need for program-
ming that could introduce new errors with each survey.
Instead, it uses a flexible and open-scripting method.
Open source is used to encourage the program’s further
development or to allow it to be adapted to local needs.
GEIS allows a single script format to be used in multiple
modes without the need for programming, resulting in
rapid survey development.
Currently, GEIS supports the CATI and IVR modes.
In CATI surveys, a computer is used to assist the tele-
phone interviewer by ordering and presenting questions
to be asked and then recording the responses (Nicholls,
1988). In IVR, the human speaker is replaced by a high-
quality recorded interactive script to which the respon-
dent provides answers by pressing the keys of a touch
telephone (touchphone). It differs from a CATI by lack-
ing an interviewer to read questions and enter the an-
swers into the computer. Many attributes of CATI are
shared by IVR, including the following listed by Nicholls:
automatic logical skipping or branching based on answers
to earlier questions; randomized option and question
order; interviews that can be interrupted and resumed at a
later time; single-choice as well as open-ended responses
to questions; validation of responses as they are entered;
provision of feedback on inappropriate responses; call
scheduling; and automatic interview and recording keep-
ing. In addition, IVR has the potential for obtaining a re-
duced response bias when used to ask sensitive questions
(Corkrey & Parkinson, 2002b).
GEIS also provides an efficient means of combining
modes in ways that would otherwise be difficult to achieve,
due to the programming complexity involved. It is pos-
sible to combine CATI and IVR so that the two modes
are used to conduct different parts of an interview. This
can allow the more sensitive questions to be asked by the
more anonymous mode. GEIS has some support for touch-
screen interviews, but only CATI, IVR, and their combi-
nations are discussed in this article.
An example is given in this article that illustrates the
use of CATI, IVR, and a combination of the two. The re-
sults are compared with those of an anonymous paper
The aims of this article are to describe (1) the use of
GEIS to create an interview, (2) the implementation of
GEIS, (3) the storage of data within GEIS, (4) GEIS
scripts, and (5) an application of GEIS.
Using GEIS to Create an Interview
The overall procedure for developing an interview in
GEIS is shown in Figure 1. An interview script was pre-
pared, using a text editor, and was imported into GEIS.
Errors in syntax were reported by GEIS at this stage.
These were corrected, and the script import attempt was
repeated until no errors occurred. In the next stage, termed
compilation, GEIS conducted detailed checks to ensure
that all the script items were validly defined, interview
control information existed, it was possible to jump from
each item to another, and every item could be reached
from an earlier one. The checks performed were very de-
tailed, so that most scripts that passed compilation ran
reliably on the first attempt, resulting in a very rapid
The script was then piloted by the survey designer and
volunteers to find any errors not detected by GEIS, refine
the wording of questions, and train interviewers. Once
script piloting had been completed, the project data sets
were uploaded to a share server (SAS Institute Inc., 1991),
described below. The share server allowed respondent
records to be individually accessed by CATI interviewers
or an IVR system. A typical hardware arrangement is il-
lustrated in Figure 2.
Figure 1. The procedure for developing a script within GEIS.
786CORKREY AND PARKINSON
Implementation of GEIS
Running GEIS required SAS software (SAS Institute
Inc., 1999) and Visual Voice Pro Version 5.0 software
(Artisoft Inc., 1998), running within Microsoft Windows.
It is expected that GEIS should be easily ported to SAS
running within other operating systems after rewriting
the graphical interfaces, but with minimal code changes.
GEIS is available for SAS Version 8.0 and is expected to
run with minimal changes in later versions.
Due to the portability of the SAS environment, the
program should also run with minor modifications on
non-Windows platforms. The portability of the IVR func-
tionality will depend on support within the proposed
platform. The use of different voice cards may also re-
quire code modification, although we have successfully
tried two types of Dialogic voice cards. However, the
high cost of IVR hardware prevents us from testing it
more widely. However, by releasing the program as open
source, we hope that others will adapt the program to a
wider range of hardware. GEIS may also be ported to
other non-SAS environments, with appropriate rewriting
of code and graphical interfaces.
The GEIS Program Windows
GEIS consisted of a hierarchical series of windows ac-
cessible from a control panel (Figure 3) that allowed a
variety of functions: script importing and editing, compi-
lation, interview piloting, system reports, system main-
tenance, and data set finalization. The more important
of these functions are described below.
Script importing and editing. Interview scripts were
stored in text files, using any text editor or GEIS. They
were then imported into GEIS. Scripts could contain
links to nested subscripts, typically for the inclusion of
standard question modules. A window (Figure 4) dis-
played the results of the script import process.
A phrases editor utility was available within GEIS for
editing, playing, and recording IVR messages. The edi-
tor could play sound files but could not edit them. The
editor displayed the text for each question to allow a
recording to be made and edited with a suitable external
program. GEIS does not provide a facility to edit sound
files directly, since this is done better by more special-
ized programs. Once a recording had been made, the ed-
itor was used to assign the recording filename to the
script item and assign a keyword to the recording. The
keywords were used within the script to specify which
recordings to play.
Script compiling. Compilation consisted of creating
survey data sets and extensively checking the script for
logical errors. The GEIS compiler wrote error, warning,
and information messages to the GEIS internal log. After
each compilation, the GEIS log was examined, and if er-
rors were found, the script was modified and recompiled.
Interview piloting. The interviewing system could be
run from the control panel to conduct pilot tests of scripts.
In CATI surveys, the interviewing system consisted of
windows for log-in, respondent selection, and interview-
ing. The log-in window was used by interviewers to log
into GEIS. In the respondent selection window, respon-
dents appeared in a pull-down list, which also allowed
for searching by particular name or telephone number. The
respondent interviewing window was used in both CATI
and IVR (Figure 5). In order to minimize interviewer
Figure 2. Typical GEIS hardware arrangements.
GENERALIZED ELECTRONIC INTERVIEWING SYSTEM (GEIS)787
training and interview variation in CATI, the design of
the interviewing window remained constant between
projects. For example, the data entry controls remained
in the same location on the screen for each question and
In the respondent-interviewing window, the “Next”
button caused GEIS to display the next appropriate ques-
tion, and the “Back” button caused GEIS to redisplay the
question last asked. In the IVR mode, movement back
and forward through the script was controlled by the re-
spondent’s pressing keys on his or her touchphone. The
* key returned to the previous question, and the # key
moved ahead to the next question or repeated the current
GEIS never displayed the next question until the current
question had been answered but did allow the previous
System status informationIVR Line
Data set finalization
Figure 3. The GEIS control panel.
Figure 4. The GEIS script import results window. Errors and warnings were displayed in
differently colored texts. The figure shows the first screen of the results of importing a script.
788CORKREY AND PARKINSON
question to be redisplayed so that the previously entered
answers might be corrected. In this way, interviewers
might return as far back as the beginning of the inter-
view. This was also possible in the IVR mode.
Other functions. GEIS produced reports to monitor
data collection and interviewer performance. Once data
were accumulated, they could be immediately displayed
or analyzed using standard SAS programs. Respondent
contact and interview control information could be edited,
but not respondent answers. A backup facility allowed
all project files to be saved together to another location.
Implementing IVR Within GEIS
To introduce IVR functions, additional hardware con-
sisting of a voice card was required. The card allowed
GEIS to initiate or receive calls, play recorded voice
messages stored in files, record messages spoken by re-
spondents, and respond to touchphone keypresses by the
respondent. The voice recordings were stored in files
that were specified in the script by the use of keywords.
When GEIS initiated a call to a household respondent,
it needed to distinguish a person from an answering ma-
chine so it could respond correctly, using either acoustic
analysis or salutation length determination. In acoustic
analysis, the voice card used the quality of the sound to
determine whether the line was answered by an answer-
ing machine. In the salutation length determination, the
voice card monitored how long the respondent spoke
when answering a call. For example, “hello” is briefer
than “hello, we’re not in at present.” The first case is
much shorter and would be assumed to be spoken by a
person, whereas the longer second case would be assumed
to be a recording on an answering machine. Since neither
method was perfect, scripts had to be written to allow for
the possibility of misidentification. These methods may
improve as voice card technology develops.
Each survey might require a different method of se-
lecting respondents for interview. To allow for this, GEIS
used a series of variables, shown in Table 1, that com-
bined to control how respondents were selected for an
interview. Only those respondents for whom these vari-
ables contained appropriate values appeared in the CATI
interviewer’s pull-down list, so that those who had com-
pleted an interview were not recontacted, respondents
who had arranged to complete the interview at a specific
date and time would be called then (and not before or
after), numbers that were not answered were called back
later at intervals until contact was made, some numbers
would not be called if a precontact letter was to arrive first,
respondents known to be ineligible would not be called,
and respondents who had refused would not be called back.
The IVR system used an analogous method to select the
respondents. Random digit dialing (Waksberg, 1978) is
not currently implemented.
The STATUS variable stored the status of interviews
as they progressed through contact attempts to interview
finalization. The STATUS variable used a two-letter cod-
ing system, shown in Table 2. The code was initially set
to code NA (no attempt) and then typically progressed
through various codes, as is shown in Table 3. The code
could not be changed from a higher degree of comple-
tion to a lower one; for example, it could not be changed
from PQ (partly completed) to NA. Response rate calcu-
lations (American Association for Public Opinion Re-
search, 2000) were done by calculating the proportions
of various status codes (Corkrey & Parkinson, 2002a).
An interrupted interview was saved with STATUS
code PQ. These interviews were automatically resumed
from the point left off when recontacted. When a fully
Module/submoduleRespondent ID, name, telephoneItem name
Figure5. The GEIS interviewing window showing a question with four possible answers. The question was gen-
erated by a CHCE script item.
GENERALIZED ELECTRONIC INTERVIEWING SYSTEM (GEIS)789
completed interview ended, the status was set to the CQ
code (completed questionnaire). However, if after having
reached the end of an interview, the interviewer returned
to an earlier item and changed an answer, GEIS would
automatically reset the status back to PQ.
Data Quality Considerations
GEIS reduces inconsistencies and errors as a result of
Range limit checks. Many questions in scripts could
require the entry of numeric data, such as a date of birth.
In GEIS, numeric quantities could be entered as integers,
numbers with decimals, dates, and times. Absolute limit
checks and reasonableness limit checks consisted of a
lower limit, an upper limit, or both. Numbers outside ab-
solute limits could not be entered, whereas numbers out-
side the reasonableness limits had to be confirmed before
being accepted. Limit checks were set within individual
Item nonresponse recording. GEIS would not dis-
play the next question until the current question had been
answered. This meant that answers to individual ques-
tions could not be omitted. However a respondent’s re-
fusal to answer a particular question could be recorded
using a SAS special missing value: .R (SAS Institute
Inc., 1990). The .R values were treated by default as
missing values within ordinary SAS programs but could
also be handled within GEIS scripts as any other value.
Item nonresponse rates could be calculated as the pro-
portion of groups of items with .R answers. If needed,
other code values could be adopted for specific answer
Script logic checks. After a script was imported, GEIS
compiled it into a format that it could use to generate the
CATI or IVR interface. This process involved creating
data sets and catalogues and extensively checking the
script for errors. Compiler error and warning messages
were written to the interviewing log.
Workstation independence. Each CATI workstation
stored all data locally until interview termination, when
the data were uploaded to the share server. This allowed
recovery following power failure or network interruption.
Programmatic constancy. Since no programming
was required, any errors could be reliably ascribed to
scripting errors. This particular aspect partly explained
the very rapid interview development possible with GEIS
GNU General Public License (GPL). To further im-
prove the software quality, GEIS has been released under
a GPL. Other users may correct bugs, extend it, or adapt
it to local needs.
IVR Call Scheduling
Since the IVR system operated automatically, it used
a call-scheduling algorithm (Kulka & Weeks, 1988; Steel,
Vella, & Harrington, 1996) illustrated in Figure 6. Cases
were assigned to four categories: callbacks due, answering
machines, previously attempted noncontacts, and unat-
tempted cases. Except for callbacks, calls were made at
alternating short and long intervals. Typically, if no con-
tact was made, a number would be rung 30 min later.
Then, if no contact was made on the second attempt, it
would be rerung after 8 h or even later. If still no contact
was made, the number was rerung 30min later, and so on.
There were several GEIS data sets, shown in Table 4.
A CONFID data set was created by the user to hold the
GEIS Variables Used to Select Interviewees
This variable was set to the earliest date and time a re-
spondent should be contacted. Respondents did not ap-
pear in the CATI interviewer’s pull-down list and were
not available to the IVR system until the START date
and time had passed.
SELECTED* If the interviews for certain cases were to be prevented
indefinitely, this variable was set to zero. These respon-
dents would then not appear in the CATI interviewer’s
pull-down list and were not available to the IVR sys-
tem. As soon as the variable was reset to one, the cases
became available immediately for interviewing.
ELIGIBLE Some cases could be removed because of ineligibility
by setting this variable to any positive value. These re-
spondents would not appear in the CATI interviewer’s
pull-down list and were not available to the IVR sys-
tem until the ELIGIBLE value was reset to zero.
STATUSAs interviews were contacted or completed or cases
were eliminated from interviewing, their condition was
recorded using this variable.
CBCKTIMEIVR call to be called back to complete an interview, the
requested date and time were stored in these variables.
The IVR system then called them back at the due date
*The SELECTED and ELIGIBLE variables performed the same func-
tion of selecting or deselecting respondents for interview but were used
in different contexts. The SELECTED variable was used to select or
deselect large numbers of respondents for interview, whereas the ELI-
GIBLE variable was used to select or deselect single respondents for
interview for specific reasons. The SELECTED variable was princi-
pally set within SAS data step programs. An example was where re-
spondents in one region were to be interviewed later in the survey than
respondents in another region. The ELIGIBLE variable was principally
set from the GEIS control panel. An example was where a respondent
had refused or an information letter had been returned. In these cases,
the ELIGIBLE variable would be set to an appropriate code.
When a respondent made an appointment within an
Principal STATUS Codes
dropped partway, due to refusal
dropped before starting, due to refusal
no attempt made to contact
out of scope–ineligible
partly completed interview
790CORKREY AND PARKINSON
respondent’s details. When a script was imported, it was
saved to the SCRIPT data set. During compilation, GEIS
used information in the CONFID and SCRIPT data sets
to create the other data sets. For each item in a script,
GEIS created one or more variables in the ANSWERS
data set, usually in the same order as in the script. The
CONTROL data set contained the completion details of
the interviews. There was an ID variable that acted as an
index that linked all the data sets. The ID variable held
numeric values that were unique for each respondent. All
data sets were in SAS format.
During interviews, only a single interviewer could ac-
cess a particular respondent’s data at one time. This elim-
inated the possibility that two interviewers might make
simultaneous attempts to ring the same respondent. To
do this, when the interviewer selected a respondent, the
respondent’s ID value was used to locate the appropriate
record in the data sets, and those records were then locked,
using a share server (SAS Institute Inc., 1991), preventing
their being modified by another user or program.
Any number of CATI simultaneous interviews could
be conducted, but the voice card allowed only four at one
time. Multiple simultaneous access to the data sets was
controlled using record locking by means of a share
server. The share server was an SAS program, run on a
networked computer (see Figure 2), that allowed con-
trolled access to data during collection, which was also
useful for statistical analysis and monitoring programs.
The GEIS script provided an open method of interview
specification within multiple modes. It contained all the
information needed to define the interview, including
question types and texts, variable texts, option texts and
codes, range limit information, question-branching in-
formation, status code information, calculations, do-loop
information, and IVR information. These are specified
by means of item types, self-protection statements (SPSs),
and answer quoting.
Item types. A GEIS script consisted of a series of
items corresponding to individual questions or performed
other functions, such as sending e-mails. An example
shown in Figure 7 defines a question about the respon-
dent’s education that allows seven possible answers.
A script item’s first and second lines were used to
specify various options. In the example (Figure 7), the
item’s type is CHCE and its name is Q2. A CHCE item
type created a question with a restricted set of possible
answers. The third line was an expression called the self-
protection statement (SPS), which will be explained
later. In the example, this is Q1 NE . The next lines were
used to specify the question text. In the example this is
What is the highest level of schooling you have com-
pleted. Following this were settings specific to the item
type or interview mode. In the example, this was a list of
possible answers with numeric codes to be stored: 3 Sec-
ondary school. The touchphone keys to be pressed in
IVR mode could also be specified here. The penultimate
line was used to specify the item’s label assigned to the
variable when the answer was saved. In the example, this
is Education level. The last line was a line of asterisks
that visually divided the script items from each other.
A complete list of item types is shown in the Appendix.
GEIS automatically configured the interviewing system
according to the item type and survey mode. As an ex-
ample, a CHCE type within a CATI script caused GEIS
to display the question and a list box containing the pos-
sible answers, of which only one could be selected (e.g.,
see Figure 5). In IVR, GEIS played the recorded ques-
tions and accepted only the specified code values.
Other item types (Appendix) were selected according to
type of question to be asked or function required. Since
there were very many items types, only a few are briefly
described here. For example, a MULT type was used when
asking a respondent to select zero, one, or more possible
answers from a list of possible answers, whereas an OPEN
item type allowed the respondent to enter any text or record
a spoken message in IVR mode. Where a series of very
similar items were to be asked, the DO and ENDD types
were used to implement do-loops within a script. Any
items between the DO and the ENDD items were repli-
Example of STATUS Codes in Successive Call Attempts
1Call rang out without answering.
2Number was engaged.
3Call answered by answering machine.
4Respondent contacted and appointment
made to call back.
CQ6 Interview completed.
The Major GEIS Data Sets
CONFID This data set contained the respondent contact details, in-
cluding name, telephone number, and address.
This data set was created when the script text file was im-
ported. It contained all information needed to define the
questionnaire, such as question texts, allowable options
for closed-form questions, range limit tests for numeric
questions, and the logical relationships between all the
items in the questionnaire.
ANSWERS All answers given by respondents were stored in this data
CONTROLThis data set held the information used by GEIS to control
the interviewing process.
INTRVSThe accumulated time each interviewer spent interviewing
was stored in this data set.
ILOG All system events and errors were stored in this data set.
GENERALIZED ELECTRONIC INTERVIEWING SYSTEM (GEIS) 791
cated a fixed number of times, and the item names and
SPSs, described below, were adjusted as needed. The items
within the do-loops could then use dynamically modifiable
question texts that altered with each cycle around the loop.
A very complex script could be broken down into sub-
scripts, and these could be inserted by means of a SCRP
item. External data could be imported using the LINK item
type, either before the entire survey started or just before
an interview started. These data could be used when dy-
namically altering question text or was evaluated within
SPSs to control the logic of question flow. Lastly, a MAIL
item could be used to send an e-mail once an interview had
completed. For example, an e-mail could be used to send a
recorded spoken comment made by a respondent within an
IVR interview to a survey administrator.
The GEIS scripting method also allowed interview
modes to be combined, such as the hybrid methods that
combined CATI and IVR. This was done by simultane-
ously running two computers, one running a CATI script
and another running an IVR script, and transferring calls
between them as needed (Corkrey, 2002).
Self-protection statements. The order in which ques-
tions appeared in a script could depend on the answers
given beforehand, or they may been asked in an unvarying
question order. Also, CATI interviewers or IVR respon-
dents could also move back several questions to a previ-
Figure 6. IVR call-scheduling loop.
Figure 7. Example of a GEIS script item. This example shows a CHCE item.
792CORKREY AND PARKINSON
ously entered answer and alter it. The determination of
which question to display in each case was done by SPSs.
An SPS was so called because it determined whether a
script item with which it was associated was protected or
unprotected; if protected the item could not be displayed,
and if unprotected the item could be displayed.
An SPS was a logical statement within each script item
that could be either true or false. An SPS could make use
of an answer to any preceding question by referring to
that script item’s name or could access external data by
means of an previous LINK item. When an SPS was
false, the associated item was deemed to be protected and
could not be displayed. Conversely, if the SPS was true,
the associated item was deemed unprotected and could
be displayed. SPSs permitted the complex logic structure
of a questionnaire to be condensed to simple statements.
In the example in Figure 8, the only allowable answers
to Q1 are “male,” coded as one, and “female,” coded as
two; Q2 is the same question as that shown in Figure 7
and accepts the codes 1, 2, 3, 4, 5, 6, and .R; Q3 accepts
any numeric response; Q4 accepts “yes,” coded as one,
and “no,” coded as two; and Q5 is omitted.
The SPS for Q2 is Q1 NE ., which refers to the answer
given to question Q1. In the SPS, Q1 means the answer
given to question Q1, NE means “not equal to,” and “.”
(period) means “no answer.” The effect of the SPS is that
Q2 is unprotected and displayable only if Q1 has an an-
swer. Similarly, the SPS for Q3 is Q2 NE ., which means
that Q3 is unprotected and displayable only if Q2 has an
answer. The SPS for item Q4 is (Q1 EQ 2) AND (Q3 NE.),
in which “EQ” means “equal to” and “AND” means that
both the parenthetical expressions must be true for the
whole SPS to be true. This SPS causes the Q4 item to be
displayed only if the answer to Q1 is “female” and Q3 is
answered. The last item, Q5, may be displayed only if
item Q3 or Q4 has been answered. Overall, male re-
spondents would be asked questions Q1, Q2, Q3, and Q5,
and female respondents would be asked all five questions.
Note that the SPSs, such as those for Q4 and Q5, can refer
to items at any earlier point in the script.
The SPSs were constructed by the user to allow each
respondent a single path through the script. When the
script was compiled, GEIS automatically detected logi-
cal errors in the SPSs, such as where it was not possible
to jump forward from an item or where it was not possi-
ble to reach an item. As data were entered, GEIS auto-
matically updated and evaluated the script SPSs. GEIS
then allowed the interviewer only to move backward or
forward to the first unprotected item. In this way, the se-
quence of questions asked was determined by the SPSs
and data previously entered.
Answer quoting and calculations. Question texts
could be modified dynamically within any item during
the progress of an interview. An example would be the
question, “Is the telephone number XXXX XXXX the
correct number to ring?” This process was termed answer
quoting and usually consisted of inserting the answers to
earlier questions into the current question’s text, but data
from external sources could also be used. To quote an
answer to a previous item, the previous item’s name was
inserted in the script item’s question text and surrounded
by carets. For example, Is the telephone number ^Q4^ the
correct number to ring? where Q4 contained the tele-
phone number. Another example is the dynamic creation
of e-mail text during the interview.
Simple arithmetic operations could also be defined,
such as ^Q5-3^, which subtracted 3 from the value of Q5
and then inserted the formatted value into the question text.
For more complex calculations, a CALC item allowed any
data manipulation SAS could perform to be done during
the interview. A typical use was searching databases.
Figure 8. Example of the logical relationships between five
questions, their self-protection statements, and option-code val-
ues. NE means “not equal to,” and “.” (period) indicates a miss-
ing answer. For example, the SPS Q1 NE . indicates that Q2 may
not be displayed until Q1 has an answer.
GENERALIZED ELECTRONIC INTERVIEWING SYSTEM (GEIS)793
An Application of GEIS
As has been described elsewhere (Corkrey & Parkinson,
2002a), GEIS was used to conduct an Australia-wide
telephone survey of households in 2000. Herein is de-
scribed a brief comparison of the results with those of an
Method. A total of 3,100 households were selected,
covering all the states and territories of Australia. Four
different telephone interview methods were used: CATI,
IVR, and two combination methods: Hybrid I, in which the
interview began with CATI and only the more sensitive
questions were asked using IVR, and Hybrid II, in which
only IVR was used for all the questions except the intro-
duction. No remuneration was offered. Simple instruc-
tion sheets showing a picture of a typical touchphone
keypad were included with letters mailed in advance.
All the computers used were Pentium II computers. A
four line Dialogic D/41H voice card was installed in one
computer to handle the IVR functions. Seven telephone
lines were used, three for the interviewers and four for
the IVR system. In the hybrid methods, interviewers
transferred calls to the IVR system after contacting and
recruiting respondents. Voice recordings were made in
16-bit monaural 11-kHz format with an Optimus 33-
3104 omnidirectional microphone and Creative Sound
Blaster Vibra 128 sound card. Voice recordings were by
a single female staff member selected using a voice as-
sessment method based on Oksenberg, Coleman, and
The interview addressed the respondent’s consump-
tion of alcohol and drugs and ended with demographic
questions. The scripts can be downloaded from the
Psychonomic Society’s archival depository. Answers to
open-ended questions were entered verbatim by CATI
interviewers, whereas IVR respondents could record
short spoken sentences as their responses. For numeric
answers, absolute and reasonable limits prevented range
errors. Invalid numeric responses triggered an appropri-
ate message or display. In all the interview methods, re-
spondents could refuse to answer a particular item, and
if they wished, they could return to earlier questions and
modify their answers.
To provide a comparison, the National Drug Strategy
Household Survey (NDSHS; Australian Institute of Health
and Welfare, 1999) was used. This was a biennial house-
hold survey of alcohol and drug use that used a multistage
stratified sample design and face-to-face interviews col-
lecting a total of 10,030 interviews. The more sensitive
questions were asked using confidential self-administered
questionnaires, which were sealed in envelopes by the
respondents prior to handing them to the interviewer.
Drinking status obtained by each method was com-
pared with the NDSHS (Adhikari & Summerhill, 2000)
results after the data were weighted by age and sex ac-
cording to the ABS Census data (Australian Bureau of
Results. The contact rates (84%–86%) of all the meth-
ods and the response rates (56%–61%) for CATI, HybridI,
and Hybrid II did not differ significantly, but IVR ob-
tained a significantly lower response rate than did CATI
(12% vs. 61%; p ? .001).
Since the distributions of drinking status did not dif-
fer between Hybrid I and Hybrid II for males [χ2(3) ?
3.0, p ? .40; n ? 200] or females [χ2(3) ? 2.6, p ? .45;
n ?324], the data from the two methods were combined.
As is shown in Table 5, the hybrid and the IVR methods
did not differ significantly from the NDSHS results with
respect to drinking status. However, the CATI method
differed significantly from the NDSHS for both males
and females. CATI female respondents underreported
being ex-drinkers and overreported never having drank,
whereas male respondents overreported being regular
Discussion. All the methods contacted similar pro-
portions of their respective samples, but the IVR method
had fewer respondents. The combined hybrid method re-
sults agreed with the NDSHS, whereas CATI deviated in
the direction expected for sensitive questions. Due to a
small sample size, the results for the IVR method were
considered unreliable. By assuming that the NDSHS was
a gold standard, the hybrid methods provided more ac-
curate telephone survey data on alcohol consumption
than did CATI alone.
GEIS provides an open and flexible method for script-
ing CATI and IVR interviews without the need for pro-
gramming, resulting in rapid interview development, a
controlled interviewing environment, and built-in data
Drinking Status by Method for Males and Females, Compared
With the NDSHS Results
CATIFemale (n ? 233)Regular
Male (n ? 133) Regular
Hybrid‡Female (n ? 301) Regular
Male (n ? 186)Regular
IVRFemale (n ? 53)Regular
Male (n ? 24)Regular
*The data were weighted by age and sex according to the ABS Census
data (Australian Bureau of Statistics, 1996).
†Goodness-of-fit p val-
‡Combined Hybrid I and Hybrid II methods.
794CORKREY AND PARKINSON
quality checks. It is suggested that GEIS represents a stan-
dard means of interview specification for CATI and IVR.
Further development is needed to support additional
modes, an open data storage format (e.g., XML; Archard,
Vaysseix, & Barillot, 2001), and user-friendly front-ends
for script generation. We also see no hindrance to includ-
ing support for Web-based and e-mail surveys, which may
then be combined with the CATI and IVR modes. This
may assist in overcoming the restrictions currently extant
in Web-based and e-mail surveys, such as poorly defined
frames and variable response rates (Schaefer & Dillman,
1998; Sheehan & Hoy, 1999; Smith, 1997), and ensuring
that sensitive questions are asked using the more anony-
mous modes. It has been shown that GEIS may be used to
reliably conduct CATI, IVR, or combined mode surveys.
Adhikari, P., & Summerhill, A. (2000). 1998 National Drug Strategy:
Household survey. Detailed findings (Drug Statistics Series No. 6,
AIHW catalogue No. PHE 27). Canberra: Australian Institute of
Health & Welfare.
Alemagno, S. A., Cochran, D., Feucht, T. E., Stephens, R. C., Butts,
J. M., & Wolfe, S. A. (1996). Assessing substance abuse treatment
needs among the homeless: A telephone-based interactive voice re-
sponse system. American Journal of Public Health, 86, 1626-1628.
American Association for Public Opinion Research (2000). Stan-
dard definitions: Final dispositions of case codes and outcome rates
for surveys. Lenexa, KS: Author.
Archard, F., Vaysseix, G., & Barillot, E. (2001). XML, bioinformatics
and data integration. Bioinformatics Review, 17, 115-125.
Artisoft Inc. (1998). Visual Voice Pro(Version 5.0) [Computer software].
Australian Bureau of Statistics (1996). 1996 Census of population
and housing: Basic community profiles. In AusStats [electronic re-
source]. Available at http://www.abs.gov.au/ausstats. Canberra: Author.
Australian Institute of Health and Welfare (1999). National
drug strategy: Household survey. Technical Report 1998. Canberra:
Australian Institute of Health & Welfare, Department of Health &
Cannell, C. F., & Fowler, F. J. (1963). Comparison of a self-
enumerative procedure and a personal interview: A validity study.
Public Opinion Quarterly, 27, 250-264.
Corkrey, R. (2002). Exploring the use of interactive voice response as a
population health tool. Ph.D. thesis, University of Newcastle. Avail-
able at http://www.newcastle.edu.au/services/library/adt/index.html.
Corkrey, R., & Parkinson, L. (2002a). A comparison of four computer-
based telephone interviewing methods: Getting answers to sensitive
questions. Behavior Research Methods, Instruments, & Computers,
Corkrey, R., & Parkinson, L. (2002b). Interactive voice response: Re-
view of studies 1989–2000. Behavior Research Methods, Instru-
ments, & Computers, 34, 342-353.
Couper, M. P., Traugott, M. W., & Lamias, M. J. (2001). Web survey
design and administration. Public Opinion Quarterly, 65, 230-253.
da-Silva, C. Q., Rodrigues, J., Leite, J. G., & Milan, L. A. (2003).
Bayesian estimation of the size of a closed population using photo-id
with part of the population uncatchable. Communications in Statis-
tics, 32, 677-696.
Hansen, M. S., & Dørup, J. (2001). Wireless access to a pharmaceuti-
cal database: A demonstrator for data driven Wireless Application
Protocol (WAP) applications in medical information processing [On
line]. Journal of Medical Internet Research, 3, e4.
Kissinger, P., Rice, J., Farley, T., Trim, S., Jewitt, K., Margavio, V.,
& Martin, D. H. (1999). Application of computer-assisted interviews
to sexual behavior research. American Journal of Epidemiology, 149,
Kulka, R. A., & Weeks, M. F. (1988). Towards the development of
optimal calling protocols for telephone surveys: A conditional prob-
abilities approach. Journal of Official Statistics, 4, 319-332.
Nicholls, W. L., II (1988). Computer-assisted telephone interviewing:
A general introduction. In R. M. Groves, P. P. Biemer, L. E. Lyberg,
J. T. Massey, W. L. Nicholls, II, & J. Waksberg (Eds.), Telephone sur-
vey methodology (pp. 377-385). New York: Wiley.
Oksenberg, L., Coleman, L., & Cannell, C. F. (1986). Interviewers’
voices and refusal rates in telephone surveys. Public Opinion Quar-
terly, 50, 97-111.
SAS Institute Inc. (1990). SAS Language: Reference, Version 6 (1st
ed.). Cary, NC: Author.
SAS Institute Inc. (1991). SAS/SHARE Software: Usage and Refer-
ence, Version 6 (1st ed.). Cary, NC: Author.
SAS Institute Inc. (1999). SAS/STAT User’s Guide, Version 6(4th ed.,
Vol. 1 and 2). Cary, NC: Author.
Schaefer, D. R., & Dillman, D. A. (1998). Development of a standard
e-mail methodology. Results of an experiment. Public Opinion Quar-
terly, 62, 378-397.
Sheehan, K. B., & Hoy, M. G. (1999). Using e-mail to survey internet
users in the United States: Methodology and assessment. Journal
of Computer-Mediated Communication [On line], 4. Available at
Smith, C. B. (1997). Casting the net: Surveying an internet population.
Journal of Computer-Mediated Communication [On line], 3. Avail-
able at http://www.ascusc.org/jcmc.
Steel, D., Vella, J., & Harrington, P. (1996). Quality issues in tele-
phone surveys: Coverage, non-response and quota sampling. Aus-
tralian Journal of Statistics, 38, 15-34.
Waksberg, J. (1978). Sampling methods for random digit dialing. Jour-
nal of the American Statistical Association, 73, 40-46.
The following materials associated with this article are retrievable
from the the Psychonomic Society’s Norms, Stimuli, and Data archive
Web archive, http://www.psychonomic.org/archive.
To access the above files or links, please visit http://www.psychonomic.
org/archive/ and search for this article using the journal (Behavior Re-
search Methods, Instruments, & Computers), the first author’s name
(Corkrey) and the publication year (2004).
DESCRIPTION: A directory containing the main program executables
and syntax file (geissynx.txt).
DESCRIPTION: A directory containing various small script examples.
DESCRIPTION: A directory containing a complete CATI survey exam-
ple and script (geisdemo.txt).
DIRECTORY: geis\doc\server\sas share Server.sas.
DESCRIPTION: Contains an example of a program to run a share server.
DESCRIPTION: Contains the GEIS manual.
DESCRIPTION: A directory containing SAS data sets to hold informa-
tion common to various survey projects.
DESCRIPTION: A directory containing SAS programs used in setting
up interviewing workstations.
DESCRIPTION: Contains the GNU General Public License that must
accompany all copies of the program.
DESCRIPTION: Contains a general introductory note.
DESCRIPTION: Contains a demonstration program to run after the in-
stallation is complete.
AUTHOR’S E-MAIL ADDRESS: firstname.lastname@example.org.
GENERALIZED ELECTRONIC INTERVIEWING SYSTEM (GEIS)795
GEIS Script Item Types (Functions Were Identical for CATI and IVR Scripts Except Where Indicated Otherwise)
CALCCALC inserted a calculation into the script that was
executed when the item became active. The calcula-
tion might involve the value of any previous answer
or imported values. They might only be simple ex-
pressions, such as Q2?3, but could also be very
CALL When a CALL item became active in an interview,
the telephone number of the respondent stored in the
variable STDPHONE was called.
CBDTThis item stored the date that the respondent should
be called back.
CBTM This item stored the time that the respondent should
be called back.
CHCE This item was used to ask a question that had only a
limited set of possible answers, such as “yes” and
“no.” In CATI mode, GEIS displayed a list box with
between 1 and 50 text options, one of which might be
selected by the interviewer. In IVR mode, GEIS al-
lowed the respondent to choose one option by press-
ing one of the keys 1, 2, . . . , 9 on the touchphone.
DOThis item started a do-loop. A do-loop might contain
a series of other items that were executed multiple
times. For example, the following questions could be
replaced by a single item (not shown) within a do-
“Has your oldest child been immunized?”
“Has your second oldest child been immunized?”
“Has your third oldest child been immunized?”
ENDDThis item ended a do-loop.
HUPIn CATI mode or IVR mode, this item hung up a tele-
phone call and, optionally, returned the call to an-
INFOIn CATI mode, this item displayed up to 12 lines of text
on the screen. Additional lines could be scrolled into
view. It was used to give instructions to the interviewer
or to display text to be read out to the respondent. In
IVR mode, this item played a message. After the mes-
sage had played, GEIS immediately activated the next
item, paused briefly before moving on, paused indefi-
nitely until a key was pressed, paused until a particular
key was pressed, or paused until a certain time elapsed.
LINKThis item imported one or more variables from an-
other data set. The data were imported during com-
pilation but could also be updated immediately be-
fore an interview.
LISTThis item was identical to a CHCE item, except that
the number of options that could be selected was un-
limited. The options had to be specified in an exter-
nal data set. A typical question was
“In which country were you born?”
for which there could be very many possible answers.
This item was not implemented in IVR mode.
LVLCThis item counted how many of a range of CHCE or
MULT items in the script had had a specified option
selected. For example, it may be used to check
whether all of a set of CHCE questions were an-
swered with “yes.”
MAILThis item sent an e-mail after the interview was com-
pleted. The address of the recipient, cc address, sub-
ject, and attachment, were specified in other vari-
This item was used to ask a question that could have
zero, one, or more possible answers. In CATI mode,
GEIS displayed a list box with between 1 and 50 text
options, 1 or more of which could be selected by the
interviewer. An example of a typical question is
“Which of the following diseases have you had:
This item was not implemented in IVR mode.
If this item was activated during an interview, it ap-
pended a new respondent record to the main data
This item was used to link together logic paths in a
script. It enabled scripts to be simplified by breaking
up lengthy SPSs into several shorter ones that were
shared between several NULL items.
The NUM item was used to ask a question that re-
quired a numeric answer. The answer could be any
valid SAS numeric value. Numbers (e.g., 1, 2, 3,
?7.1, 0.03), dates (e.g., 23jan1990, 230199, OCT3),
and times (e.g., 12:40PM, 17:00, or 9:00:40), could
be entered. Upper and lower reasonableness and ab-
solute limits could be specified. If the interviewer en-
tered a value outside the reasonableness limits, GEIS
displayed a check box that had to be ticked before an-
other item would be displayed. If the interviewer en-
tered a value outside the absolute limits, GEIS dis-
played an error message and refused to accept the
answer. With IVR mode, dates and times had to be
entered using digits only. For example, the date
23Jan1950 was entered as 23011950. Upper and
lower reasonableness limits could be specified within
the IVR mode as well. If the respondent entered a
value outside the reasonableness limits, GEIS played
a message asking the respondent to confirm the value
by pressing the hash key before the next item would
be played. If the respondent entered a value outside
the absolute limits, GEIS played an error message,
and the question was repeated.
NUMM This item was similar to the NUM field but allowed
up to five entry fields. An algebraic expression was
used to set the value of a summary variable. A con-
straint expression ensured the field values were con-
sistent. This item was not implemented in IVR mode.
OPENThis item was used to ask a question that required an
open-ended answer. In CATI mode, the interviewer
typed the verbatim answer into a text box. In IVR
mode, the respondent was asked to speak their an-
swer, which was then recorded by GEIS.
RST If this item became active, the interview was reset,
all data were erased, and the first item then became
SCALThis item was used to define one or more numeric or
character values. Although a LINK item could be
796CORKREY AND PARKINSON
used for the same function, the SCAL item value di-
rectly appeared in the script. It was also used in com-
bination with do-loops.
This item was used to import another script fragment,
called a subscript, into the current script. This al-
lowed a script to be broken up into a series of smaller
pieces or a standard question domain to be imported.
This item appeared at the beginning of the script and
did not form part of the script logic. It allowed a mes-
sage to be defined for a given STATUS code. When
an interview was begun with a matching STATUS
code, the message in the SMSG item was displayed
to the interviewer. In IVR mode, a specific voice
recording was played instead.
This item was used to set the STATUS variable code
value on exit from an interview. There had to be at
least one STAT item in a script to set the STATUS
variable code value to CQ, indicating a completed
questionnaire. Usually, there would also be other
STAT items for codes, such as CB, RT, and so on.
TABLThis item displayed a table of two or three columns.
This allowed entry of either a column of numbers,
or a series of short open-ended answers. In the table,
the first column in each row contained a label.
The second column was for numeric entry, and the
third was for character entry. Buttons could be dis-
played instead of specific rows. This item type was
used for complex questions that required multiple
answers. This item was not implemented in IVR
When this item became active, it stored the duration
since the interview began. It did this only once, so
that if the item became active at another time the du-
ration was not changed.
This item specified the title of the project and also
set global options.
This item transferred a call to another number. It was
used when the IVR and CATI modes were combined,
such as in the hybrid method as described elsewhere
(Corkrey & Parkinson, 2002a).
(Manuscript received January 7, 2003;
revision accepted for publication June 4, 2004.)