IIS Minimum Functional Standards, 2001-2013 Historical Information
ShareCompartir
This website is archived for historical purposes and is no longer being maintained or updated.
December 18, 2012: Content on this page kept for historical reasons.
Note: Effective December 14, 2012, these standards have been replaced by the IIS Functional Standards, 2013-2017
This document represents the April 5, 2001 recommendations made by the National Immunization Program's (now known as National Center for Immunization and Respiratory Diseases) Technical Working Group (TWG) on the minimum technical functions of immunization registries. These standards were identified through a process that involved an October 1997 survey of immunization program managers and registry developers regarding the technical functions that "at a minimum, state- and community-based immunization registries must" implement. Functions that were identified by >= 75% of respondents were discussed at breakout sessions at the 1997 Program Managers meeting to ensure consensus. Since that time, the core functions have been renamed "immunization registry minimum functional standards."
These standards continue to guide IIS development today. Given the evolving nature of health information technology, these standards are currently being reviewed, updated, and revised. NVAC approval will be sought as part of this process.
Note: These standards only apply to records available in a population-based immunization registry (one that is designed to contain all children in the catchment area) that is operating in compliance with state/local laws and/or policies. For example, in a state where explicit consent is required by law or policy, these standards only apply to records where explicit consent has been obtained.
| # | Functional Standard | Definition | Notes |
|---|---|---|---|
| 1 | Electronically store data on all NVAC-approved core data elements | The registry's computer database contains fields for all NVAC–approved core data elements. These elements are: patient name (first, middle, and last); patient birth date; patient sex; patient patient birth state/country; mother's name (first, middle, last, and maiden); vaccine type; vaccine manufacturer; vaccination date; and vaccine lot number. | The core data elements comprise the basic set of data that registries will exchange with each other. They are designed to standardize a set of patient demographic and vaccine event elements that are considered core to record exchange between registries. The mother's name element refers to current legal mother (who may or may not be birth mother). To receive credit for the patient and mother names, at least a surname and one other name element must be valued. |
| 2 | Establish a registry record within 6 weeks of birth for each newborn child born in the same catchment area | Identifying information from a population-based data set (e.g., vital statistics) is regularly sent to or retrieved by the registry in a computer file format that requires little, if any, manipulation by registry staff for the data to be entered into the immunization registry. Such information is available in the registry within 6 weeks of birth. | |
| 3 | Enable access to and retrieval of immunization information in the registry at the time of encounter | The registry provides a means by which providers can access and retrieve immunization records prior to or at the time of a scheduled encounter. | This standard accommodates registries that do not operate continuously (e.g., closed Sundays and holidays) and those that send and receive non–electronic records in order to allow access to users without electronic capabilities. For example, providers can request and receive the immunization record(s) needed from the registry prior to the scheduled encounter (can include printed patient lists, flags on charts, fax or phone requests). |
| 4 | Receive and process immunization information within 1 month1 of vaccine administration | The registry receives and processes immunization information within 1 month of vaccine(s) administration (e.g., can include fax or phone requests). | |
| 5 | Protect the confidentiality of health care information | The registry has written confidentiality policies and procedures in place and implemented, including administrative and technical practices to protect health care information2. The policies and procedures are consistent with applicable state and local laws, and Federal law (HIPAA or other privacy law) when implemented, and with the recommended specifications and guidelines outlined in the updated "Community Immunization Registries Manual: Chapter II: Confidentiality," except where they conflict with applicable legislation. | |
| 6 | Ensure security of health care information | The registry has written security policies and procedures in place and implemented, including administrative and technical practices and physical safeguards to protect health care information. The policies and procedures are consistent with applicable state and local laws and with Federal law when implemented. | Appendix D of the "Community Immunization Registries Manual: Chapter II: Confidentiality" will serve as the current recommended specifications and guidelines; however, HIPAA implementation may result in a change in the minimum specification. |
| 7 | Exchange immunization records using Health Level Seven (HL7) standards | The registry has a function, at the central level, that creates, receives, and properly processes the HL7 messages, as specified in NIP's Implementation Guide for Immunization Data Transactions using Version 2.3.1 of the Health Level Seven (HL7) Standard Protocol, June 1999. | |
| 8 | Automatically determine the routine childhood immunization(s) needed, in compliance with current ACIP recommendations, when an individual presents for a scheduled immunization | The registry has an automated function, accessible at the provider level, that determines needed routine childhood immunizations, in compliance with current ACIP recommendations, given an individual's immunization history to date. | |
| 9 | Automatically identify individuals due/late for immunization(s) to enable the production of reminder/recall notifications | The registry has an automated function that produces a list of individuals who, as of a given date, are due or late for immunizations according to the registry's algorithm (see Functional Standard #8). The output from this function gives the ability to produce reminder or recall notices. | |
| 10 | Automatically produce immunization coverage reports by providers, age groups, and geographic areas | The registry has an automated function to assess immunization coverage (e.g., % of children "age-appropriately" immunized) as of a given date for an individual provider's practice, for the registry's entire catchment area, and for subgroups within a practice or the catchment area (e.g., children of a certain age). | |
| 11 | Produce official immunization records | The registry has a function that allows authorized users to produce an individual's immunization history that is accepted as an official immunization record. | |
| 12 | Promote accuracy and completeness of registry data | The registry has developed and implemented a data quality protocol to combine all available information relating to a particular individual into a single, accurate immunization record. |
Footnotes
- For the purposes of this calculation, one month equals 30 days.
- Health care information in this document refers to patient demographics, as well as medical conditions, care or services related to the health of the patient.
- Page last reviewed: November 15, 2016 (archived document)
- Content source: