Vermont Immunization Registry and NEDSS I’m here to talk about the Immunization Registry activities that have been occurring in the Vermont Department of Health during the past couple of years. My talk will be focused on the construction of the application, as I am with the Departments centralized IT group and not part of the Immunization Program, although the activities of our unit concentrating on that program for the past couple of years has made us quite familiar with the program. The points I want to discuss are: The current status of the Vermont Immunization Registry How we got there What lies ahead What we learned during the process While we use the concepts presented by NEDSS, we named our initiative SPHINX, Shared Public Health Information Exchange, simply to recognize that these are two separate initiatives, destined to be joined in the near future. Next slide Vermont Department of Health 4th Immunization Registry Conference – Atlanta, GA – October 28, 2003

Where we are An in-house developed Immunization Registry 12 pilot locations 20,000 children registered 950 have 2 or more immunizations recorded Uses the NEDSS logical data model Utilizes the CDC-provided immunization forecasting algorithm The registry was developed totally by in-house staff. We have four Visual Basic developers and three SQL Server developers that were dedicated to this project for most of the period. No contractors were engaged for the development of the software, with the exception of training services, to help us with our software development process. The registry is currently at 12 pilot locations and plans are being made to double that by the end of this calendar year. There are approximately 150 sites, statewide 20,000 children registered – populated from Vital Record Birth data Approx. 950 of these have two or more immunizations recorded This application uses a database that was created from the NEDSS logical data model that was released by the CDC in October, 2001 The registry contains a immunization forecasting algorithm - the one that was provided by the CDC. Next slide

Where we are Contains a de-duplication process Menu driven Web based – utilizes Citrix technologies Prints Immunization Record Three levels of security User Application Database The de-duplication process is done through a purchased software package. The name of the package is Name-Search and is provided by Intelligent Search Technology, Limited. The name matching process is continually being reviewed for increased accuracy and efficiency. The application itself is menu driven. This started out from a software package we purchased from Data Dynamics called Active Bar. We have since added a couple of applications around this package, so that the menu structure can be tailored for the individual user, depending upon the privileges granted that user. The immunization program administrator will use the other application to assign new users to the application, controlling the privileges they have. The application is web based, utilizing both Citrix and Nfuse technologies. The only report from the registry is the child’s immunization record. Work is currently underway to define additional reports, both for the provider and the department. We maintain three levels of security. The user must have a computer account with the Vermont Department of Health. The Menuing application controls which portions of the application a particular user can access. The database will only allow access through the application – external access is prohibited.

How did we get here 03/00 – Attended the First NEDSS Conference in Atlanta, GA 10/00 – Developed the design for the first application using this concept. 07/01 – Started implementing a software development process 07/01 – Developed the vision document for the Immunization Registry 12/02 – The pilot version was ready for implementation. We came to the realization in the late 90’s that the Health Department had many disparate applications that were not well integrated. They resided in a character based mainframe and some migration strategy was necessary. It was clear that we needed a defined approach if were going to have any success tackling this huge migration effort. The first NEDSS conference was held about that time and I came away impressed with the concept. We developed our first system a few months later. It was to process surplus foods. The application worked but the process was a disaster. We were plagued with software errors, scope creep, and no change control process. We learned a lot, but the application is no longer We went looking for a software development process in 07/01. By shear coincidence, we picked the same software development process being used by the consultant that was developing the NEDSS concept for the CDC. That process is the Rational Unified Process, offered by IBM – Rational. It was about this time that we threw away our NEDSS-like database that we had created and created a physical database using the first NEDSS logical model that was being distributed by the CDC. The Vermont Immunization Registry project Vision document was produced in July, 2001, and was used as a basis for our pilot system. At that time we were told that our deadline for producing the pilot version was January 1, 2003. We again threw away our database and adopted the CDC released the October, 2001 version of the NEDSS model. That’s the model being used for our current database. The pilot version was ready for distribution in late December 2002. Since that time we have been working with users, adjusting the forecasting algorithm, built a routine to populate the registry with historical birth record information, and have started some new enhancements.

The User Interface Patient Information This is the data entry screen for entering a new patient. We continued to follow the NEDSS concept, by building this software as reusable modules. The software that produces this screen can be reused for any application that must record people demographics. We can capture multiple addresses, multiple types of ID numbers, and different types of contact information. The required fields and their corresponding tabs are shown in red, and are changed to black once the entries are made.

The User Interface Immunization Information This is the Immunization screen. Those immunizations shown in yellow are the history, those in green are recommended by the forecasting algorithm. To record a recommended immunization, double click on a green vaccine will the system prompt the user to fill in the required fields, and the record is added to the child’s record. We added another option so the practice can globally identify the manufacturer and lot number of their current vaccines, and they become the default values.

Where are we going Implementing the NBS, beginning in December. Currently working on improvements to the user interface to expedite data entry. Have initiated a project to incorporate Vital Record Births within the NEDSS (PHIN) environment. Our current schedule has CDC at our site in December to implement the current version of the NEDSS base System. Between now and then and certainly for a period to come, we will be evaluating the effort to have SPHINX and the NBS to become one database. The early pilot release of the registry has resulted in requests to modify the interface to improve the data entry effort. Have just released a Vision document that will work towards the integration of the Vital Record Birth system, following the new NCHS standards and use cases, within the SPHINX environment by January 2005.

What we Learned Don’t change the NEDSS data model – add to it. Develop a change management and requirements management process in place. Maintain a project schedule. Implement the basic system first. Quality is key. Very early, we decided that we would not change the NEDSS data model. All of the data tables and fields have been left in tact. For those areas where our needs were not included in NEDSS, we added additional tables. We are hoping that this endeavor will facilitate the migration between our database and the NEDSS base system. That remains to be proven. Effective change management and requirements management were what allowed us to complete the project in the allotted time. Without being able to effectively manage change requests and keep track of the necessary software requirements, we would have not been able to meet this deadline. The project schedule was key. Once you get behind schedule, it’s imperative that the schedule be revisited to determine if the project can catch up, or if there are features that must be dropped in order to meet the required deadline. If you don’t have a schedule, its nearly impossible to measure current progress against the established deadline. We learned to stop trying to implement all of the features at once. This approach tends to contribute to late deliveries, promotes scope creep, and frustrated users. Implementing a partial system allows you to start getting user feedback while continuing to work on other enhancements. Those features that are included in the initial release of software must still be of very high quality.

Contact Information Ed Andrus Vermont Department of Health 108 Cherry Street P.O. Box 70 Burlington, VT 05402 eandrus@vdh.state.vt.us (802)865-7782 Feel free to contact me for clarification or questions of any of the material that I have presented here Thank you for allowing me to be a part of your conference.