Noam H. Arzt, Ph.D. (
President, HLN Consulting, LLC (
Senior Fellow, University of Pennsylvania (

Susan M. Salkowitz (
Health Information Systems Consultant, Salkowitz Associates, LLC

Expert Testimony,
National Vaccine Advisory Committee and
National Immunization Program, Centers for Disease Control and Prevention
Initiative on Immunization Registries
Public Meeting on
Resource Issues Related to State and
Community-based Immunization Registries
Washington, D.C. – May 13, 1998

Registry System Tradeoffs


There have been precious few studies, and very little successful research, on the cost of deploying state and community-based immunization registries. While clearly they require substantial resources to be launched, studies that focus on the initial startup costs of deploying registries often suffer from limited usefulness for a number of reasons:

  1. As the number of records contained in the systems tend to start out small, the temptation to calculate a cost per record yields an alarmingly high number (large cost numerator, small record quantity denominator).

  2. The true ongoing operational costs are hard to predict, are frequently unfunded, and often are buried in various operating lines of the budget.

The development of immunization registries involves making a variety of tradeoffs. The ever-present tradeoff between a registry project and all other systems projects and programmatic initiatives to be undertaken by an organization is being stressed by two major events in the late 1990's:

  1. Information technology organizations are consumed with Year 2000 fixes and changes to the point that, in some extreme cases, all new initiatives are on hold until the new millennium.

  2. Many large health systems have embarked on major systems redesign or redeployment projects that will take years (and millions of dollars) to complete. Immunization registries appear as flies buzzing around these immense projects.

All that being said, we have found it useful to examine the tradeoffs of functionality within  registry projects when resources are limited (as they always are...), and to consider these tradeoffs when assessing the impact of registry development. We have constructed a model to describe these tradeoffs.

Elements of the Model

The model has four elements:

Functionality: This refers to the features that support provider and community registry functions (as defined by NVAC): initialization of a child's record at birth, consolidation of immunization records, query to locate a child's record, assessment of immunization status and the schedule algorithm to support it, facilitation of reminder/recall, and interface with CASA for practice or community assessment. Some registries include other immunization functionality such as adverse event/contraindication reporting and vaccine inventory.

Some registries also include such healthcare functionality as: capturing a greater number of tests and conditions, like TB and lead; well child/EPSDT and scheduling, and/or are part of larger public health, practice management or clinical systems. In some cases, these other functions can diffuse the focus on immunization, though if designed properly they can enhance the overall usability, functionality, and appeal of the registry.

A variety of user interfaces to these systems are supported (e.g., FAX-back, client/server, web-enabled) are elements of the system's overall functionality.

Timeliness: Timeliness refers to the registry's response in a variety of ways to the demands of schedule and currency. In includes everything from the amount of time it takes from initial system query for a record to appear (no matter what the product architecture may be), how fast a new record or updated record is absorbed into the registry and is available for other functions (e.g., assessment or reminder/recall). Timeliness also refers to the turnaround time for batch records to be loaded into the database. The more frequently or regularly data flows, the more resources will be consumed to keep it timely and accurate.

The size of the registry: The size of the registry, measured either in number of records or number of provider sites participating, affects the communications, technical capacity, and staffing required to operate the system, maintain stability and reliability, and ensure confidentiality. The transience of patients among providers is a complexity issue which also impacts deduplication efforts and impacts how fast a project can add providers and maintain data quality. The larger the number of providers involved, the more complex the organizational relationships required to sustain the project. Sheer size can stress the scalability of many technical architectures and the stability of the organizational support.

Sophistication of Records Exchange Interface: Registries rise and fall based on their ability to be populated with timely and accurate demographic data and immunization histories. The most successful systems are those that are initialized at birth and maintained on a "go forward" basis with point of service online data entry and update. As a practical matter, most registries rely on a combination of online data entry (either by data entry staff from forms or at point of service) and batch data (usually via an electronic interface). Some registries use a combination of interfaces, relying on an initial electronic file load with online data update thereafter; others require bi-directional data transfer between the registry and provider systems.

Electronic files can vary from flat ASCII files to standards-based formats such as X12 and HL7 and standard field values such as CPT codes. Many registries have timely electronic birth interfaces, but need to incorporate retrospective demographic and history records from disparate systems with wide variations in record quality. Data quality issues are significant and are affected by how automated data cleaning procedures become.

Diagram of the Model

In many ways, registry system development is a "zero sum game" – a fixed set of resources are available for the initiative, and doing a little more of one thing results in getting a little less of another. To help understand these tradeoffs consider the diagram below:

The four items each occupy one of the four axes on the graph. The closer the item is plotted to the center of the diagram, the less the attribute is present in the registry system being examined; the farther the item is plotted from the center of the diagram, the more the attribute is present in the system.

Two sample systems are plotted for illustrative purposes:

The red example represents a registry whose project has chosen to focus on a maximum of immunization functions, and strives to sign up as many participating provider sites as possible. With fixed resources, this project cannot support a very sophisticated records exchange interface if it is to maintain data quality among its large number of provider sites, nor can it provide very timely processing.

The blue example represents a registry whose project has also chosen to focus on a maximum of immunization functions, but has deployed a more sophisticated records exchange interface at the expense of covering a larger number of provider sites. It's smaller size and more sophisticated records exchange interface allow it to be slightly more responsive to project timetables.

The shape of the polygon formed by connecting the points touching each axis shows visually the tradeoff accepted by the registry project. The amount of resources available determines the overall size of the shape. Using this methodology, a registry project can explore its own tradeoffs and have a visual tool to show the impact of its decisions.

Copyright © 1998 HLN Consulting, LLC and Salkowitz Associates, LLC