• The Delivery System as Surveillance Partner - Hope or Hype? 8
• Update on NEDSS Extramural Activities 9
• The Base System: Implementation of NEDSS Standards and an Option for Use 9

B. The Delivery System as Surveillance Partner--Hope or Hype?

Richard Platt, Professor of Ambulatory Care and Prevention, Harvard Medical School, Harvard Vanguard Medical Associates, and Harvard Pilgrim Health Care

Modern public health surveillance challenges include bioterrorism, anti-microbial resistance, emerging infections, and influenza. The health care delivery system can play a vital role in meeting these challenges, particularly in generating needed data, but public health must carefully think out the strategies they use to get the cooperation of the delivery sector. Those who deliver health care are very busy. Reporting public health information is low on the list of challenges and opportunities they face. They often forget what is reportable by law and have different ideas about what is of public health significance. Faced with burdensome demands for providing information to others, their major concerns are providing information that helps them deliver quality health care and get paid for their services. They also have concerns about privacy and liability. However, managed health care plans have much in common with public health activities in several important respects, and we can build on these commonalities. They serve defined populations, acknowledge prevention as an important part of health care delivery, have limited resources, collect and use data, and can intervene to improve the health of the populations they serve.

Dr. Platt described preliminary data from a series of pilot programs that he and others had carried out in Eastern Massachusetts. These programs evaluated data from managed care organizations and compared it to data reported to public health agencies, demonstrating that pharmacy records and claims forms can supplement reporting of diseases like tuberculosis (TB) to health departments. Pharmacy reports of prescriptions for two or more commonly used drugs for TB were a particularly sensitive method of identifying unreported cases. For detection of respiratory diseases, chest x-ray records were another source for finding unreported cases, although physicians often manage Lower Respiratory Infections (LRI) without benefit of chest x-ray. Preliminary work has been done to compare ambulatory visit codes by census tract for certain LRI with reports of influenza, TB, and other respiratory diseases. LRI reports matched expected national influenza time trends, but correlation with TB cases was not apparent. Further analysis is planned focusing on disease rates, subpopulations, obtaining real-time reports, automated detection of events, and syndromes other than LRI.

Discussion Points

A discussion period followed Dr. Platt' s presentation.

• •Accuracy of Data - Concern was expressed about miscoding of information in the various originating systems. This was acknowledged as a problem and should be evaluated on a case-by-case basis. Some data could be used as a sentinel surveillance system, requiring follow-up investigation and validation. It was noted that miscoding already plagues the public health reporting system.
• •Privacy and Confidentiality - Concern was expressed that using data from these systems for public health purposes might be in conflict with the privacy requirements of the Health Insurance Portability and Accountability Act (HIPAA). These problems were addressed in the Massachusetts project on the rationale of carrying out research and study. An exemption permitting access to identifiable health information for public health purposes is included in HIPAA.
• •Public Access to Surveillance Findings - Can demographic and geographic data about the occurrence of events might routinely be shared with the public? It was suggested that this can be done, but carefully so that individuals are not identified.
• •Collaboration with the Massachusetts Department of Health - The importance of close collaboration between public health agencies and health care providers in exploring uses of health care data was emphasized. Cooperation in Massachusetts was early and ongoing.

• Update on NEDSS Extramural Activities

Bob Pinner, National Center for Infectious Diseases, CDC

Last year, NEDSS funded 12 states to develop NEDSS data elements, 2 states as charter sites, and 36 sites to complete assessment and planning activities. There were more requests for funding than expected and a large number of jurisdictions are currently involved in NEDSS development or ready to begin development. Extramural funding totals for this year are approximately $21.6 million. The goal is to fund as many sites as possible and add new element development sites and charter sites. However, the average award will decrease from about $450,000 to $333,000 per site. Work on the NEDSS Base System, which will provide software that implements NEDSS standards and supports integration, is also well under way. States will have the option to propose use of the Base System in the FY 2001 Grant Proposal. Questions about the awards should be directed to Dr. Pinner (Rpinner@cdc.gov).

• The Base System: Implementation of NEDSS Standards and an Option for Use

John Loonsk, Associate Director for Informatics, CDC

Mike Rigden, Computer Sciences Corporation (CSC)

Dr. Loonsk opened the discussion of the Base System by providing an overview of future goals for the system. The first step is to move from "Conceptual Standards" to "Concrete Standards" in the development of the Base System. There is a strong drive toward using national standards wherever possible, but ensuring that they meet public health needs as well. It is also important to realize that the standards will change as the information technology industry grows and matures.

Figure 1 shows a schematic of the NEDSS system architecture. Aspects of the architecture include security, a messaging component, integration broker technology, a core integrated data repository, a shareable directory of public health personnel, and transportable business logic. The system should be modular to the degree possible; the goal is to set up a scalable platform for sharing data. The architecture elements will use industry and de facto standards, but will try to minimize the dependency on any one commercial-off-the-shelf (COTS) software. The intent is to build the NEDSS system around elements that are functionally and technically defined, have de facto standards, facilitate the use of commercial software, minimize dependency on a particular software, and facilitate exit strategies for using new software later.

The Base System software is broken down into the Core Demographic Module (CDM), Nationally Notifiable Disease Module (NNDM), core data and systems functions to support program area modules (PAMs), and a limited electronic lab reporting system. The commercial software products involved are a SilverStream application server, Eclipsys E-link messaging tool, VeriSign digital certificates, Statistical Analysis Software (SAS) for analysis, and potentially others as the Base System develops. Dr. Loonsk expects that all applications of the Base System will fit on a

single application server machine. The system will interface with the state's Integrated Data Repository (IDR) using current Oracle structure query language (SQL) Server Database Management System (DBMS) software though the Java Database Connectivity (JDBC) and SQL standards. Data will be exchanged with the CDC through the application server vis HL7 Version 3.0-based. In addition, CDC will collect and disseminate the data through Health Level 7 (HL7) 2.3 format from large clinical labs to states in a "route not read" fashion. See Figure 2 for a graphical depiction of this process.

In order to be functional, the system needs to be a flow of information among the web modules. The state can receive information for the Base System's CDM and PAMs using eXtensible Markup Language (XML) messaging and eXtensible Stylesheet Language (XSL) templates. Transfer of data between the states and the CDC will use strong security standards. The goal is to have the Base System integrate well with existing firewalls without opening holes. The Base System also plans to use the state's existing authentication message, whether it is token- or certificate-based for Internet access or a username/password combination for Intranet access. Information will be transported across the Internet using secure pipelines and field level encryption and VeriSign digital certificates ensuring an audit trail. Messaging hubs located at the state and the CDC will use Health Level 7 (HL7)-compliant XML to transfer data bi-directionally. Figure 3 shows these hubs in reference to the state and CDC firewalls. The CDC hub will be in front of the main firewall, but behind another for security purposes. If a state lacks the necessary security infrastructure to use the Internet, the Base System can function using a state Intranet.

