American Journal of Medical Genetics (Neuropsychiatric Genetics) 81:248–256 (1998)
Integrating Clinical and Laboratory Data in
Genetic Studies of Complex Phenotypes:
A Network-Based Data Management System
Francis J. McMahon,1* C.J.M. Thomas,1 Rebecca J. Koskela,2 Theresa S. Breschel,1
Tyler C. Hightower,1 Nichole Rohrer,1 Christine Savino,1 Melvin G. McInnis,1 Sylvia G. Simpson,1
and J. Raymond DePaulo1
1
Department of Psychiatry and Behavioral Sciences, The Johns Hopkins University School of Medicine,
Baltimore, Maryland
2
Department of Genetics, Stanford University, Stanford, California
The identification of genes underlying a
complex phenotype can be a massive under-
taking, and may require a much larger
sample size than thought previously. The in-
tegration of such large volumes of clinical
and laboratory data has become a major
challenge. In this paper we describe a net-
work-based data management system de-
signed to address this challenge. Our system
offers several advantages. Since the system
uses commercial software, it obviates the
acquisition, installation, and debugging of
privately-available software, and is fully
compatible with Windows and other com-
mercial software. The system uses rela-
tional database architecture, which offers
exceptional flexibility, facilitates complex
data queries, and expedites extensive data
quality control. The system is particularly
designed to integrate clinical and labora-
tory data efficiently, producing summary
reports, pedigrees, and exported files con-
taining both phenotype and genotype data
in a virtually unlimited range of formats. We
describe a comprehensive system that man-
ages clinical, DNA, cell line, and genotype
data, but since the system is modular, re-
searchers can set up only those elements
which they need immediately, expanding
Contract grant sponsor: Charles A. Dana Foundation; Contract
grant sponsor: NIMH; Contract grant sponsor: National Alliance
for Research on Schizophrenia and Depression; Contract grant
sponsor: Johns Hopkins University Affective Disorders Fund;
Contract grant sponsor: Johns Hopkins University George
Browne Laboratory Fund.
*Correspondence to: Francis J. McMahon, M.D., Department of
Psychiatry and Behavioral Sciences, The Johns Hopkins Univer-
sity School of Medicine, Meyer 3-181, 600 N. Wolfe Street, Balti-
more, MD 21287-7381. E-mail: fmcm@welchlink.wech.jhu.edu
Received 10 September 1997; Revised 13 January 1998
© 1998 Wiley-Liss, Inc.
later as needed. Am. J. Med. Genet. (Neuro-
psychiatr. Genet.) 81:248–256, 1998.
© 1998 Wiley-Liss, Inc.
KEY WORDS: relational database; linkage;
data integrity; modular
INTRODUCTION
The identification of genes underlying a complex
phenotype can be a massive undertaking. Data man-
agement for such studies must cope with large sample
sizes, multiple data storage sites, and some data that
change over time. The integration of such large vol-
umes of clinical and laboratory data has become a ma-
jor challenge in genetic studies of complex phenotypes.
Gene identification in complex phenotypes may re-
quire a much larger sample size than thought previ-
ously. Large sample sizes may be needed for the initial
detection of linkage, and even larger sample sizes for
replication of linkage findings [Suarez et al., 1995].
Narrowing the linkage finding to a physically-
mappable chromosomal location may require more
than 2,000 affected sib-pairs [Kruglyak and Lander,
1995]. Furthermore, each affected subject is typically
associated with a large amount of clinical data and the
more than 300 genotypes that are generated in ge-
nome-wide linkage searches.
Each type of primary data has special storage re-
quirements. Clinical assessments are typically col-
lected on handwritten forms and are often supported
by copies of medical records and other documentary
evidence in various nonstandard formats. Blood
samples and cell lines must be tracked from subject to
freezer. Genotype data may exist in the form of auto-
radiographs or the specialized data files produced by
automated genotyping systems.
The data generated in genetic studies are not static,
but change over time. Previously unavailable relatives
may volunteer for the study or previously studied sub-
jects may die. Clinical data may change after longitu-

