History Of AVSS.
Beginning in 1981, the Automated
Vital Statistics System
(AVSS) was envisioned to be a modular
computer system for the collection, management, and reporting
of public health paper forms, with special emphasis on vital records.
The primary goal of AVSS has been the improvement of timeliness
and accuracy of vital records by means of computer automation.
AVSS used an innovative approach that was both revolutionary
and evolutionary. It was revolutionary since it was the
first electronic birth certificate system that interactively produced
a computerized legal copy of a paper birth certificate that passed
state-mandated quality assurance edits. Information was collected
as close as possible to the source of data. Electronic data resulting
from birth registration in hospitals was automatically transmitted
to public agencies thus eliminating many of the time-consuming,
redundant, and error-prone manual processes. But AVSS was
also evolutionary since it adapted to the existing system
of vital event registration that has been in place in most states
for nearly a century. This gave rise to the world's first electronic
birth certificate in 1981 at Santa Barbara's Cottage Hospital.
The goal of AVSS was to create an interactive vital records
computer system that would:
Improve timeliness.
Emphasize accuracy.
Minimize redundant data entry.
Feedback data to providers.
Accuracy was achieved by developing and implementing in four states
(California in 1981, Massachusetts and Rhode Island in 1986, and
Connecticut in 1987) an interactive system of direct data entry
into a central computer where quality edits were performed before
the birth certificate was printed. This interactive system used
automated telecommunications with modems along with ordinary
telephone lines to achieve the goal of timeliness. This was made
possible by building a hierarchical standardized system
with data flowing automatically from the hospital to the county
health department and on to the state registrar, then eventually
to the National Center for Health Statistics and the Social Security
Administration. A report generator was incorporated to
achieve the goal of information feedback to data providers. Import-export
functions were developed to enable data sharing. All of
these features were part of a win-win approach that has
proved to be successful.
Three types of vital records were originally targeted as AVSS
modules:
Birth Certificate.
Confidential Morbidity Report.
Death Certificate.
Today's Situation.
Electronic birth certificates are automatically transmitted
daily from the hospital to the local registrar, then to the state
registrar. After data arrives at the state it is written from
the AVSS data base in batches to the Department of Health
Services network, then transmitted to the Social Security Administration
and National Center for Health Statistics. Electronic birth certificates
are automatically reallocated weekly from county of birth
occurrence to county of birth residence when they differ. The
resultant data base, containing all natality records by place
of birth occurrence and by place of mother's residence, is used
by local agencies for pubic health surveillance. Certified
birth abstracts are presently printed by AVSS in thirteen
local registration districts. Automated census tracting
and bar coding by AVSS has also improved staff efficiency
at the local level.
Confidential morbidity reports are key-entered into AVSS
to reduce the tedium of weekly infectious disease reporting and
to create a local data base for epidemiology. In addition to registering
nearly all (99+%) births in California, AVSS transmits
to the Department of Health Services electronic data on communicable
diseases from 42 counties, representing more than 90% of reported
cases. Death certificate data is also key-entered into
AVSS at the local level, but AVSS does not presently
transmit electronic death data to the state. As a uniform statewide
system, AVSS has the potential of tracking health outcomes.
Automatic linkage procedures for matching electronic birth
and death records are under development.
How Did We Get Here?
Although AVSS began at the local level, significant
funding was received by state and federal Maternal and Child Health
sources. It was developed incrementally with minimal resources
using rapid prototyping. This evolutionary approach continually
added user suggestions. User input is incorporated by means of
AVSS modification requests that are discussed by a technical
advisory group.
As stated above, AVSS is both revolutionary and evolutionary:
revolutionary, since it was the world's first electronic birth
registration system. Evolutionary, since it adapted to existing
paper forms and was modular; thus allowing it to grow flexibly
and incrementally. By using an ANSI standard computer language,
AVSS could be ported to a variety of computer platforms,
and is scaleable in size according to need. The uniformly programmed
AVSS software can be run on a notebook computer involving
a few hundred births, or on much larger scales, and is capable
of managing all US birth certificates on a PC.
In order to succeed AVSS incorporated the following features:
Edits, including range checking and cross-checks between data
fields.
User validation of unusual data values.
List processing where users easily select from many choices.
On-line help with official state instructions.
Default values set automatically.
Context sensitive logical branching to skip ahead around unnecessary
prompts.
While these were new and innovative features when they were introduced
in 1981, AVSS is first and foremost a vital records registration
system. It was designed not only to save time and effort
by producing flawless paper copies at the source of information,
but it created electronic connections between the hospital and
the local registration district and between the local registration
district and the state registrar. This electronic network resulted
not only in automated data flows, but also in more efficient interactions
between the hundreds of parties involved in the birth registration
process. It has increased efficiency and accountability by means
of improved and timely information. The features listed above
resulted in a two-thirds reduction in key-strokes to produce a
birth certificate in hospitals. Additionally, these savings were
multiplied more than two-fold by eliminating redundant data entry
in local and state health agencies. It took 15 years of persistent
effort on the part of local and state agencies in cooperation
with University of California to arrive at the present solution.
For the 550,000+ annual births, there are presently 283 hospitals
and 54 local registration district using the software in California.
Because AVSS is a multi-user system, this adds up to 500+
user workstations. These 500+ workstations require frequent and
continued technical support due to equipment malfunctions, staff
turnover, need for training, and technological change as well
as software updates. The responsibility for providing this technical
support lies principally with the local AVSS System Manager
and to a lesser extent with staff from the AVSS Project
at the University of California, Santa Barbara.
There are two different ways of implementing AVSS:
Time-shared via modems.
Stand-alone via PCs.
The time-shared method was the original approach and remains more
prevalent in Northern California. The amount of local technical
assistance varies, but tends to be more demanding for stand-alone
PCs. Indeed, this has been a chronic problem in Los Angeles County,
where more than 65 hospital PC installations are provided technical
assistance by limited county staff.
Today's Concerns.
Although the AVSS Death Record module is presently
being used to capture a minimum data set in 29 local registration
districts (accounting for more the two-thirds of all California
deaths), it has not been used to print death certificates or provide
death registration assistance to funeral directors. There are
several reasons for this:
First, is the larger number of parties involved. For births there
are 339 sites with 500+ user workstations in California. For deaths,
there could be many thousands, including:
About 800 funeral homes.
Probably hundreds of hospitals.
More than 100 county health department and recorders.
Nearly 60 county coroners.
Possibly 10,000 or more physicians.
Second, is the complexity of the process of gathering and completing
data fields involving multiple parties, sites, and times. For
births all data is gathered over a short period of time at the
place of birth, usually by a single entity, usually in the medical
records department. For deaths, it may involve the cooperation
of a number of autonomous parties including:
Funeral directors
Physicians
Family members of the deceased
Coroners/Medical Examiners
Hospital staff
Third, is the logistics of producing an acceptable copy of the
death certificate. Nearly all AVSS birth certificates are
acceptable for registration when the arrive at the local registration
district. For deaths, not only are there more data fields to be
completed, but there is more complexity. The most complex and
debatable field (Cause of Death) is a multiple-entry item that
is usually hand-written, often difficult to read, and may use
inappropriate terms or time sequences.
Fourth, is the associated burial permit that cannot be issued
until the death certificate is accepted as valid by the local
registrar. This is a multiple-part form (VS 9) requiring impact
printing and is not designed for use with laser printers. Note:
the present death certificate (VS 11) also is not optimal for
overlay printing by AVSS.
Requirements For An AVSS Solution.
In order to address the unique challenges associated with
electronic death registration, the AVSS approach would
utilize the time-shared approach. As for births in Northern California,
users wishing to register a death would connect to an AVSS
computer located at the local registration district. This assumes
that the local registration district has the necessary resources
including: adequate modems and telephone lines, an appropriate
multi-user computer, an AVSS System Manager, and AVSS
software that has been modified to meet death registration requirements.
Real-Time Death Registration Using AVSS.
As with the case of automating birth registration in 1981,
the AVSS approach to death registration would be revolutionary
and evolutionary. Revolutionary, since it would eliminate many
of the time consuming steps now required to register a death and
obtain a burial permit. Evolutionary, since it would build on
existing fax-based death registration procedures.
The procedures for real-time death registration under AVSS
would involve the following steps:
The funeral director connects to AVSS by means of a modem
on the local registration district computer in much the same way
as the public now connects to an Internet service provider such
as America Online or CompuServe. She/he initiates registration
by completing general fields on AVSS Draft Death Certificate
(DDC), then contacts physician.
The physician or coroner may also connect via modem to complete
the medical fields, then notify the funeral director. AVSS
would perform official state edits at all levels in the process.
Alternatively, the funeral director could complete the necessary
medical items according to physician instructions.
The funeral director contacts local registration district staff
to request certificate approval. This may be accomplished orally
by telephone or by using AVSS to remotely print a DDC (marked
"DRAFT") at the registrar's office in the same manner
as draft death certificates are presently faxed. The local registration
district staff reviews the DDC on a computer screen with the assistance
of AVSS edits and logic. If the DDC is acceptable, then
the registrar's staff runs an APPROVE DDC sub-option in AVSS
for that specific DDC. Otherwise, the funeral director must initiate
the necessary corrections as reported by AVSS electronic
mail or by telephone.
If the DDC is approved, then AVSS would allow the funeral
director to print the official death certificate and burial permit.
As with the fax procedure, a random FAX Authorization Number would
be printed on both the VS-9 and VS-11 forms. Following the successful
printing of the burial permit, AVSS would disallow additional
editing or printing of the specific DDC or burial permit.
The funeral director presents the printed certificate to the physician
for signature, then forwards both documents to local registration
district within 24 hours. If they are acceptable, then the DDC
is assigned a local registration number and becomes an official
California Death Certificate (CDC) that is no longer accessible
to the funeral director or physician. If it is unacceptable, the
registrar's staff would run a DISAPPROVE DDC sub-option to allow
the process to begin again, but retaining the current data values.
Benefits Of The AVSS Approach.
Automating the production of the death certificate as described
above would greatly reduce the manual efforts presently required.
More importantly, real-time connections between the funeral director,
the physician/coroner, and the local registrar by means of a common
data base would remove much of the uncertainty of timing related
to the acceptance and filing of death certificates. This would
reduce costs and assist in improved scheduling of funeral events,
thus eliminating a source of pain and frustration for bereaved
families. The benefits of the approach described on the previous
page are as follows for the:
Funeral Director.
The same advantages that made AVSS so useful to hospitals
for birth certificates would be immediately available to funeral
directors: no re-typing would be needed and corrections could
be easily made. Additionally, built-in edits would reduce the
likelihood of a rejected certificate. But more importantly, the
local registration district staff would review the draft certificate
before printing so that it would be very likely that the trips
to the local registration district would be reduced if not eliminated
entirely. Real-time registration should help to meet the 8-day
limit on completing certificates. Burial permits would be more
easily produced and more timely.
Physician/Coroner.
As with the funeral directors, automation would reduce the
need for re-typing and corrections and edits would improve the
quality of death certificates. Additionally, because AVSS
has already incorporated the entire ICD-9-CM list of diseases,
the cause of death reporting would be standardized and likely
to be of increased validity. Communications between various parties
would be greatly enhanced since all could participate in completing
the draft electronic record. This should help to meet the 15 hour
(3 days for coroner cases) time limit for completing medical items.
Local Registration District.
Because all edits, both logically by computer and visually
by the local registrar's staff, would be performed before the
death certificate is printed, not only would there be fewer rejected
certificates but also fewer counter visits by funeral directors
or their representatives. By insuring that state standards are
met at the local level, there would be fewer rejected certificates
by the State Office of Vital Records. Because the process of producing
a death certificate will generate an electronic record, there
would be major time savings for those local registration districts
that are presently key-entering data fields from death certificates.
With electronic death certificates integrated into a uniform AVSS
data base along with electronic birth records it will be possible
to electronically link births and deaths. California pioneered
the matching of births and deaths at the state level three decades
ago, which led to a number of "cohort" studies that
improved public health. Current requirements related to immunization
initiatives and managed care have emphasized the need to replicate
this success at the local level on a more timely basis. This goal
could best be realized if all local registration districts were
interconnected for both births and deaths by means of a single
integrated computer system.
State Office of Vital Records.
If the history of death automation follows that for births,
then state participation will follow several successful local
initiatives. For a number of reasons, the State Office of Vital
Records has historically taken a "wait and see" approach
to AVSS. If the counties are successful in automating deaths,
then the state could benefit, as it has for births, by receiving
electronic data and thereby its reducing key-entry load. During
the interim it would benefit by improvements in the quality and
timeliness of paper records resulting from automation.
RESPONSE TO SPECIFIC QUESTIONS CONTAINED IN THE RFI.
1. Are you planning to use your existing system?
Yes, as indicated in the Background discussion
above, we believe that it is important to build on the progress
made since 1981. Not only would this greatly minimize the cost
of development, but it would take advantage of the existing infrastructure
of software, equipment, and telecommunications. Of equal importance
is the significant investment in human capital in the form of
specialized training. As discussed above there is also the synergistic
effect of using a single system to create an integrated data base
containing both birth and death records.
As to the first sub-question: Will modifications be necessary?
Yes, there will be numerous modifications required to produce
an automated system of death registration that functions as smoothly
as AVSS does for births. As with births, we envision a
similar evolutionary process involving rapid prototyping. By this,
we mean that a prototype system would be programmed within a few
months and installed in a medium-sized local registration district
having fewer than ten funeral directors. (Note that Santa Barbara
County was the pilot for births and we would envision a county
of similar size for developing AVSS death registration.)
The prototype system would be tested by daily operations on a
small scale and re-evaluated with emphasis on user input. Changes
would be incorporated as needed by means of an iterative process
of real-world testing and programming improvements. It should
be noted, however, that as compared to the situation with births
in 1981, most of the necessary software components are already
in place, and that the development of a real-time death registration
component will require a fraction of the resources invested thus
far.
As to the second sub-question: Will we be using sub-contractors?
No, given adequate funding, the AVSS Project possesses
the requisite resources to make the necessary enhancements to
AVSS without the need for external assistance. As in the
past, however, we would work cooperatively with public agencies
to achieve mutually agreed on goals. In this sense there would
be the need for external resources, especially in terms of implementation
and ongoing operations.
2. What systems and capabilities do you currently possess that
will meet specifications defined as our EDRS minimum requirements?
2.1 Decedent and Informant Data.
During the course of its development AVSS was programmed
to optimize the indexing of vital records for rapid storage and
retrieval. Inherently, the B-tree data base structure employed
by AVSS is very efficient for accessing to individual records.
While each record is stored according to a primary filing index,
e.g. the local file number on birth certificates, there are numerous
cross indexes that allow users to quickly locate records by different
identifiers. For example, birth certificates are presently cross
indexed by child's name, mother's name, father's name, hospital
of birth, date of birth, date of filing, and date of last update.
Indeed, AVSS indexing is based on an open-ended design
that will allow the addition of any data base variable as a cross
index. Of course, the addition of a new cross indexing variable
will increase disk storage requirements. The power of AVSS
cross indexing, sometimes referred to as the "Person Selector"
has already motivated many local registrars to key-enter a minimal
number of data elements just to establish a data base for look-up
purposes alone.
The AVSS Person Selector is the starting point for editing
existing records. After typing "E" for edit, the Person
Selector queries the user on the choice of cross index, then proceeds
to prompt for the appropriate identifying information, where partial
responses are allowed (in fact, recommended). Records matching
the user's specifications will be displayed and, after the user
selects the appropriate record, the data field number that is
be edited is requested. This is a fundamental AVSS concept:
data items are stored and retrieved simply according to the number
of the data field, e.g. on the Certificate of Death, 1 is the
first name of the decedent, 2 is the middle, 3 is the last, etc.
For appropriate fields, extensive lists of choices are available,
and values may be selected by entering a few unique characters.
Editing a particular field for a specific record can therefore
be accomplished quickly by means of a handful of keystrokes.
2.2 Provider Information.
As discussed above, AVSS stores extensive lists of
choices for appropriate variables. For example, for Death Certificate
Field 23, AVSS allows the user to choose from all zip codes
in California, Oregon, Nevada, and Arizona. Moreover, each zip
code is associated with a corresponding state, county, and city,
so that the latter fields (25, 22, and 21) are set to the appropriate
default values based on the user's specification of the zip code.
This automated feature not only saves many key strokes, but improves
accuracy as well. This is an example of a fixed list of choices:
because zip codes and their associated place names are universal
and fixed for a given time period, they are maintained by the
AVSS Project and unmodifiable by users. If the user encounters
the need for an update due to postal zone or other institutional
change an AVSS Modification Request is submitted, and the
software is universally updated. There are other lists that may
be modified locally by the user. For example, the AVSS
list for Death Certificate Field 44 (Name of Funeral Director)
is presently maintained by each local registration district. Local
users initiate and maintain corrections to these lists and there
is no exchange of data from lists among local jurisdictions. If
there is a decision to standardize a list for a particular data
field, then there would be a requirement for maintaining such
a list at a central site, which involves a significant effort.
In either case, AVSS is programmed to facilitate the use
of such lists, either standardized or user-modifiable.
2.3 Provider Linkage.
If we are to interpret the word "linkage" to indicate
that funeral directors, physicians, coroners and local registration
districts would all participate in the production of paper and
electronic death certificates, then the AVSS approach is
geared toward that goal. In the discussion above under the heading
Real-time Death Registration Using AVSS the interaction
between the various parties is described. The "linkage"
of all participating parties is made possible by sharing a common
interactive data base, accessed by means of modems and telephone
lines. Since AVSS is based on a multi-user, multi-tasking
computer operating system it is possible for multiple parties
to access the same record simultaneously. Note however, that "record
locking" is maintained so that a specific record cannot be
simultaneously edited.
2.4 Death Certificate Generation.
As discussed above under Today's Concerns, overlay
printing by computer on the current Certificate of Death as supplied
by the State Department of Health Services has been one of the
obstacles in using AVSS for automating death registration.
In response to that barrier, Version 4.6 of AVSS was programmed
to produce a complete Certificate of Death, including data field
values, from plain paper on a single pass. As shown in Appendix
1, the resultant form appears very similar to the current state-supplied
blank forms. In actuality, it is of a style nearly identical to
the Certificate of Live Birth (VS 10D) since the AVSS Project
produced the latter as a public service using similar software
tools. The primary difference between the AVSS-produced
Certificate of Death and the state-supplied form is the absence
of check boxes in the former. The AVSS form does not contain
check boxes since they are not required in an automated system
and, more importantly, AVSS is programmed from the ground
up using a "what-you-see-is-what-you-get" approach.
That is, the electronic value stored for each data field is exactly
equal to the value printed on the paper. The check box approach
demands that an "x" be printed at a fixed spatial location
on the document, and not the actual data value. This would result
in unnecessary complexity and would possibly create errors. The
situation is similar to the early days of birth certificate automation.
The early state-supplied birth certificate forms contained check
boxes. In the early 1980s, the Office of State Registrar quickly
recognized the need for a computer-specific form without check
boxes. For some time there were three different forms: manual,
dot-matrix printer, and laser printer. In the case of the using
AVSS to print death certificates, no new forms would be
produced by the state, just the approval to use AVSS-produced
forms without check boxes.
The advantages of eliminating the need for state-supplied forms
are many. In addition to eliminating the cost and logistics of
printing several hundred thousand forms annually, the uniform
production of the death certificate on plain paper would allow
the various parties to view the Draft Death Certificate before
the official copy is produced. This would enhance the "provider
linkage" activities discussed above.
2.5 Burial Permit Generation.
Again, as discussed above under Today's Concerns, the
burial permit (VS 9) is a multiple-part form provided by the State
Office of Vital Records that requires impact printing and is not
designed for use with laser printers. To implement real-time death
registration using AVSS as described above it would be
necessary to program AVSS to print the VS 9 form and data
values on plain paper, but in this instance four copies would
be printed for each decedent. An example of the prototype four-part
VS 9 generated by a laser printer on plain paper is contained
in Appendix 2. As discussed above, the burial permit (as well
as the official death certificate) could not be printed until
the local registrar approved the Draft Death Certificate and the
electronic version of the burial permit.
2.6 Tracking and Query.
Because many vital records are confidential by nature and
may be legal documents, it is important that there be accountability
for their validity and accuracy. AVSS helps in this objective
by noting all user interactions for each form. AVSS was
designed to maintain an audit trail on all user interactions with
individual records. Beginning with the initial registration of
an event (birth, death, or disease episode), AVSS maintains
a log of the user identification, date, time, and type of transaction
for each electronic record. The contents of the log may be easily
accessed by under various menu choices including record display
and user reporting. For example, there are userspecific
reports on the time it takes to perform registration and editing
tasks and reports on initial and final values following user edits.
Logs are also maintained on automated telecommunications between
interconnected AVSS computers.
Additionally, the proposed data structure has the Draft Death
Certificate as a pending record, so that the status of completeness
of registration could be determined by examining the number of
incomplete data items. After the DDC is accepted for registration
and the VS 9 and VS 11 forms are printed, the DDC is transformed
into a legal electronic record, the California Death Certificate
(CDC). This will allow the status of legal registration to be
readily determined by authorized users.
2.7 Standard Reports.
AVSS has a built-in Report Generator that has already
been programmed to produce several legally-mandated reports utilizing
electronic death certificates. For example, the VS-200 report
lists identifying information for deceased persons over 18 years
of age to the local registrar of voters. These standard AVSS
reports are already in widespread user throughout California.
There is also a query data base capability that allows the user
to answer basic questions; for example, what are the ages for
deaths in a specified time period and zip code range? Undoubtedly
there exists a need to create additional standard reports for
death certificates, and the AVSS Report Generator provide
open-ended means to such an end.
2.8 Cross-filing.
The proposed AVSS approach provides remote access via
modem to a central data base by place of death occurrence. Cross-filing
between jurisdictions could therefore be most easily achieved
by providing outside agencies with the telephone access number
for the jurisdiction corresponding to the place of death.
2.9 Local Certificate Amendment Capability.
AVSS already contains an amendment capability for both
births and deaths. There is also an amendment display option that
allows the user to easily review the before-after values and the
date of the amendment.
2.10 Certified Copy Abstract Production.
Beginning in 1992, AVSS has had the capability to produce
certified abstracts for both births and deaths. This capability
is based on state protocols and is presently being used for births
in 13 local jurisdictions.
2.11 Reallocation Of Death Certificates.
AVSS has been automatically reallocating electronic
birth certificates from county of birth occurrence to county of
mother's residence since 1990. There are presently 55x55 or 3,025
electronic transfer paths for electronic birth certificates in
California. This process has been tested for electronic death
records between Alameda County and the City of Berkeley over the
last several years and the software for death reallocation has
been incorporated into Version 4.6, which was implemented statewide
during November and December, 1996. Full implementation of electronic
death reallocations is already complete in participating counties.
The steps in the automated reallocation process are as follows:
On a weekly basis the Central Site AVSS computer automatically
dials the AVSS computer at a participating Satellite Site.
An ongoing AVSS program at the Satellite Site continually
creates a list of those records that need to be reallocated, i.e.,
certificates for which the local registration district (LRD) of
birth occurrence differs from LRD of residence. This list is referred
to as the "Satellite Site Reallocation List." The corresponding
records are tele-communicated from the Satellite Site to the Central
Site (Forward Transfers). As the records are successfully transferred,
they are removed from the Satellite Site Reallocation List.
2. After the records have arrived at the Central Site, a different
list is updated describing the LRDs to which the records are to
be reallocated, referred to as the "Central Site Reallocation
List." This list may contain records to be reallocated to
the Satellite Site as determined from previous telephone calls
to other LRDs. If so, the records on this list are transferred
from the Central Site to the Satellite Site (Reverse Transfers).
As the records are successfully transferred, they are removed
from the Central Site Reallocation List and deleted from the Central
Site data base.
3. Return to Step 1 and telephone the next LRD in the cooperative
network. This process continues until all participating LRDs have
been polled. It is repeated weekly so that the Central Site Reallocation
List and the number of certificates at the Central Site are constantly
changing, but never grow indefinitely for participating LRDs.
For those LRDs that are not part of the network (and for other
states), however, there will be an accumulation of certificates
to be reallocated. These eventually will have to be purged from
the Central Site. This may occur for out-of-state residents.
2.12 Restricted User Access.
An important aspect of AVSS system management is protecting
against unauthorized use. This is especially pertinent since much
of the data stored in AVSS is confidential and protected
by state law. Access to AVSS options and data is limited
by user identification and by communication device number. Only
those individuals with authorized passwords are permitted to log-on
to the system, and their passwords tell the system not only who
they are by name and facility, but also the degree to which they
have access to AVSS options and sub-options. Similarly,
communication devices can be restricted in terms of access to
certain options and sub-options. For example, a System Manager,
is authorized to access all AVSS functions, but that person
will not be allowed to perform an activity by means of a particular
modem line that does not allow entry into certain options. Alternatively,
a hospital birth clerk might use a terminal connected directly
to the AVSS computer, which allows access to all options
and sub-options, but their password limits access to only the
HOSPITAL BIRTH RECORD option. It is the responsibility of the
local AVSS System Manager to control system access by means
of both password and device security.
2.13 System Outputs.
AVSS has been programmed to create standard ASCII files
for both birth and death records according to a number of formats.
Most noteworthy has been the California Birth Certificate Electronic
Submission Specifications ("CBC") format, as published
by the State Office of Vital Records. There have been several
versions of these specifications, the most recent specifying a
1400 byte record. The AVSS output corresponding to the
CBC format has been rigorously tested for over a decade. A number
of iterations were required to bring the CBC specifications and
the AVSS output into congruence. In some cases there was
a need to reprogram AVSS, but in as many cases there was
also a need to clarify and correct the CBC specifications. It
is important to note in this context that before AVSS was
employed for births there was a enormous amount of manual coding
involved in creating the CBC format; for example, place of birth
was numerically coded as was mother's and father's race and ethnicity.
The rules for these human decisions were sometime complex and
convoluted, involving multiple data fields. So it was necessary
to initiate an dialogue between those who were familiar with the
manual coding process and the programmer-analysts who had to create
the complex computer programs to replicate human thought. While
this was ultimately successful for births, it demanded significant
time and resources.
A similar situation now exists for deaths. With the advent of
the California 1996 Death Certificates Electronic Submission Specifications
in December, 1996, it will now be possible to begin programming
a standard ASCII file (1888 bytes in length) for deaths. A quick
review of the document indicates that the process will be similar
for births in that the death specifications remain incomplete.
For example, there is no indication on how to report time intervals
between onset of cause and death in terms of units of measure,
since years, months, weeks, days, hours, minutes, seconds, and
instantaneous are all possibilities. It is likely that an iterative
process, similar to that experienced for births, will be necessary.
2.14 System Inputs.
AVSS originated in a minicomputer environment in the
early 1980s and retains that legacy in terms of input devices.
This is the primary reason why the line-by-line prompting interface
remains the primary method of data entry. While antiquated in
appearance beside modern graphical screens, the character-based
AVSS interface has been refined over the years to become
a very efficient vehicle for data entry. Ten function keys are
programmed in most sites to correspond to important AVSS
functions and shortcuts. This, coupled with the standardized nature
of vital records results in data entry times that are very short
by any standard. Moreover, the simple interface has the advantage
of easy access by means of ASCII terminals, PCs, serial communication
lines, and modems. The interface has been recently integrated
with bar code readers, resulting in improved efficiency during
electronic birth registration.
2.15 Remote Access.
The AVSS approach to automating death registration
has remote access by modem as the principal avenue for user input.
This was the original method for data entry during the early years
before the advent of PCs. With the coming of PCs there was a rush
to standalone installations at hospitals. This was appropriate
when central processors had much less power and modems were slow,
subject to telephone noise, and somewhat expensive. However, standalone
PC implementations are more expensive to install and more difficult
to maintain, in terms of hardware, software, and user training.
More importantly, standalone computers necessitate complex telecommunications
strategies to transport data and there are unavoidable time delays.
With the advent of very powerful and inexpensive central processors
and high-speed modems with error correction, and with the need
for real-time sharing of data for death registration, the remote
access model is the preferred choice for death registration. The
multi-user/tasking nature of AVSS coupled with the built-in
tools for restricting user access (discussed in 2.12 above) makes
it an ideal platform for constructing an automated death registration
system based on modems. This approach could be applied to the
Internet by utilizing Telnet capabilities in place of modems.
2.16 System Security and Access Control.
As discussed in 2.12 above, AVSS was programmed from
the beginning to allow access only to authorized individuals by
means of passwords, and access can be customized to be limited
to specific functions depending on the password. This is accomplished
by means of the CLASSIFICATION FILE, which limits access to AVSS
options and sub-options for specific user classifications according
to each user's encrypted password. In the same manner, the DEVICE
TABLE limits access to options and sub-options for specific devices,
e.g. modem lines or terminals. In addition to the System Manager
classification, which allows access to all AVSS options
and sub-options, there are a number standard classifications that
come automatically with every implementation. These classifications
should suffice in most instances, but there may be special circumstances
the require the creation a custom classifications, which is a
standard procedure that can be performed by the AVSS System
Manager. These features mean that AVSS could be programmed
to restrict access of certain components of the database to certain
classifications.
AVSS has a number of additional security features such
at the automatic expiration of passwords and security report that
lists failed password attempts by device number, date, and time.
2.17 User Interface.
As a character-based user interface AVSS has been optimized
to automatically select from a list of choices using the "first-hit"
principle. As an example, consider the prompt for state of birth.
For over a decade AVSS has incorporated the Library of
Congress Machine Readable Codes (MARC) containing abbreviations
for all countries as well as US states. These codes have allowed
local health departments identify parental birth place with much
greater detail than current state abbreviations, which are limited
to just a few foreign countries. In order to allow the user to
choose from a list of hundreds of choices in the MARC list, but
still use a "first-hit" method for more frequent entries,
AVSS employs sophisticated input logic. For example, if
a "C" is entered for state of birth, AVSS will
ask the user to chose from 36 possibilities in the following pick
list:
1 CA= CALIFORNIA
2 CAICOS ISLANDS
3 CALIFORNIA
4 CAMBODIA
5 CAMEROON
6 CANADA
7 CANAL ZONE (OLD)
8 CANTON ISLANDS (OLD)
9 CAPE VERDE
10 CARTIER ISLAND (OLD)
11 CAYMAN ISLANDS
12 CENTRAL AFRICAN REPUBLIC
13 CENTRAL LINE ISLAND (OLD)
14 CH= CHINA
15 CHAD
16 CHILE
17 CHINA
18 CHRISTMAS ISLAND (INDIAN OCEAN)
19 CN= CANADA
20 CO= COLORADO
21 COCOS ISLANDS
22 COLOMBIA
23 COLORADO
24 COMOROS
25 CONGO (BRAZZAVILLE)
26 CONNECTICUT
27 COOK ISLANDS
28 COSTA RICA
29 COTE D'IVOIRE
30 CROATIA
31 CT= CONNECTICUT
32 CU= CUBA
33 CUBA
34 CYPRUS
35 CZECH REPUBLIC
36 CZECHOSLOVAKIA (OLD)
But if a "CA" is entered, AVSS will
automatically match "CALIFORNIA" even though there are
ten other entries beginning with the letter "CA." Note
that the entire word is also on the list in case the user spells
the name entirely or uses a different abbreviation such as "CALIF."
Similarly, one could select "COSTA RICA" in one step
by entering the three unique letters "COS." In summary,
the AVSS list processing is highly developed and refined,
is efficient, and is familiar to local registration district staff.
2.18 Open Flexible Design.
A central aspect of the original AVSS design was its
modular structure. From the beginning, it was decided to build
on a centrally integrated data base by adding independent processes.
Thus, the birth certificate was but one branch on a tree with
other applications to be added as necessary. And within the birth
certificate, added functionality could be incorporated as users
became more acquainted with the potential of the data base that
had been created; the issuance of certified abstracts is but one
example. Adding new modules cannot be readily accomplished without
the support of the AVSS Project, however. While modularity
is fundamental to the AVSS data structure and software
design, it nevertheless requires an expert AVSS programmer
to add a new module. While there was an attempt to generalize
the addition of modules during the middle 1980s by means developing
a new programming tool (the AVSS Form Editor), the ability
of outside users to master this tool was found to be inadequate.
There are thus no easy-to-use "plug-ins" in AVSS.
Some outside users have, however, been able to master the AVSS
Report Editor and thereby produce custom reports.
2.19 Responsiveness.
As discussed earlier, the data structure of AVSS is
optimized toward individual record storage and retrieval. Using
today's Pentium processors, identifying and retrieving a specific
record in a data base containing tens or hundreds of thousands
records is usually accomplished within a fraction of a second.
Because this data structure is geared toward individual records,
the efficiency gained for individual records transactions (which
comprises the bulk of AVSS user activity) is offset when
it comes to running reports. As with individual queries, reports
must utilize one of the several AVSS indexes to select
the records to report on; for example, a date range. As a result,
report generation tends to be slower in AVSS as compared
to sequential data structures. Still, the enormous speed of fifth
and sixth generation computer chips has offset this limitation.
As for system reliability, AVSS operates with only occasional
problems in hundreds of sites throughout California on a 24-hour,
7-day week basis. The M operating system used by AVSS was
designed to be used for real-time medical applications and is
considered to very robust and reliable. System reliability is
further enhanced, however, by the careful selection of reliable
computers, tape backups, and uninterruptable power sources.
2.20 Quality Control.
Partly as the result of user suggestions, AVSS now
possesses rigorous quality control tools for electronic birth
records which could be applied without a great deal of effort
to electronic death records. For example, in order to prevent
duplicate birth certificates, there are three separate checks:
an interactive check that is executed several time during birth
registration, a batch report that checks for duplicate name and
date of birth, and a batch report that identifies babies having
identical hospital, date, and time of birth.
As for interactive edits and quality checks of data during data
entry, this is an area in vital statistics that was first introduced
by AVSS in an effort to improve the quality and completeness
of vital records. To accomplish this, AVSS automatically
performs many edits at the time of data entry to warn or otherwise
prevent users from making errors. If a data value appears "unreasonable,"
users will be warned, asked to validate the value, or possibly
not even allowed to enter it. There are two types of questionable
data entities in the CBC Specifications: "cross references"
and "validations." Cross references represent data impossibilities
(e.g. a thirdborn twin) and must be resolved before an electronic
record can be printed or filed. Validations represent unusual
data values that are very unlikely, and the user must confirm
they are correct by referring to the original data to be sure
that there was not a transcription or data entry error. The third
type of edit is an AVSS-specific warning that goes beyond
the CBC Specifications. To summarize, there are three types of
AVSS input checks:
Cross References: Impossible data values are not allowed.
Validations: Improbable data values that require the user
to check original sources.
Warnings: Unlikely values, but do not require the user
to check the original sources.
Validations are important since they require time and effort to
check the original sources of information. If the user confirms
that the value is correct, then AVSS will record the user's
initials and the date that the validation took place. The following
demonstrates a validation message during birth certificate data
entry:
26. BIRTHWEIGHT > [6600] [ENTER]
BIRTHWEIGHT (26) IS GREATER THAN 6500 GRAMS.
VALIDATION: BW2
THE STATE REGISTRAR REQUIRES THAT THE FOLLOWING
COMBINATION OF FIELD(S)/VALUE(S) BE VALIDATED:
FIELD: 26 = '6600'
YOU WILL LATER BE ASKED TO VALIDATE THIS VALUE,
IF YOU ARE UNSURE OF ITS VALIDITY, BACKUP WITH AN '^' AND USE
'^S' TO SKIP
If the user does not change the value for Field 26, then
the following validation procedure must be executed:
BIRTHWEIGHT (26) IS GREATER THAN 6500 GRAMS.
VALIDATION: BW2
THE STATE REGISTRAR REQUIRES THAT THE FOLLOWING
COMBINATION OF FIELD(S)/VALUE(S) BE VALIDATED:
FIELD: 26 = '6600'
HAVE YOU REFERRED TO THE ORIG SOURCES & ARE YOU SURE? >
[Y] [ENTER]
Again, validations require that the user check the original
sources. Cross references require the user to change one or more
data values until the cross reference message no longer appears.
In both cases AVSS will not allow the record to be printed
or filed until the questionable data values are resolved. In the
case of validations, AVSS will record the necessary information
to create an audit trail for reporting purposes. This information
is used in the VALIDATION DISPLAY as shown below:
VALIDATION MESSAGES:
BIRTHWEIGHT (26) IS GREATER THAN 6500 GRAMS.
VALIDATION: BW2
THE STATE REGISTRAR REQUIRES THAT THE FOLLOWING
COMBINATION OF FIELD(S)/VALUE(S) BE VALIDATED:
FIELD: 26 = '6600'
VALIDATED BY (INITIALS) BC ON 2/12/96 AT 10:41.28 AM
Since the Electronic Submission Specifications document
for deaths has just (December, 1996) been made available by the
Office of Vital Records, the necessary cross-references and validations
have not been programmed into AVSS. This is a customized
task that is likely to require significant resources.
2.21 Training and Operation.
The AVSS character-based user interface has proved
to be simple and easy-to-use. The user is given a hierarchical
set of menu choice and selects by typing the first letter of the
choice; for example, "D" for Death Certificate, then
"R" for Register. Additionally, ten function keys have
been programmed to perform special AVSS functions; for
example, pressing the F1 key yields context-sensitive help.
As with menu choices, the AVSS training method is also
hierarchical: the AVSS Project trains the local registration
district staff with special emphasis on the System Manager. The
local System Manager, in turn, is responsible for training all
AVSS users within the registration district, and works
with the local vital records unit and with hospitals to improve
the timeliness and quality of paper and electronic birth certificates.
This person is responsible for the daily automation operations
in regard to vital records, and insures that the hospitals and
all other AVSS users are able to properly maintain their
automation functions as well. In brief, the AVSS System
Manager oversees and assists in the implementation, training,
updating, and ongoing support of all local AVSS operations.
2.22 Technical Support.
The AVSS Project provides technical assistance by means
of a telephone help desk that is available from 8:00 AM to 5:00
PM on weekdays. This includes assistance in the answering of user
questions, software debugging, hardware problem solving, database
repairs, installation of AVSS-compatible hardware, and
writing of reports. At least one on-site visit is provided to
each local registration district annually. One updated version
of AVSS software containing user-suggested improvements
is also provided annually. The AVSS Project is not responsible
for hardware maintenance.
2.23 Remote Diagnostic Capability.
Since all AVSS sites have built-in remote access by
modem, the AVSS Project staff is able to diagnose and can
usually solve system problems remotely. Indeed, a prerequisite
for any AVSS installation is the availability of modem
access so that technical assistance can be immediately provided.
In order to minimize the possibility of data base errors, AVSS
automatically performs a system integrity check each evening and
records the results for remote access and diagnostics. If an error
is detected, all data entry is automatically suspended until the
problem is corrected.
3. What modifications to your existing system will be required
to meet our stated specifications?
Although AVSS already possesses most of the features
that are required for an electronic death registration system,
there remains considerable work to produce the real-time system
described above. First would be the development of the Draft Death
Certificate module described in the five steps on Page 4. The
concept would have to be field-tested and undoubtedly, as for
births, a number of changes would be required to have the system
operate to the satisfaction of all the parties involved. As already
described, this would involve an evolutionary process. A major
component of the DDC would involve the programming of cross references
and validations contained in the 1996 Death Certificates Electronic
Submission Specifications. Programming the standard ASCII file
corresponding to these specifications would be another significant
task. In addition to developing the DDC, the programming the printing
of the VS 9 form remains to be completed as well as an undetermined
number of standard reports.
Please provide the following descriptions:
Note: A more complete description of AVSS capabilities
is contained in Appendix 3 and there is more information available
on the AVSS Home Page at: http://id-www.ucsb.edu/avss/avsshome.htm.
4.1 Related experience and current/past installations.
AVSS Project staff have contributed to public health
programs for more than two decades with emphasis on maternal and
child health and on vital statistics. Project staff have published
seminal research papers related to vital statistics in public
health and medical journals. A list of publications is contained
in Appendix 4. AVSS has been in continuous operation in
California since 1981 and presently encompasses 337 sites composed
of 54 local registration districts and 283 hospitals.
4.2 Pricing structure and approach.
AVSS is copyrighted by the Regents of the University
of California. A Software Agreement specifies a royalty charge
of $250 per user terminal, renewable every three years. M is also
required to run AVSS. A "runtime only"
M-PC license, suitable for hospitals or small-to-medium-sized
local registration districts, is available through the AVSS
Project for $250. Thus, the minimum cost for a oneuser AVSS
license on a PC, including M, is $500, with each additional terminal
adding $250, payable every three years. A more powerful version
of the M license typically costs $1,000 for eight users.
There are also fees for AVSS technical assistance. These
fees support the daily (M-F) telephone help desk, an annual AVSS
update, and as-needed technical services. The FY 96-97 formula
was $2,000 per registration district plus $500 per AVSS
hospital for districts having at least 3,000 births annually.
A sliding scale, designed to relieve smaller districts of a large
financial burden, was applied as follows: discount the formula
by 75% for districts with fewer than 1,000 births annually, 50%
for 1,000 to 1,999 births, and 25% for 2,000 to 2,999 births.
4.3 List of current customers (contact person, telephone numbers
and email addresses).
A list of AVSS sites in California with the name and
telephone number of the site contact person is contained in Appendix
5. Note: the contact person at some hospitals may be the local
System Manager.
4.4 Company profile/history/depth and scope of staff resources.
The AVSS Project resides within the Health Data Research
Facility, a research center belonging to the Community and Organization
Research Institute (CORI) at the University of California, Santa
Barbara (UCSB). For more than two decades, CORI has served as
one of the most successful of UCSB's organized research units.
CORI's original mission was to serve as a resource for research
in the social sciences and to promote the dissemination of research
into the community. It was the latter goal that attracted the
AVSS Project's director to CORI, who became CORI's first
full-time academic researcher and has served as acting director.
At total of 78 different projects employing 54 academic personnel,
12 staff members, 80 graduate students, and 55 undergraduates,
with over $6 million in funding, are currently administered by
CORI. AVSS Project staff consists of six members:
Ronald Williams, who has directed the AVSS Project since
its beginnings in 1980. From 1972 to 1995 he developed the Maternal
and Child Health Data Base, a hospital-specific compilation of
perinatal statistics. His efforts to improve the timeliness and
accuracy of the input data for the Data Base were key to the creation
of AVSS. Ron holds a B.A. in physics from the University
of Michigan and a Ph.D. in economics from UCSB.
Peter Chen, who is one of the two principal AVSS Project
programmers, and was the lead programmer for the Maternal and
Child Health Database. Peter has a B.A. in computer science from
UCSB, where he graduated Phi Beta Kappa.
John Marinko, the other principal programmer, who wrote the prototype
version of AVSS in 1980. John earned a B.S. in computer
science from UCSB.
Julie Kluss, who has been the AVSS Project's secretary
since 1991 and is responsible for managing the financial accounts
related to software licensing and technical assistance. Julie
earned a B.A. in zoology with highest honors from the University
of Hawaii.
Ellen Needham, who has been with the AVSS Project since
1992 where she is responsible for the AVSS Help Desk ,
managing change control, and site data base files. Prior to 1992,
Ellen worked in the Data Processing department at a medical laboratory
for 17 years. Ellen received her B.S. in computer information
systems from California Lutheran University.
Gail Cayton, who joined the AVSS Project in 1995, assists
Ellen at the Help Desk and specializes in field work. She received
a Certificate in PC Support and Network Management from Santa
Barbara City College. Prior to coming to UCSB, Gail worked at
American Airlines' Sabre Software Help Desk and earned a B.A.
in history from Pennsylvania State University.
4.5 Operating system/applications software to be proposed.
AVSS is programmed to run under the M system. M is
not only a multi-user and multi-tasking operating system, but
also integrates an American National Standard programming language
and a B-tree data base structure. The standard nature of the language
permits portability over a range of computer architectures. As
a result, AVSS runs on a variety of computers, ranging
from the minicomputers that were used for the first implementations
of AVSS, to a MS-DOS and Windows 95-based contemporary
personal computers. VAX minicomputer implementations are also
supported.
4.6 General system design/architecture description.
As discussed on Page 4, the AVSS approach would utilize
a time-shared computer whereby users wishing to register a death
would connect to the local registration district facility by means
of modem. This real-time process is based on simultaneous remote
access of all appropriate parties to the same pieces of information
concerning the deceased, and sharing in the work load to satisfy
legal requirements.
4.7 System software/hardware requirements.
For adequate responsiveness, AVSS requires at the minimum
a PC with a 486 chip. All presently marketed mainstream PCs have
ample memory and disk storage to support AVSS in small
local registration districts. Similarly, current mainstream Pentium
computers would support a medium-sized county. For larger counties
a PC with a fast Pentium chip and 2 or more gigabytes of disk
storage is recommended. Additionally, in order to support the
simultaneous access by many users, a multiple serial communications
board must be added to the PC. Currently marketed external modems,
such as those used to access the Internet, will suffice for AVSS
applications. It is recommended that the local registration district
have a separate telephone line (of the same quality as used for
fax machines) and an external modem for each funeral home accessing
the system. For data base protection an uninterruptable power
supply and an external tape backup are required. Each user accessing
the system remotely must have a telephone line, a modem, and either
an ASCII terminal or a PC with communications software. A laser
printer with PostScript capability is required to print death
certificates and burial permits.
4.8 Reporting capabilities at various levels.
The AVSS Report Generator Query Database sub-option
is a menudriven interactive tool for producing adhoc
tabulations after entering selection criteria. Query Database
is an easy-to-use interactive tool for ad hoc queries.
It may be used to search the data base, using one or more fields
from AVSS records. Query Database produces one-dimensional
tabulations, after locating birth records that satisfy the conditions
specified in the query. It is flexible in its method of identifying
a special subset of vital records. Its main disadvantage is the
output reporting format, which is limited. For more specialized
reports, such as listings and cross-tabulations, a general purpose
Report Editor has been used to create dozens of standard reports
for birth certificates, but as yet only a handful for the death
certificate. Expert AVSS users can create their own custom
reports by means of the Report Editor. These reports may be run
as multi-tasking jobs and the output saved to be retrieved at
a later time.
5. Demonstration Aspects.
5.1 Can all or portions of your system be demonstrated at a
site we will select?
A total of 29 local registration districts in California
are currently using AVSS to key-enter a minimum data set
of fields from the Certificate of Death. These sites include:
Alameda, Contra Costa, El Dorado, Fresno, Humboldt, Kern, Los
Angeles, Madera, Marin, Mendocino, Merced, Monterey, Napa, Nevada,
San Bernardino, San Joaquin, San Mateo, Santa Barbara, Santa Clara,
Shasta, Solano, Sonoma, Stanislaus, Sutter, Ventura, Yolo, and
Yuba counties as well as the cities of Berkeley and Long Beach.
The portions exclusive of the method of real-time death registration
proposed herein could be demonstrated immediately at any of these
sites. Of course, it would be necessary to contact the AVSS
System Manager at the site chosen for approval and to make the
necessary arrangements in advance of any demonstration.
5.2 Please describe demonstration capability and mode.
Since space and computer equipment in most local registration
districts is very limited and there are frequent interactions
with the public, the site chosen should account for the number
of persons in the evaluation team. In any case the mode would
be by means of existing equipment, and thus limited to a relatively
small number of persons. Offsetting this limitation is the advantage
of observing the actual capabilities of AVSS in an operational
setting.
5.3 Describe capacity to customize.
The AVSS Project is prepared to undertake further customization
of existing capabilities as described in Section 3 above. Before
programming begins, however, it would be necessary to obtain the
necessary funding to commence a project of that magnitude.
5.4 Estimated time to complete.
Assuming the full cooperation of state and local agencies,
it is estimated that it would take approximately six months to
develop a prototype real-time death registration system of the
type described herein, and another six months for testing and
additional developments in a local registration district. Following
the successful completion of a prototype system, it is likely
to take several years for statewide implementation.
Updated January 17, 1997 by RL Williams