Mr. Mike Rigden continued the presentation by describing the application functionality of the Base System. The Base System is a set of enabling technologies needed to solve business value issues. The process used for refining NEDSS functionality consists of a discovery phase, a preliminary design phase, and an application functionality phase. The application functionality will include program

management, person-based surveillance, aggregate surveillance, person intervention, population identification, and intervention. The first release of the NEDSS Base System will focus on some but not all of these areas.

Mr. Rigden's discussion focused on person surveillance. The key process model concepts for person surveillance include:

• •Multiple types of Entities (Persons, Non-Person living subjects, Organizations, Groups, Materials, and Places
• •Each type of entity can include multiple types of roles and close-entity role relationships can be related to specific activities that they perform.
• •Multiple types of Activities: Observations (lab results, clinical results, field reports, etc.), Investigation Work-Ups, Cases, Notifications, Patient Encounters, Interventions, and Referrals.

Current surveillance systems provide the entry and reporting of observations (events) but do not provide support for work-flow management and collaboration. The Base System will allow for the entering of events observations, creation and management of work-ups, bulk data entry of paper form-based Case Reports, Notifications, Analysis, Visualization, Reporting, investigator work-flow queues, automatic capture and routing of electronic lab and clinical results.

The presenters briefly discussed some of the other functional issues of the NEDSS Base System. Additional details can be found in Mr. Rigden's PowerPoint presentation in Appendix C.

In conclusion, the presenters remarked that the Base System should be viewed as a package containing architecture systems and services, messaging standards, integrated repository standards, a set of software code from CDC, packaging of support for Integrated Data Repositories (IDRs), registry management, and direct assistance via grants for base system integration support. In June 2001, there will be integration testing of the base system in one to three states followed by a beta release sometime after October 2001. A series of program modules that will sit on top of Base System will be available at that time. The process for development of the base system requires state involvement in developing core modules. Therefore, state feedback is critical and necessary to the development of the system. States can provided feedback on the draft requirements documentation posted on the NEDSS WebBoard

Discussion Points

Following the presentation, there was a question and answer period.

• •IT Issues - States may have problems interacting with their IT people while developing NEDSS. There will be a need to integrate state and Federal resources. At the state level, we will need to help with resources and make intelligent requests for help from IT departments. What are they and what do we say to get help? States will need to commit IT resources and actively collaborate with IT personnel to ensure successful implementation of NEDSS. A software solution is being developed, but use of the Base System will still require state IT capacity.

• •Communication between States - Currently, CDC will route data from commercial labs and will not read identifiers associated with the data. Will state-to-state communications work that way? The ultimate goal is for the NEDSS Base System to support the creation, routing, and receiving of electronic messages from any system that supports the standards that the Base System supports. As a first step, the Base System will support the routing of electronic lab results from national labs through the CDC router and to the states.
• •Unix and the Base System - Will existing Unix systems be able to interface with the Base System? The Base System is independent of operating system. The standards supported by the Base System are supported on all of the major operating systems, including: Unix, Linux, Windows, and MVS. Likewise, the system will support an IDR residing on any Relational Database Management System (RDBMS) that supports the SQL standards. CDC provided software components will operate out of the box on SQL/Server and Oracle DBMS.

• •Messaging - Can states and other agencies use CDC's message software, engine, and security to support our applications? Yes, the license agreement permits the use of these components of the base system. With respect to messaging, the states will need to use to build the Base System, or obtain a development license if they wait to create state specific translators.
• •Compatibility with other Federal Agencies - As the NEDSS Base System is developed, will there be consideration for it being compatible with and able to access state Medicaid databases? NEDSS is meant to use generic standards for data and architecture. Therefore, it could link to Medicaid databases if the standards are compatible. This could also limit a state's reporting burden. It is critical at the state level to consider what the standards-based NEDSS approach could facilitate for other data utilization, including Medicaid. The Health Insurance Portability and Accountability Act (HIPAA) data security standards currently being developed by the Health Care Financing Administration (HCFA) will be incorporated in NEDSS as applicable.
• •Base System Codes - Will Base System codes be made available to states that are not using the Base System? The codes will be available to anyone, but if the codes are changed by the state, they may no longer work with the Base System. As technology advances, the Base System codes will be versioned; it is the state's responsibility to keep track of the various versions of the Base System codes. The goal is to share as much information with the states as possible.

• ---

  WORKGROUP SESSIONS

• Session A: NEDSS to Date

Claire Broome, Senior Advisor for Integrated Health Information Systems, CDC

NEDSS is a set of standards for information systems that will be inter-operable for bioterrorism and epidemics, making rapid responses possible. Preparedness for facilitation detection of bioterrorism or epidemics requires that all partners be part of a surveillance system. The current system in place is inadequate, incomplete, fragmented, and slow. The development of national standards for surveillance systems is currently possible due to progress in technology, standards for health electronic data interchange (outlined in the Health Insurance Portability and Accountability Act (HIPAA)) and funding for NEDSS.

In FY 2000, the National Electronic Disease Surveillance System (NEDSS) was created with $20 million made available for this purpose. Ten million dollars went to 14 states for NEDSS compatible development and to 33 states and 3 metropolitan areas for assessment of current information systems and how they could be modified to meet NEDSS specifications and standards.

At the inaugural NEDSS National Stakeholders' Meeting held in March 2000, long-term objectives for NEDSS were stated:

• •Ongoing, automatic capture and analysis of data.

• •Use of data already available in electronic form

• •Designed around data sources rather than diseases
• •Integration of data from both public health and health care systems.

The steps laid out at that meeting were to establish standards for both data and system architecture that makes NEDSS able to integrate data across jurisdictions. It is necessary to take a collaborative approach across categorical programs and to develop sophisticated security standards to ensure confidentiality.

The Public Health Conceptual Data Model (PHCDM) was developed as the basis for data standards to enhance data exchange capabilities with health care providers and public health partners. It also helps to represent public health data needs to national standards organizations.

There are eight elements in the NEDSS architecture. These elements are defined by industry standards and the standards of existing commercial products. They accommodate the use of commercial software as elements and will allow NEDSS to take advantage of new commercial software development. NEDSS is a web-based system which allows the system to be easily upgraded on the server without upgrading each individual computer. The security system is designed to allow data entry over the Internet, while providing the technical capacity to restrict access to authorized users.

At the request of state health departments, CDC has a contract with Computer Sciences Corporation (CSC), an experienced web software development company, to develop a Base System. The Base System is a NEDSS-compatible system that will be a platform for use at state health departments. It can support a range of program area modules.

Discussion Points

Following Dr. Broome's presentation, the session turned to a group discussion of NEDSS.

• •Updating Current Reporting Systems - The NEDSS reporting system includes sexually transmitted diseases, infectious disease, tuberculosis, HIV, vaccine preventable disease, bioterrorism, etc. A core activity of NEDSS is surveillance, including analysis and reporting of data.

• •Marketing - Several participants suggested that CDC "market" NEDSS with brochures designed to explain the system and its capabilities.
• •Availability of Software - The software that has been developed to date is owned by the government, and therefore is available and free to anyone. CDC would like to see commercial companies develop future software, but the market may be too small to attract the private sector.
• •Contact Person - Information about NEDSS is posted on CDC's website. The Office of Integrated Health Information Systems coordinates these efforts at CDC.
• •Grant Timelines - Concern was voiced that the timelines for NEDSS grant applications are unreasonably short. CDC is trying to make this process simpler by creating a single category for everyone's applications this FY.
• •Facilitating State Information Sharing - CDC is encouraging partners to share experiences and information on the NEDSS WebBoard. State sites can post what they find works or does not work on the WebBoard to facilitate other states' development.
• •Health Level 7 (HL7) - HL7 is currently relevant to NEDSS in two ways: 1) as a messaging format, and 2) as developer of a national standards data model for clinical information,
• •Expanded Staffing Needs - There was concern that this system will require more staff to set up and maintain. Although more state IT capacity is needed, this is related to the central role of information in public health, and the opportunities new IT provides. NEDSS can help states make this investment effectively.