dinal follow-up. DNA sample supplies dwindle and
must be replaced. Genotype data may require correc-
tion if they fail to segregate or when false paternity or
sample mix-ups are detected. Thus, regular archiving
and updating of data are required to forestall degen-
eration of the database over time.
In this paper we describe a network-based data man-
agement system designed to address the special re-
quirements of family studies of complex phenotypes.
The system is expandable, modular, and easily adapted
to a wide variety of studies. The system uses existing
relational database, pedigree, and networking software
and standard PC hardware. The efficient integration of
clinical and laboratory data in the form of output files,
summary reports, and pedigrees is a major feature.
MATERIALS AND METHODS
User Input
Our first task in designing a data management sys-
tem focused on the ‘‘users,’’ i.e., the clinicians, research
assistants, and laboratory technicians who would be
using the system every day. We involved the users in
deciding which data elements needed to be considered,
the naming of fields and tables, and the design of data
entry forms. After each module of the system was made
available, users were polled in a series of feedback
meetings about whether that module was accomplish-
ing the desired tasks in an efficient and user-friendly
fashion. If not, that module was redesigned to better
fulfill user needs. After the system was entirely in
place, further expansions and modifications were con-
sidered as needed.
Hardware Requirements
The hardware requirements for this system depend
on the size of the sample to be studied and the modules
used. At least one computer is required to house the
main database, and (ideally) at least one computer is
devoted to each module, located in a spot where the
users will have ready and continuous access. As the
main computer we use a Pentium 75-MHz machine
(Compaq Computer Corp., Houston, TX) with 16 MB of
RAM, a 2-gigabyte hard drive, and a Colorado Jumbo
1400 tape drive (Hewlett Packard, Palo Alto, CA).
These should be viewed as reasonable minimum re-
quirements, since this computer stores all the data and
acts as a server for the entire system. For each module
we use at least one 486/66-MHz or Pentium 75-MHz
computer with at least 16 MB RAM and a 500-MB hard
drive. For the genotype module, a Macintosh computer
(Apple Computer, Cupertino, CA) is also needed if
automated genotypes will be processed using the
GeneScan 2.1fc2 and Genotyper 1.1 programs (Applied
Biosystems, Foster City, CA).
If additional computers are being used, then a net-
work must also be in place and each networked com-
puter needs a network card. The network system we
use is a departmental local area network (LAN), con-
necting each computer to a central hub, with struc-
tured cabling utilizing 10BaseT Ethernet. The hub also
connects the LAN to the campus-wide network using
fiber-optic cable, which provides access to the Internet.
Network-based Data Management System 249
Each computer should be connected to a printer, ei-
ther through the network or through a printer buffer.
We use two different types of printers. Our main
printer is a Hewlett Packard (HP) LaserJet 4M Plus
(Hewlett Packard, Palo Alto, CA), which is linked to the
network and is centrally located for multiple users. We
also have HP Inkjet 500-series printers attached di-
rectly to the computers that serve the DNA, cell line,
and genotype modules.
The DNA module is designed to work with a spectro-
photometer that measures DNA concentration and
quality. We use an HP Diode Array Spectrophotometer
(model 8452A) connected to an HP Vectra 486/33N
computer with 16 MB RAM. Included with the spectro-
photometer is general scanning and quantitation soft-
ware that enables the user to program desired absor-
bance wavelengths for DNA quantitation.
Software Requirements
This data management system requires two types of
software: commercial or ‘‘off the shelf ’’ programs, and
customized programs written by us expressly for use
with the database software or for software used by in-
dividual modules.
The commercial software required includes a rela-
tional database program, backup software (usually pro-
vided with the backup drive), a pedigree drawing pro-
gram, and optional network software. The relational
database software is the keystone, providing storage,
querying, and reporting capabilities. The relational da-
tabase software must also allow each module to access
data both within and between modules on different
computers. One of the most useful features of this da-
tabase is the ability to output data into a pedigree
drawing format, so the software chosen for the pedigree
drawing should be able to import files. We use Paradox
version 5.0 (Borland Intl., Scotts Valley, CA) for the
relational database, Colorado Backup version 2.80, Cy-
rillic 2.1 (Cherwell Scientific, Oxford, UK) for the pedi-
gree drawing, and Windows for Workgroups 3.11 on
the server computer. Computers used for the indi-
vidual modules use either Windows for Workgroups
3.11 or Windows NT 3.51/4.0.
The customized programs come in three types. The
first type facilitates the use of the database software.
These programs consist of data entry forms, reports,
and queries that are part of the relational database
program options; only knowledge of that software is
needed. The second type of customized program builds
on the options within the database software (for Para-
dox these programs are written in ObjectPal). For ex-
ample, we have created ‘‘smart forms’’ that aid data
entry by filling some fields with prespecified default
values, skipping inappropriate fields based on previ-
ously entered values (e.g., skipping an IF YES, SPECIFY
field when ‘‘no’’ was entered into the previous field),
and automatically calculating sums and differences.
Other forms provide a ‘‘button’’ that when ‘‘pressed’’
executes other programs, e.g., backing up the data files
or archiving old data. These custom programs, which
modify and extend features within the database soft-
ware, call for additional knowledge of that software
250 McMahon et al.
and some basic programming skills. The final type of
program is more complex. It includes a BASIC program
that converts the data output from the spectrophotom-
eter into the correct format for the database, and an
ObjectPal program that then appends the spectropho-
tometric data to the appropriate database table. An-
other example is the ObjectPal program that gathers
all the relevant data and creates an ASCII file that the
pedigree drawing program processes into a visual rep-
resentation of a pedigree with selected information dis-
played. These programs were written by the authors
(C.J.M.T. and R.J.K.) and require a more advanced
knowledge of the internal programming of the data-
base as well as programming languages such as BASIC
and ObjectPal. The original code for all our customized
programs is available upon request to the correspond-
ing author.
Fig. 1. Each module is shown by an open circle. The Master Pedigree table joins the individual modules via the subject identifiers. The Alias table
stores all alternative identifiers for each subject. Asterisk (*) indicates key field.
Notation
Throughout this manuscript, all variable fields are
indicated in SMALL CAPITALS and data tables in italics.
RESULTS
Overall Structure
The overall structure of the database is illustrated in
Figure 1. Each of the four modules is represented by a
circle. The Master Pedigree table joins all modules via
individual unique identification numbers for each sub-
ject. This table also stores pedigree structure informa-
tion, such as parent identifiers and gender. Each record
in the Master Pedigree table is joined via the SUBJECT
ID to a record in the Alias table. The Alias table stores
all alternative identifiers ever used for that subject,
 Network-based Data Management System 251

including numbers assigned to blood or DNA samples,
and numbers assigned by other studies in which the
subject may also be enrolled. So that the Master Pedi-
gree and Alias tables can be used to join any other
tables in queries, all subjects appear once and only
once in both the Master Pedigree and Alias tables. To
help ensure referential integrity, data may be entered
elsewhere in the system only for subjects with an entry
in both the Master Pedigree and Alias tables.
Clinical Modules
Structure. The clinical data module is designed to
track all the clinical findings and administrative data
for each enrolled subject and family. The module con-
sists of three sets of related tables (Fig. 2). The Family
table stores information about each family as a whole,
such as method of ascertainment, status in the study
(from ‘‘enrolled’’ to ‘‘all interviews and blood draws
complete’’), or the phenotype segregating in the family.
The Administrative tables store information about
each subject for bookkeeping purposes, such as demo-
graphics, consent forms, and subject reimbursement,
as well as each subject’s status in the study (from ‘‘en-
rolled’’ to ‘‘interview and blood draw complete’’). The
Phenotype tables store information derived from the
clinical evaluation, including symptoms and diagnosis.

Fig. 2. The clinical data module tracks all the clinical findings and administrative data on each subject and family in the study. Tables and groups
of tables are designated by rectangles, fields by ellipses attached by dotted lines. Major relationships between tables are indicated by a solid line, with
the linking field shown. One to many relationships are shown by crows’ feet. Asterisk (*) indicates key field.
252 McMahon et al.
Depending on the phenotype studied, these tables
might also store clinical laboratory data, such as the
results of glucose tolerance testing.
Data flow. When a family is ascertained, each in-
dividual who appears in the pedigree is given a unique
identifier (SUBJECT ID), under which all of that sub-
ject’s data are stored. The SUBJECT ID is placed in the
Master Pedigree and Alias tables. The family status
(‘‘enrolled’’) and the method of ascertainment are en-
tered as well.
After completion of the evaluation, the clinical find-
ings are entered into the Phenotype table. Once all
available members of the family have been interviewed
and blood has been received, the status of the family is
changed to ‘‘complete’’ in the Family table.
The administrative tables are used to process sub-
jects through all stages of the study, from ascertain-
ment through follow-up. This allows for a confirmation
that each subject has signed a consent form, received re-
imbursement, undergone clinical evaluation, and so on.
DNA Module
Structure. The DNA data module tracks the loca-
tion, quantity, quality, and current volume of each vial
of DNA for each subject. The module consists of three
related tables (Fig. 3). The DNA Sample table tracks
the date a particular vial of DNA was extracted, its
freezer box location, and the starting volume for every
DNA vial. Spectrophotometric data associated with
each DNA vial are imported into the DNA Concentra-
tion table. These data include the concentration data,
Fig. 3. The DNA data module tracks the location, quality, and current volume of each DNA vial for each subject. See Figure 2 legend for explanation
of symbols.
260/280-nm ratio and other DNA quality ratios, and
the ASCII filename of the spectrophotometer output
file. This SPECTRAL FILE FLAG allows the user to access
graphical spectrophotometric data for each vial of
DNA. The DNA Volume table records the usage history
of each vial of DNA. The Archive DNA Volume table
stores all the DNA sample and concentration informa-
tion as well as the usage history once a DNA vial is
emptied.
Data flow. Each time a new vial of DNA is gener-
ated, the SUBJECT ID, DNA vial identifiers, and other
data are entered into the data base, using a form. Dur-
ing the data entry process, data (in ASCII format) are
imported from the spectrophotometer into the DNA da-
tabase, using a program that also calculates the DNA
concentration based on 260-nm absorbance data. Any
aliquots of DNA removed are automatically subtracted
from the original starting volume, so that there is a
continuously-updated record of the current volume and
amount of DNA for each vial and for each subject in the
study.
Once a vial of DNA becomes empty, this information
is entered in the DNA Volume table and a script is
activated that simultaneously removes all the entries
pertaining to that particular vial from the DNA Con-
centration, DNA Sample, and DNA Volume tables to
Archive DNA Volume. This table can be accessed at will
and serves an essential function by preserving all data
entered into the DNA module. This allows users to
track down key errors and account for other data dis-
crepancies that may arise.