B. Session B1: Integrated Data Repository and Data Modeling Workgroup

Greg Fetter, Minnesota Department of Health

Greg Pierce, National Center for HIV, STD, and TB Prevention, CDC

IDX Corporation Site Visits

Mr. Abdul Malik-Shakir, from IDX Corporation, reported on the site visits by IDX Corporation to the 12 states that were awarded Federal funds to develop integrated data repositories (IDRs). The purpose of the site visits was to meet with primary contacts for the awards, provide states with an opportunity to ask questions, promote the bi-directional understanding of goals, engage in dialogue, identify action items, and establish a communication link.

Common goals were found among the sites. These included electronic reporting of disease, electronic connection of laboratories, and electronic public health records. Some sites had additional long-term goals, including the goal of integration with other state databases. Sites were working on centralized reporting or centralized repository. A few sites were moving on to consolidating lab results and disease data across program areas and a few had progressed to the level of attempting to integrate disease and case data. However, sites were managing the scope of their task by not trying to take on all aspects of IDR development at once.

Common technologies are also guiding states. Oracle, Sybase, SQL, and DB2 were identified as candidates for systems implementation technologies. Proposed data modeling tools included Erwin, Rose, Visio, and ER studio. UNIX, Multiple Virtual Storage (MVS), and Windows NT were widely considered for operating systems. Development tools under consideration include J Builders, SilverStream, Oracle Designer, and Web Sphere. At the design level, there is no incompatible technology tool; however, the Base System will consist of "example" software and designs based on J2EE. Some tools, such as Visual Basic and C++ will be incompatible with the base system because they do not natively run in a J2EE environment. However, if states want to build their own environments, there will not be any incompatible software tool.

The sites did not all take the same development approach. Essentially, three basic approaches were being used: 1) some sites were developing a single integrated database to replacing current program databases; 2) other sites were building a single database with an interface to current programs; and 3) still other sites were developing a "virtual repository" or collection of databases with common identifiers and semantic repositories. Sites were also in various phases of their element development. Most sites remain in the planning and assessment phase, while a few have moved on to confirmation and design. So far, no states have begun beta testing or converted legacy data.

Many opportunities for collaboration were observed during the site visits. These included the following: publishing the first normal form of the Public Health Conceptual Data Model (PHCDM); publishing design guidelines and/or a common IDR logical model; working with common definitions and data models; sharing reusable business logic for person-case matching and Geographical Information System (GIS); and sharing findings from the reverse engineering of CDC-supplied software data structures and constraints.

In addition to opportunities, challenges exist for states involved in element development. These include multiple funding sources, addressing local jurisdictional and private interests, converting old data, data security, and end user training.Mr. Shakir cautioned that current plans to fully develop integrated data repositories by October may be overly ambitious. He also noted that limited information technology resources within health departments, large number of stakeholders, limited general resources, and legal constraints may limit the speed of development of IDRs. IDX recommendations to public health departments are to start small and build on successes, collaborate within departments, re-use efforts by other departments, seek to involve local health departments and the private sector, measure success, under commit, over communicate, and celebrate interim achievements.

The next steps IDX identified for itself are to prepare project scope and functional specifications, construct logical data models, conduct assessment of state-developed data models, finalize the site visit report, and publish interim updates. The IDX site visit report completion date was set as April 21, 2001 and the report was subsequently slated to be posted to the WebBoard.

State-by-State Report on Current Status of IDR DevelopmentState representatives from Charter states provided a short status report on NEDSS activity in their state.

• •Ohio: About one-third of the total project is built. The object design is done and testing will begin in one month. A disease reporting event-based system is being built. Web-based access is being expanded in phases to hospitals, laboratories, and health departments. Health Level 7 (HL7) message imports and exports will be used. Subjects covered by the system include demographic, disease, user security, disease programs on a logical level (including surveillance), tuberculosis (TB), and sexually transmitted diseases (STDs). Functionally, the system will provide event review. There will be manual links on person and events. There will be no case management or autolinking of cases. The system will have the capability to search and edit events. Maintenance will take place at locations and jurisdictions will be sharing use. SilverStream is being used as the portal feature for security. Windows 2000, Oracle 816, and J Developer/J2E are being used.

• •Minnesota: The project is still in the assessment and planning phases. The primary work is focusing on modeling surveillance. External stakeholders' meetings are taking place. There will be a surviving legacy database containing HIV data because of cultural challenges. A collaboration has been undertaken with the immunization registry. Oracle 8x is being used.
• •Wisconsin: The project has a clear vision but is still in the planning and assessment phase. There is a great deal of interest in mapping and a virtual repository. There is also interest in capturing vital records. The ideal situation is to have the communicable disease database talking to labs, before rolling out others. The biggest challenge for Wisconsin is getting the word out to programs within the state that communicate with CDC.
• •New York: The state currently has a number of different program areas using electronic reporting. Workgroups have been organized to implement NEDSS. New York will be moving its database design into Erwin. The platform they are using is UNIX. Web Logic, Oracle, Sybase, and Java are also being used. The goal is to develop a virtual database.
• •New Mexico: Development is in the assessment and planning phase. An advisory committee has been formed. The approach is to start small by first working with databases they have control over and then moving into other databases. The project is using Windows 2000, Whistler, Java, and software provided to them by Los Alamos Labs.
• •Utah: The project is in the assessment and planning phase. Process modeling is serving as a starting point. The project is taking the form of developing a single, real, integrated database.
• •Colorado: The state plans to pilot NEDSS using Laboratory Information Management Systems (LIMS) software between laboratories and epidemiologists. Conceptual and logical data models have been completed. The current goal is to ensure that the disease reporting application is working from the same model as the CDC base system. Colorado is using only Microsoft products.
• •Pennsylvania: The project is working with communicable disease and vaccine preventable illnesses using Microsoft and Oracle products. They are thankful for help from New York's and Ohio's project designs. Windows 2000 and Erwin are also being used. The project received $750,000 for web development from the state. The state itself is also the location of a Microsoft public key infrastructure (PKI) development project. They are working to develop their data security.
• •California: The state is starting in the assessment phase. A repository is being developed for HL7 message data from microbial disease labs. Certain reportable disease data are being collected and the project will expand to collect other data. Local health departments and private labs will need to be involved and their collaboration is being sought.
• •Nebraska: A paperless public health lab ordering system is currently in place. No modeling has yet taken place and there is an effort to retrofit previous work.

• •Kentucky: The state currently has a centralized patient repository and is striving toward a single system model. The effort started as an immunization data registry and now has case management capabilities. The initial goal was to eliminate other databases. However, old systems will need to be integrated and data modeling will have to be undertaken.

No representative was available from Oregon or Washington.

Evolution of the Public Health Conceptual Data Model (PHCDM)

Mr. Shakir presented a series of slides on the evolution of the PHCDM. The presentation focused on the changes between versions 1.0 and 1.1 of that model.

The model continues to stay close to the HL7 reference information model, which has also recently been updated, but the PHCDM is not in lock step with the HL7 model. The original model consists of four subject areas: parties, materials, locations, and health-related activities. Referencing graphical representations of the models, the group discussed some of the changes to the HL7 model as well as the PHDCM. The new version of HL7 introduces the concept of "entity" (party and material together), changed participation to roles, borrows the locator term and calls it "location," identifies the physical characteristic of location, calls organizations "entity groups," creates a new class called an "entity role," and has several additional changes from the earlier version. Among the changes made to the PHCDM were the addition of a class code and a health-related activity, deletion of the class of "specimen," the renaming of the class medication to substance administration, and the addition of a secondary association between entity role and entity.

The PHCDM will continue to change. Multiple events will influence the model, such as data types specifications, message specifications, vocabulary specifications, alignment with national standards, and IDRs. In the future, a process for changes to the model will be coordinated by CDC staff, including harmonization with HL7.

Discussion

Under the direction of the moderator, the workgroup moved toward discussing the current status of the PHCDM and the process for reducing through normal forms of the model distributed in the workgroup bearing the title "NNDM-LDM0321D-10--Display 1/Main Subject Area." The moderators indicated that design of the model had not been completed and that the workgroup's input was needed. The model distributed in the workgroup does not contain all the changes referenced in the earlier discussion relating the evolution of both the HL7 model and the PHCDM. Due to the complexity of the model and limited time available, the moderators noted that the group was probably too large to be a working group and scheduled a lunch meeting for the following day to discuss the particulars of the model with those interested.

As a final comment, the moderators noted that an updated version of the model will be released within two months. The model will be placed on the WebBoard and the designers are eager for feedback.

Meeting Outcomes

The Integrated Data Repository Workgroup discussed several topics during its meeting.

• •IDX Corporation has visited all of the technical assistance sites and identifies several common themes. Preliminary recommendations and the IDX report on their findings will be posted to the WebBoard.
• •Ten states reported on their IDR development progress. Five states are in the assessment and planning stages. The other states are at various levels of modeling, prototype testing or in production.
• •IDX Corporation also presented on the evolution of PHCDM. It was clear that there were no drastic changes from version 1.0 to version 1.1. IDX is working to maintain harmony with the HL7 format in the development of PHCDM.
• •CSC presented its progress in the development of the Logical Data Model for NNDM. CSC invited comments and challenges on the draft model they presented at the session. An interim model will be published on the WebBoard in three weeks with the "final" model posted on the WebBoard in five to seven weeks.
• •The IDR Workgroup also held an additional meeting on Wednesday, April 11 in which the reverse engineering of the Tuberculosis Information Management System (TIMS) was discussed. Also addressed was the chance to take advantage of "opportunities" identified during the site visits, e.g., CSC and Ohio developing common core code sets.

C. Session B2: Electronic Messaging

Greg Smith, Washington State Department of Health

Tim Doyle, Epidemiology Program Office, CDC

Sam Groseclose, Epidemiology Program Office, CDC

The workgroup began with a discussion of progress made on objectives or issues established during the January 2001 NEDSS meeting. While a great deal of progress had been made toward accomplishing those objectives, more needs to be done. It was evident that communication between the various disciplines involved (e.g., IT personnel, laboratorians, programs, and managers) needs to be maintained.

Objective 1: Catalog of Ongoing Electronic Reporting and Messaging Projects

• •CDC has compiled a list of electronic messaging projects in the states on the WebBoard. Participants felt that this list needs to be periodically updated.

• •Laboratory personnel indicated a desire to know what progress is being made as they are not involved in the daily electronic reporting and messaging activities.

• •Samples of the projects could also be posted on the WebBoard, which would provide a snap shot idea of what is going on. This should spur interaction among states and increase responses.

It was concluded at the end of the discussion of Objective 1 that a catalog is needed. States need a way to exchange information with their data trading partners. CDC could start this process by routinely posting changes or updates on the WebBoard.

Objective 2: Share Information on Product Evaluations and License Agreements