The primary output for the DNA database is a report
listing the box location, current volume, and total
amount of DNA per vial and per subject. Other reports
can be generated that essentially function as flags. For
example, reports are generated when a particular DNA
vial is of poor quality (e.g., out-of-range 260/280-nm
ratio) or when the amount of DNA for a particular sub-
ject goes below a user-specified value, thereby alerting
the technician to begin cell culture for the extraction of
new DNA. The main output file can also be interfaced
with the cell line, clinical, and genotype databases.
Cell Line Module
Structure. The cell line module consists of three
related tables (Fig. 4). The Growth table contains data
about each growth attempt, recording the number of
attempts, quality of the growth, and reasons for any
failure. The Storage table contains the box and coordi-
nate location data for each cell line vial in the freezer,
giving an up-to-date inventory of cell lines available for
each subject studied. The Usage History table records
any additions or removals to the freezer, thus tracking
the usage of cell lines, and facilitating error checks and
audits.
Data flow. When a blood sample arrives at the
laboratory, an attempt is made to grow a cell line. The
vigor and quality of the culture and relevant dates are
recorded in the Growth table for every growth attempt.
Once a cell line is grown successfully, the storage in-
formation is entered into the Usage History table, with
a field showing that it is a new addition. These data are
automatically copied into the Storage tables. When a
Fig. 4. The cell line data module tracks the growth and storage of each vial of lymphoblastoid cells generated for each subject. See Figure 2 legend
for explanation of symbols.
Network-based Data Management System 253
cell line is removed from the freezer, this fact is also
entered into the Usage History table, with the field
showing it as a new removal. The vial is then automati-
cally deleted from the Storage table. As a result, the
Storage table always contains an accurate inventory of
the available cell lines and their locations. The Usage
History table contains a record of all additions and re-
movals, and thus acts as an archive for the Storage
table.
Reports are generated to identify subjects needing to
have a blood sample redrawn because the culture
failed, to summarize the number and locations of cell
line vials stored for each individual, and to alert labo-
ratory staff that the supply of cell line vials for an in-
dividual has gone below a user-specified value.
Genotype Module
Structure. The genotype module consists of four
related tables (Fig. 5). The Genotype table contains the
marker genotypes for each subject, in the form of arbi-
trary allele numbers. The exact allele size in base pairs
corresponding to each arbitrary allele number is re-
corded in the Allele Size table. The Reader table con-
tains the information on who read the genotypes in
each family, with MARKER ID specified. Allele Size and
Reader are linked to other tables via FAMILY ID, since
arbitrary allele numbers are assigned within each fam-
ily. The last table, Markers, contains the reference in-
formation for all markers, linking the MARKER ID to the
marker name(s), chromosome, and location (if desired,
multiple Markers tables can be used to group markers
in a convenient manner, such as by chromosome).
254 McMahon et al.
Fig. 5. The genotype data module tracks the results of the polymorphic DNA marker analyses for each subject as well as descriptive data about the
markers used and their chromosomal locations. See Figure 2 legend for explanation of symbols.
Data flow. After a family has been clinically
evaluated, the individuals with a DNA sample who are
required for linkage analysis are selected for genotyp-
ing. This is noted in the Master Pedigree table, in a field
called GENOTYPING. Another field, NEED FOR PEDIGREE,
designates the individuals selected for genotyping
along with individuals required to connect the pedigree
structure, e.g., parents of a sib-pair.
Once the genotypes for each marker are determined,
they are entered into the Genotype table. If the geno-
types were read automatically, these data are set in an
importable format by a semiautomated routine. Output
from the ABI 373 sequencer is binned using the pro-
gram Genetic Analysis System (GAS 2.0; GAS © Alan
Young, Oxford University, 1993–1995), whose text out-
put is imported into the database tables. If genotypes
are read manually, the information is entered directly
into the Genotype table. This is accomplished with a
form that requires entering MARKER ID only once per
family and simplifies data entry by allowing entry into
Genotype, Reader, and Allele Size tables all at once.
This guarantees complete data for every genotype, e.g.,
that every arbitrary allele number corresponds to an
absolute allele size value in the database.
The primary output from the genotype module is
linked with the phenotype data from the clinical mod-
ule to generate linkage files for analysis. Other outputs
can also be generated, e.g., status reports summarizing
genotype progress by individual or marker.
Pedigree Reports
The most useful report format for family studies is
often the pedigree itself. Therefore, we developed a
method for importing any data of interest from the da-
tabase into a pedigree drawing program, where the
data are displayed directly on the pedigree. This ap-
proach preserves the flexibility of the relational data-
base while displaying the data in the way that is most
intuitive for genetic researchers.
For each report format, a program collects the data of
interest from the relevant tables in the database, joins
these data with the pedigree structure information in
the Master Pedigree table, and formats the joined data
for importing into the pedigree drawing program. Re-
sidual errors in pedigree structure are easily detected
at this point, since any errors will cause the pedigree
drawing program to either reject the import file or