• •The Base System will include a license for a messaging tool to interchange messages with multi-jurisdiction labs and CDC.
• •The evaluation of products and the criteria used for this evaluation are fairly informal; useful information may require a pilot implementation. People that have information post it on the WebBoard. CDC needs to be careful that when something is posted (either good or bad), that it is not construed as an endorsement. CDC has a much broader implementation plan than the states, so their "evaluations" may not be appropriate for the "small package" states. CDC can talk to the states individually about the criteria they used to evaluate eLink, eGate, eBiz. The states should also look at their functional requirements and do a feasibility study. The goal is to obtain different perspectives.
• •Thirty-six states are in the process of assessment planning/evaluation and it would be good to know their results. It was suggested that CDC could get a CSTE-type organization to post the results or progress to date to reduce the issue of endorsement. Assessments that have been performed will be used by the states to determine where they are in the process; CDC also can use the information to determine where the states are.

Objective 3: Input on Standard Formats/Messages for Electronic Reporting

It is necessary that messaging work with Integrated Data Repositories (IDRs).

• •eXtensible Markup Language (XML) - The role of XML in messaging has not been clarified yet. Some participants feel that a "white paper" needs to be developed. XML is good for encoding messages and could serve as a format for storing documents. However, a clearer scope of what it should do is needed. XML is already working in HL7 messaging, enabling the encoding into versions 2.3 and 3.0.

• •Systemized Nomenclature of Medicine (SNOMED) - A description of how to obtain SNOMED authorization is on the web. There are three tables that have been authorized for use: 1) living organisms, 2) modifiers, and 3) disease (including all that are reportable). Initially, SNOMED was thought to be more robust but, in actuality, it is not. Any suggestions for improvement would be greatly appreciated. In a comparison of NEDSS event codes to the SNOMED disease listings, 75% of NEDSS events codes were found. Some of the items not found are unique to public health and SNOMED would be willing to add these to their disease listing. ICD codes could probably not be fixed to relate to SNOMED. Additionally, the Health Care Financing Administration (HCFA) felt that insurance companies would likely use terms like "suspect" inappropriately. There was some brief discussion about mapping that is done by the states, the use of two sets of codes, and the need to continue to improve the SNOMED version 3.0. Probably the best thing to do with coding is to move to Federal licensing of SNOMED. If SNOMED were used by the states to evaluate their own reporting issues, it would likely be legal under the licensing agreement. CDC sent the authorization forms for SNOMED to the states; they were signed and returned to CDC. This process not only created a record of the authorization but also identified a single point of contact. Once approved, the state will submit a list of not more than 100 laboratories that will be allowed to participate. The process for renewal of the license is being worked on now. CDC needs to know who is using SNOMED. CDC will also work directly with the national laboratories such as Lab Corps and Quest Diagnostics.

NEDSS Electronic Messaging - Messaging Methodology: Requirements for Messaging

Following the discussion of the workgroups objective, Mead Walker from IDX Corporation spoke to the workgroup on NEDSS electronic messaging.

NEDSS requirement of standard messaging and communication in public health involves state and local health departments, health care providers, reference laboratories, and CDC - at a minimum. In order to have efficient communication, standards must be used and must consider of the uniqueness of public health and its relationship with the wider medical community.

Electronic communication is an area of great activity. The Health Insurance Portability and Accountability Act (HIPAA) largely mandates the use of Accredited Standards Committee X12 (ASC.X12) yet HL7 is universally used by hospitals and many other health care providers. Using existing standards is vital for effective disease surveillance in that it eases the burden of implementation for reporting laboratories and reduces research and development costs.

Most of the states and many laboratories have experience in NEDSS and the HL7 Unsolicited Observation Report (ORU) to transmit data to health departments and to CDC. HL7 has spent eight years and substantial organizational resources defining a process for message development. The information model plays a central role in taking advantage of the Reference Model Repository. The NEDSS functional requirements are posted on the WebBoard. The tight relationship between the Public Health Conceptual Data Model (PHCDM) and HL7 makes mapping from one to the other much easier. To reconcile conflicts in definition or code, either suggest changes or use another domain.

The Unified Modeling Language (UML) has defined two diagrams that show communication between two objects to support the requirements (use cases) of a system. The Collaboration Diagram captures the parties (objects) within the system and shows the information exchanges needed. The Sequence Diagram shows each party as a vertical bar rather than a box. This allows for focus on the dependencies between messages and on their temporal sequence.

Currently, the flow of information is among state health departments, laboratories, and CDC. All laboratories are pretty much the same in their relationship with state health departments. The state also has the responsibility to identify potential duplicate reports. In addition, an "implementation guide" needs to be developed. Anything beyond the Base System is a "work in progress." For example, hospital reporting needs to be better defined, including specialized areas such as laboratory and medical records. The role of HMOs, additional payers, pharmacies, and the Medicaid Program needs to be clarified.

Wrap-Up

The workgroup wrapped up its meeting with a call for better communication among all the people involved in the development of NEDSS.

Meeting Outcomes

This workgroup discussed a number of issues and developed action plans for each.

• •Three objectives that were developed during the January meeting were revisted during this workgroup session.

• Develop a Catalog of Messaging Projects Underway -- CDC is to compile a list of CDC level messaging projects and post them to the WebBoard. States will then add their own messaging projects to the catalog.
• Share Information on Product Evaluation and Licensing Agreements - The workgroup will use information provided to develop recommendations for CDC on broad use of COTS products.
• Input on Standard Formats and Messagtes - It was determined that collaboration between the IDR workgroup and the electronic messaging workgroup is necessary to facilitate data management issues.

• •SNOMED Update - States need to provide CDC with a prioritized list of local labs that will use SNOMED licenses and coordinate the ditribution of the licenses.
• •NEDSS Base System Message Development - All information on message development activities will be posted to the WebBoard. Meeting attendees are encourages to comments on the model and the type of messages.
• •Notifiable Disease Notification Message Content - A matrix of data elements and coding will be posted on n the WebBoard. Meeting attendees were invited to comment on both the data elements and the codesets used to represent data elements.

D. Session B3: Data Analysis, Visualization and Reporting

Rebecca Johnson, Minnesota Department of Health

Tonya Martin, National Center for HIV, STD and TB Prevention, CDC

The session opened with an overview of the Data Analysis, Visualization and Reporting (AVR) System workgroup. The goal of this system is to make surveillance data (canned reports, user-defined and customer reports, and datasets) available via the Web and other methods. The use of real-time surveillance data and architecture not only permits sharing, but also addresses security and data user concerns. The moderators encouraged participation in the AVR conference on the CDC WebBoard, where CDC and Minnesota have posted criteria for selecting and testing AVR products. The Minnesota criteria includes: ease of use, degree of documentation, analytic capabilities, and the type of assistance and training available.