draw a discontinuous pedigree structure. After the
pedigree is drawn, further adjustments in formatting
(but not content) can be applied prior to printing. This
ensures that the content of the pedigree reports agrees
exactly with the data in the database on the day the
report was generated.
Several different pedigree report formats have been
developed. For example, one format (Fig. 6) displays
the latest phenotype data, DNA availability, and study
status for each subject in a family. This format is par-
ticularly useful for deciding when to send a family into
the laboratory for genotyping. Another format, used for
families that have already been genotyped, displays
the final clinical diagnosis along with genotype results
for a set of DNA markers. This format is useful for
checking the results of linkage analyses and construct-
ing haplotypes. Pedigree reports showing only struc-
ture and gender can also be generated for use in the
laboratory, where it is important to maintain blindness
to phenotype.
DISCUSSION
We describe a network-based data management sys-
tem designed to address the special problems posed by
family and genetic studies of complex phenotypes. The
system uses commercial relational database, pedigree,
and networking software, and standard PC hardware.
The efficient integration of clinical and laboratory data
is a major feature. The system is comprehensive, ex-
pandable, modular, and highly adaptable to a wide va-
riety of studies.
Our system offers several advantages for researchers
studying the genetics of complex phenotypes. Since it
uses commercial software, our system obviates the ac-
Network-based Data Management System 255
quisition, installation, and debugging of privately-
available software, and is fully compatible with Win-
dows and most other software, both private and com-
mercial. The system is based on relational database
architecture, which offers exceptional flexibility, facili-
tates complex data queries, and expedites extensive
data quality control. Data entry and retrieval forms
can be designed to facilitate these functions for users
with little training. The system is particularly de-
signed to integrate clinical and laboratory data effi-
ciently in a variety of output formats. Summary re-
ports, pedigrees, and exported files containing both
phenotype and genotype data are easily generated in a
virtually unlimited range of formats. Since the system
is modular, researchers can set up only those elements
which they need immediately, expanding later as
needed. Although our system works with PC-type ma-
chines in a Windows environment, the concepts can be
adapted to Macintosh or Unix platforms as well.
This system may not be suitable for all situations.
Much of the flexibility comes from the networking of
several computers, but networks can be unstable and
good maintenance is essential. (This issue appears to
be less problematic with newer network protocols and
operating systems such as Windows NT.) Our system is
based on a central ‘‘hub’’ computer that stores all of the
data; the system is thus disabled when the hub ma-
chine is down. This could be avoided by distributing the
database over several networked computers, but
backup procedures would then have to be implemented
for each networked computer. The powerful query
mechanisms offered by the relational database archi-
tecture may pose security problems, since identifiers
can readily be joined with other data. Like most com-
mercially available relational database software, Para-
Fig. 6. Sample pedigree reports. SADS:
Clinical interview completed; Best Est: Best es-
timate diagnosis completed; G: Selected for
genotyping; L: Needed for linkage analysis, but
not selected for genotyping; C: Cell lines avail-
able; D: ù0.15 mg of DNA available; d: <0.15 mg
DNA available. Pedigree drawn by Cyrillic 2.1.
256 McMahon et al.
dox offers a password mechanism that limits which
data a particular user can see or edit. This addresses
the problem satisfactorily for our system. Finally, as
with any relational database, the establishment and
maintenance of referential integrity are essential, usu-
ally requiring effort from trained staff.
All relational database management systems should
contain automatic procedures for ensuring referential
integrity and other types of data integrity. Our system
automatically implements four types of data integrity
checks. To prevent ‘‘orphan’’ entries that cannot be
linked to other tables in the database, a limited hier-
archy is imposed upon the database tables. Data may
be entered into the system only for subjects with en-
tries in the Alias and Master Pedigree tables, and the
corresponding rows in these tables must be deleted be-
fore entries can be deleted elsewhere in the database.
To minimize key errors, a variety of range restrictions
are imposed at the point of data entry. Any data editing
automatically generates a log entry recording the old
and new values, date and time of change, reason for the
change, and the log-in name. Finally, the hard drive of
the hub computer is automatically backed up every
evening, and the backup tape is stored off-site.
Several other data management systems have been
developed for genetic studies DOLINK [Cook et al.,
1993] prepares data output formats that are compat-
ible with many genetic analysis programs, but is not a
complete data management system. DOLINK and the
more recently introduced program Genome Topogra-
pher [Marr, 1996] complement our system, since
the relevant data can be easily exported in any text for-
mat for further manipulation by such programs. The
LABMAN/LINKMAN package of data management
programs [Adams, 1994] offers many of the same ba-
sic functions as our system, but lacks the flexibility
of our modular organization, and is currently not
fully compatible with Windows. The database system
HYPERGENE [Charru et al., 1994] is conceptually
quite similar to our system, but is designed for a Mac-
intosh platform and does not offer modules to manage
DNA or cell line samples. Another relational system,
PhenoDB [Cheung et al., 1996], was developed with the
aim of integrating population and linkage genetics. It
offers some of the same capabilities as our system on a
Unix platform, but was not designed to manage exten-
sive clinical phenotype data.
Like the acquisition and analysis of scientific data
itself, data management is a process that evolves over
the course of a study. Thus it is essential that a data
management system be able to adapt to changing
needs. We describe a network-based data management
system that is highly adaptable and efficiently inte-
grates clinical and laboratory data. While this system
or its concepts may be of value to researchers, they
should carefully consider all of the advantages and dis-
advantages of this and other systems before embarking
on a large scale study.
ACKNOWLEDGMENTS
This work was supported by grants from the Charles
A. Dana Foundation Consortium on the Genetic Basis
of Manic Depressive Illness, the National Institutes of
Mental Health, and the National Alliance for Research
on Schizophrenia and Depression, and by contributors
to the Affective Disorders Fund and the George Browne
Laboratory Fund at Johns Hopkins University. We
thank Susan Folstein and Thomas G. Marr for concep-
tual input. Scott Allan, Dean MacKinnon, and Geri
Rochino provided user feedback. Diane M. Carroll, Re-
nee Conte, Meryl Cooper, Sara Cushing, Cheryl Eckler,
Jo Ellen Green, Barbara Schweitzer, and Eva Vishio
contributed to earlier versions of the present system.
Matthew Goykers Eliot, Mike Grierson of Survey Re-
search Associates (Falls Church, VA), Phil Marcus of
Training to Go (Ellicott City, MD), and Mark Oxenham
of Cherwell Scientific (Oxford, UK) provided technical
advice and assistance.
REFERENCES
Adams P (1994): A data management system specifically designed for ge-
nome searches of complex diseases. Genet Epidemiol 11:87–98.
Charru A, Jeunemaitre X, Soubrier F, Corvol P, Chatellier G (1994): Hy-
pergene: A clinical and genetic database for genetic analysis of human
hypertension. J Hypertens 12:981–985.
Cheung K-H, Nadkarni P, Silverstein S, Kidd JR, Pakstis AJ, Miller P,
Kidd KK (1996): PhenoDB: An integrated client/server database for
linkage and population genetics. Comput Biomed Res 29;327–337.
Cook CCH, Gurling HMD, Curtis D (1993): DOLINK—A computer pro-
gram to facilitate management of genetic data and analyses. Ann Hum
Genet 57:307–310.
Kruglyak L, Lander ES (1995): High-resolution genetic mapping of com-
plex traits. Am J Hum Genet 56:1212–1223.
Marr TG (1996): Genome Topographer: A computerized system for doing
genetics, finding genes and studying their function [abstract]. Am J
Hum Genet [suppl] 59:308.
Suarez BK, Hampe CL, Van Eedewegh P (1995): Problems of replicating
linkage claims in psychiatry. In Gershon ES, Cloninger CR (eds): ‘‘Ge-
netic Approaches to Mental Disorders.’’ Washington, DC. American
Psychiatric Press, pp 23–46.