SAS Institute Update

Ms. Hope Toupin from the SAS Institute (SAS) reviewed the current status of the licencing agreement between the Department of Health and Human Services (DHHS) and SAS. Language originally in the agreement allowed DHHS grantees to have access to SAS software for analyzing and presenting NEDSS data. Unfortunately, this language was removed, but efforts are underway to reinstate the original language in the agreement. Some restrictions may be added to limit access to only certain software applications. Meanwhile, CDC and SAS are investigating interim provisions for NEDSS grantees. Ms. Toupin also said that SAS would be providing more information to the states on available SAS products and functional applications.

Demonstrations of AVR Applications

• •SAS Institute Enterprise Guide - This application allows users to tap the full power of the SAS system with an easy-to-use, task-based, familiar Microsoft graphical user interface. The Guide connects the user's PC to any Version 8 SAS System Server and allows that user to access any data types supported by the SAS system, utilize the execution power of that machine to run any SAS processes, and return professional reports and graphics to the user's PC. Bryan Sheff, from the SAS Institute, used the Enterprise Guide and data from the Indian Health Service to demonstrate the point and click interface using simple dialogs and wizards. Although a windows-based product, data may be pulled from other operating systems and from multiple sources into a single table. There is also a built-in quality check to assure that no data are lost during transmission. For user defined reports, the Enterprise Guide programs outputs from the whole database not just predefined data - not just predefied data elements.

• •CDC's Epidemiology Program Office (EPO) - This demonstration used data from the National Notifiable Disease Surveillance System (NNDSS) located on an EPO application server. Using a real-time connection from the PC in the conference room to the EPO server, both ad hoc and structured outputs were demonstrated - with data appearing in less than 30 seconds. The demonstration was a "proof of concept" and showed how an authorized user would have direct access to a database and could download data for analytic purposes. Discussion focused on the policy issues involved in establishing such a system within a state, but no clearance currently exists for wider use.

• •New York State Department of Health - In 1997, the Communicable Disease Unit began implementing an Web based electronic reporting system at the local health unit level (LHU). Prior to this time, the system was entirely paper-based. The objectives of the system are to enhance rapid reporting, integrate local and state communicable disease information, and increase public health responsiveness to infectious disease outbreaks. The system was pilot tested in selected counties for six months and then made available to all counties.

Each user signs in and is allowed to perform only specified functions. For example, STD staff are allowed entry only to the STD areas of the system. There are built in quality checks, and supplemental data screens are available for special collections. LHUs are able to download copies of the state reporting form to print and distribute to providers, helping to ensure adoption of the latest revisions. The system is established on a SAS background and users are able to develop a variety of outputs. The state also has a public web site with a full report menu.

Currently 44 of 57 counties are actively using the system. There is currently no laboratory participation, but a pilot test is underway. The primary cost relates to the initial technical assistance and training required to establish the system. Maintenance cost are minimal and are borne by the State Department of Health. LHUs must run dual systems until they achieve a consistent error rate of less than 3%.

The primary benefits of the system have been:

• •Decreased reporting lag (time elapsed from the report to the LHU to the State Department of Health has been reduced from 11 days to 5 days among those LHUs using the system)
• •Presence of a uniform database
• •Ease of case report submission and updates
• •LHU query capability
• •Readily accessible state reports
• •Increased confidentiality
• •Greater flexibility
• •Establishment of a common interface for multiple applications

Implementing Geographical Information System (GIS)

Several workshop members asked for advice in implementing GIS. There was general discussion about successes experienced by Connecticut and Minnesota with environmental health issues. The Web site of the Agency for Toxic Substances and Disease Registry (ATSDR) was also cited as a good source for information.

Wrap-Up

The session concluded with recommendations for next steps to:

• •Broaden representation
• •Share evaluation criteria for tools
• •Exchange information and experiences in testing and/or implementing tools
• •Share templates, routines, etc.
• •Use the NEDSS WebBoard and conference call for communication.

Meeting Outcomes

• •During a brief overview of the AVR Workgroup, it was suggested that evaluation criteria for evaluating products for analysis developed by states and/or CDC develop should be post to the WebBoard.
• •Even though language that included DHHS grantees in the SAS licensing agreement was removed, there is an effort to reinstate it. In the meantime, SAS and CDC are investigating interim provisions for grantees.
• •There were several demonstrations of products during this workgroup session.

• A brief presentation on the SAS Enterprise Guide and SAS/Internet application for the Indian Health Service project.

• Representatives from CDC conducted a proof-of -concept using the SAS/Internet product showing that it can be c=used to develop a web-based application. By accessing the National Notifiable Disease Surveillance System (NNDSS) during the presentation and conducting structure/ad hoc queries , they were able to demonstrate what can be accomplished in a short development time period..
• A representative from New York State demonstrated a communicable disease reporting wen-based system that was developed a few years ago.

• •A few next steps were also identified.

• To continue to share with grantees and others through the NEDSS WebBoard what is happening concerning the development of AVR routines. templates, etc.
• For CDC to continue working with SAS to develop a broad template that would meed the reporting needs of states and locals.
• To address issues around security, confidentiality and appropriate data use.

• Session B4: Security

Ivan Gotham, New York State Department of Health

Meeting Outcomes

• •CDC is committed to building base-infrastructure for public health across the United States. This infrastructure is focused around information technology, public health workforce, and organizational capacity. CDC is accomplishing this through HAN, NEDSS, and the Frist-Kennedy Bill of 2000.
• •The U.S. Congress is also committed to building public health infrastructure by providing funds through HAN, NEDSS and the Frist-Kennedy Bill of 2000.
• •The state of Massachusetts is in the process of developing a HAN portal that is user-friendly and will be used on a daily basis. Massachusetts approached the issue of building the infrastructure by partnering with tobacco control who had IT needs and money to spend.
• •The state of Colorado is developing an electronic surveillance system focusing on long-term needs. In choosing tools utilized by the system, Colorado did not base their decision on technology, but rather on existing staff that could support those tools. One obstacle that Colorado faced was locating money to build the infrastructure. Colorado received money from HAN and NEDSS, but also found additional funds from programs that adopted the surveillance system in the early stages of development.

C. Panel C: Opportunities for Public Health through Vital Statistics and NEDSS

Moderators: Alvin Onaka, Hawaii State Department of Health, National Association of Public Health Statistics and Information Systems

Mary Lou Lindegren, National Center for HIV, STD and TB Prevention, CDC

This session focused on the role and implementation of electronic birth and death records for NEDSS and surveillance. The panelist for this session were Delton Atkinson from the National Association for Public Health Statistics (NAPHSIS), Garland Land from the Missouri Department of Health, Pamela Akison also from NAPHSIS, and Mary Ann Freedman from the National Center for Health Statistics.

Delton Atkinson - NEDSS and Vital Statistics

Mr. Atkinson began by asking whether a NEDSS-vital statistics partnership is a new frontier. Vital statistics is the oldest system in public health statistics, and is both an administrative system and surveillance system. As a system for gathering surveillance data, vital statistics provides data on births and deaths, and should provide data that are of high quality, cause minimal burden and are easily accessible. As an administrative system, vital records have multiple legal functions; concerns include: lost or stolen certificates, fraudulent use, amendment, issuance and customer satisfaction.

There is a need to link the administrative and surveillance aspects of vital records to NEDSS and NEDSS uses. Reengineering or "e-vitals" is one way to link these two systems. Such a reengineering would recognize the perceived limitations of vital records, such as, inadequate access, legal restrictions, inadequate customer service, reliance on paper records, the lack of state of the art technology, and surveillance limitations including timeliness, quality, and burden on the provider. Reengineering should provide rapid issuance and reporting across transaction types (Government to Client, Government to Government, Government to Business, Client to Business), and instant feedback to providers of data.

The difficulty lies in how to accomplish these goals without wasting time, while simultaneously preventing fraud, maintaining strong security procedures, improving customer service, and automating population of other systems. A reengineered administrative system will provide a sound surveillance system by design alone. Getting to this reengineered system will require partnering, process and data standards and a focus on electronic systems. The next steps in moving toward that reengineered system are:

• •an improved understanding of vital statistics
• •pilot implementations of E-systems with standards and electronic interchange
• •consensus on data standards for web dissemination, and
• •partnerships in an e-vital statistics world that will bring together essential communities.

Garland Land - Opportunities for Public Health through Births and NEDSS

Dr. Land spoke about the current strengths of birth records in most states. In Missouri, birth certificate data already have enhanced data sharing around infant deaths; immunization registries; birth defects; newborn screening and newborn hearing; women, children and infants; Medicaid; hospital discharges; special health care needs; lead; and STDs. Birth records are fundamental building blocks for other programs sponsored by CDC, United States Department of Agriculture (USDA), Health Resources and Services Administration (HRSA), and the Social Security Administration. Therefore, birth records could be the hub for an integrated data repository and need to be considered within the NEDSS system. Federal agencies should collaborate to support integrated birth information systems, not just reportable diseases, in a single system.

Pamela Akison - Death Records: The Ultimate Outcome of the Dataset

Dr. Akison discussed the differences between death and birth records. Unlike birth records, death records are rarely reported in an electronic form. Death records, like birth records and all vital records, serve as both legal records and surveillance data. Moreover, death records are not a target for archiving because they must be kept forever, making the need even greater for electronic formatting. Death records can serve as key public health statistics and provide cause of death data that will perhaps lead to recognition of unrecognized diseases. Death records need to be linked to other registries for outcome analyses. Unusual partners are needed to reengineer death records because funeral directors enter demographic information, while physicians and coroners enter the cause of death. Speed is of the essence with death records as they must be completed within 3 days of death and prior to burial.

The Social Security Administration is piloting the Electronic Death Registration System (EDRS). This pilot system will verify social security numbers online and report deaths within 24 hours. It is being built on current and evolving standards including the Public Health Conceptual Data Model (PHCDM) and the Health Insurance Portability and Accountability Act (HIPAA) requirements for security, privacy and digital authentication. EDRS is being designed to be compatible with NEDSS in recognition of the importance of integration.

Mary Anne Freedman - Vital Statistics the National Perspective

Dr. Freedman addressed the statistical uses of vital statistics rather than the legal components. There is no Federal law controlling vital statistics; rather, the system is decentralized and based in state and local law. Discussion about vital statistics can be broken down into timeliness, standards, strengths and weaknesses, and future direction. The timeliness of vital statistics is critical and depends on data flow, interventions at each step of collection, transmissibility, and level of responsiveness at a state and national level. Standards - such as standard vital certificates, model laws, and data specifications - are necessary if the timeliness of data are to be improved. There are a number of strengths and weaknesses associated with the current collection of vital records as surveillance data. Decentralization, "weakest link" issues, and resistance to change are problematic. On the plus side, however, there is a great opportunity for cooperative partnerships, the data have great analytic strength, and there is a long history of vital statistics collection. Future goals must include the reengineering of the birth and death systems through process change, the implementation of new standards, and improvement on work completed so far.

Meeting Outcomes

• •Currently, the vital statistics system is not technologically advanced. Death, fetal death and induced abortion registration systems are paper-based. Although birth registration is an electronic system, it is based on 1970s technology and varies from state to state.
• •There are several common goals between NEDSS and a re-engineered vital statistics system: create data standards, reduce data development efforts, enhance data sharing, representing public health data needs to national standards setting bodies and facilitate collaboration between CDC and its state and local partners.
• •A major theme in this panel discussion was the integration of vital statistics into NEDSS in order to communicate with other information systems to enhance data sharing. The panelists characterized the vital statistics system as serving two functions: one, a public health surveillance systems including notifiable diseases, maternal and child health data needs and chronic disease registries; and two, an administrative data source for federal agencies such as the Social Security Administration and for child support enforcement.
• •Using birth certificates as a hub for information, an integrated data repository could be a data source for the statistics on women, infants, and children; lead testing; new born screening; new born hearing; birth defects; immunizations; and SHCN.
• •Immediate next steps identified by the panel are to include an article about this NEDSS conference in the NAPHSIS April newsletter and brief the attendees of the NAPHSIS/NCHS Annual Meeting in May on NEDSS and common goals with vital statistics.
• •Long-term next steps are to convene a CDC/NAPHSIS planning meeting in order to develop an action plan, identify strategies to include other federal partners, develop a NEDSS process model, identify pilot projects and share outputs with states.

D. Panel D: Policy Issues Around NEDSS: Data Sharing, Access and Confidentiality

Moderators: Gianfranco Pezzino, Kansas Department of Health and Environment

Dan Jernigan, National Center for Infectious Diseases, CDC

It is hoped that the implementation of NEDSS will increase the efficiency and rapidity of public health access to needed data. This session discussed some of the policies and options available for sharing data and protecting its confidentiality, and described how these issues have been addressed in some state public health agencies. Dan Jernigan from the National Center for Infectious Diseases, Jac Davies from the

Washington State Department of Health and Perry Smith from the New York State Department of Health addressed policy issues, technical solutions and the direct implementation of NEDSS.

Dan Jernigan - Policy Issues Around NEDSS: Electronic Lab-Based Reporting (ELR)

States have varying requirements for reporting findings for public health importance. Additionally, there are separate requirements for clinical providers and laboratory providers . Electronic Laboratory-Based Reporting (ELR) will improve the timeliness and completeness of disease reporting. Both NEDSS and the Base System have an ELR function in its design. ELR helps reporting move towards a more integrated environment and automates the capture and transmittal of information. State and Federal laws have varying requirements for how information is handled, who has access, and what method is used for reporting. For the NEDSS system, standards will need to be developed for consistency among all states. There are clear benefits in moving lab-reporting systems from paper to electronic format. After the initial setup, an ELR uses fewer personnel, saves time with efficiency, and make content easier to transmit. With encryption and audit trails, electronic formats are ultimately more secure than paper.

There are also several requirements for ELR in NEDSS Base System, functionally and technically. Information must comply with the state standards regarding routing and security. Several layers of encryption may be needed to allow only the parts of the record intended for a recipient to be reviewed. The system ensures secure transferal over the Internet by using secure pipelines between the state and CDC. Communication between national labs and states will be routed through a hub, but not read to ensure privacy. The technical standards considered at this point are SilverStream application servers, E-link translators, Health Level 7 (HL7)-compliant eXtensible Markup Language (XML) as a messaging format or Systemized Nonmenclature of Medicine (SNOMED) as data types.

Jac Davies - Data Sharing Issues in the Age of NEDSS

Ms. Davies discussed data sharing issues and how various policies affect NEDSS. Nearly every state has different policies on data sharing based on the type of data involved. For example policies for HIV data are typically more stringent than for vital statistics. At present, it is acceptable to have differing data sharing policies among states.

The Public Health Issue Management System (PHIMS) in Washington State is similar to NEDSS. The PHIMS acts as an active server page (ASP) for local health departments with the database and application in a central location. Rules and policies ensure proper security and access to various levels of data. For example. some HIV data policies prohibit full integration. Trust must also be established so that local health agencies have confidence their data will be protected.

People and technology must be used to help maintain the rules. Technology can be designed to control data access, but people must enforce those policies to make sure the controls work. For example, when staff change jobs or roles, their access rights also need to be adjusted. It is important to maintain control and to respect who has control. This will promote "buy in" of users and enable a successful system.

In the State of Washington, the Epidemiologic Query and Mapping System (EpiQMS) is a browser-based analysis and geographical information system (GIS)-mapping tool. The current prototype contains death, cancer, hospital discharge and sexually transmitted diseases (STD) data. Users of EpiQMS are assigned an access level when they sign up to use the system. Data stewards determine the appropriate level of access according to the data the user wants, are responsible for controlling that access of users over time.

The future holds both policy challenges and opportunities. The primary challenge is to support technology while keeping in mind that public health needs and rules do not change. New technology affords the opportunity to share data more efficiently, but data sharing agreements should change as technology advances.

Discussion Points

Following Ms. Davies' presentation, there were a few questions from the audience.

• •Vital Statistics Data - In incorporating vital statistics, will the data be collected historically? The vital statistics data are aggregated. As long as the dataset has common attributes, incorporating vital statistics historically can be accomplished. However, there needs to be a reality check to make sure that all data are available.
• •Registry Matching - In performing registry matching with ELR, how are matching and subsets handled? This problem is still being resolved.

Perry Smith - Data Sharing, Access and Confidentiality - The New York Experience

Dr. Perry Smith discussed confidentiality, gave a brief overview of the New York system, and described what is involved in making policy decisions as it relates to technology. In New York, local health departments communicating with clinical labs and providers via secure encrypted links over the Internet. This system requires only an Internet connection and web-browser so is accessible from virtually anywhere. The key to maintaining security is using differential rights and access. There are several layers of access including physical security, firewalls, proxy servers, and application filters to ensure data integrity and proper access. To ensure ease of use, the system utilizes single-sign-on to access data, applications, and web services.

When identifying policy rules, feedback is solicited from Information Systems, Legal, Executive leadership, Local Health Units (LHUs) and the Programs. Policy rules typically stem from the needs of the programs, since the programs house the experts and determine constraints on data access.

Several barriers to implementation were identified:

• •"One size does not fit all" when developing systems.
• •Multiple passwords must be used and security measures established.
• •The system must accommodate changing data needs
• •It is difficult to find enough resources to complete the project and supply ample training.

Lessons learned were to involve system users early in the planning stage and keep them updated. Also, the system should be constructed modularly, starting small and allowing time to grow.

Discussion Points

Following the presentations there was a question and answer period.

• •Role of Local Health Departments - Local health departments are the agencies that really use the information in the surveillance systems; however, most policy language concerns CDC or the state level. How can this issue be resolved? There is a need to pay more attention to the local level and to cater to their policy needs. Language must be included in policies that will accommodate local health departments.
• •Decentralized Security Model vs. Centralized - What model is best? The state of New York has de-centralized security since the state level lacks the resources to do otherwise. Therefore, the program office is responsible for granting access, though there are also checks on this system to ensure that access is being granted correctly.
• •Soft Policy Issues - How are situations handled in which data are misinterpreted? The technology has not changed access to data; thus, the old problems still remain. One solution is to educate and train personnel in how to interpret data correctly. A related issue is trying to decide what information to put on the website.

• •Resources - How many people does it take to develop and maintain these systems? The main development of the system involved only one or two programmers over a long period of time; however, there are several funding streams for programmers, trainers, etc. to use.
• •Tribal Communities - How will tribal communities fit into this system? Like the military, the health facilities will be involved.
• •Value - How can the value of this system be judged, especially with all the money that is being funneled into this project? New York was able to develop a full surveillance system for a specific disease agent (i.e., West Nile Virus) in only a few months. There is value in that.

Meeting Outcomes

• •Linkage of two Databases - As it was presented, there are actually two databases in ODRS. Will these ever become one database? Ohio is working towards integrating the two databases into one database. However, two issues are involved: security and case management. Both of these needs must be met in a single database for all partners to be satisfied. There is hope that the NEDSS modules, especially concerning HIV/STD, can help integrate the two databases.

Xen Santas - NEDSS Relationship with HIV/AIDS Program