Content development took place in two stages. During the first stage, the work group selected 10 of the originally identified 55 indicators to develop a prototype. The 10 indicators were as follows: 1) diabetes prevalence, 2) annual hemoglobin A1c test, 3) annual influenza vaccination, 4) pneumococcal vaccination, 5) level of diabetes education, 6) diabetes-related hospitalizations, 7) prevalence of end-stage renal disease, 8) hospitalization for lower extremity amputations, 9) physical inactivity, and 10) overweight. Because members of the work group lived in different states, discussions were conducted through a series of telephone conferences and two in-person meetings.

During the second stage, the work group selected an additional 28 indicators from the original 55 through a two-round modified Delphi process. Indicators were ranked in priority according to the following four criteria:

The typical reason for excluding an indicator was that no state-level data source could be identified to measure it. A list of indicators that were excluded and the rationale for excluding them can be found on the DIDIT (available from www.cdc.gov/diabetes/statistics/index.htm). All 10 indicators used to develop the prototype as well as all 28 selected during the second stage were retained, with a total of 38 indicators selected for inclusion. At this stage, the selection of fields to describe each indicator (e.g., definitions of indicators) and data source (e.g., its methodology for data collection, data access) was also finalized with input from the DIDIT work group.

After selecting indicators, associated data sources, and their related fields of information, the DIDIT team, including work group members, contractors for both content and Web site development, and DDT leaders, met in January 2003 (Table 1). The major focus of the meeting was to develop a process to ensure that the information included in the DIDIT was accurate and complete. The work group viewed the Web-based prototype with 10 indicators and eight associated data sources. Each work group member was assigned a set of indicators from the group of 38 to review and revise.

During content development, a contractor researched information on selected indicators and their associated data sources, and the work group provided feedback on its accuracy and completeness. Comments and suggestions on content were discussed during monthly conference calls, and the content was approved by all work group members before it was finalized. A second in-person meeting was held to review and refine content and to ensure that the process of reviewing content was efficient and effective. The protocol for developing and refining content resulted in valuable end-user feedback. Development of the Web-based application took place at the same time as development of content.

The primary purpose of project planning was to articulate the objectives and scope of the DIDIT and ensure the technical feasibility of the system. We noted previously that the purpose and vision for the DIDIT were defined early during the concept development phase. During the project planning phase, the work group articulated the purpose and vision to the technical contractors, and they produced a document that outlined the definition and scope of the project; this document served as a blueprint for system development efforts. Additional activities in this phase included confirming the project's operational and organizational feasibility, developing a schedule, estimating costs, and allocating resources. The project planning phase culminated in the development of a final project plan, which was reviewed by the project lead and management staff. After the plan was approved, technical development efforts, or systems analysis, for the DIDIT were initiated.

The analysis phase defined in detail what the information system needed to accomplish to provide users with the benefits they desired. Several storyboards were created to display preliminary design options for Web page content and format. The storyboards were uploaded onto a secure Internet site to allow sharing among and feedback from a geographically dispersed user group. As design options were presented, users were quickly able to provide comments. An iterative feedback process allowed further revisions to DIDIT storyboards. System requirements were prioritized as they were identified. The analysis phase culminated with the development of model diagrams, which were used to drive the next phase, system design.

While the analysis phase focused on what the system should do, the design phase focused on how the system should function. Information from the analysis phase was used to design the application, the database, the user interface, and the operating environment. The application and database were designed in parallel with the user interface. The user interface is a critical component because it ensures ease of use. It was designed with stakeholder input to ensure that the final product would reflect stakeholder needs.

During the implementation phase, a demonstration model was built, tested, and released with information on the 10 pilot indicators and associated data sources. The model included core functionalities such as the ability to browse, sort, and search, and it was demonstrated at the first in-person work group meeting in early 2003. Input was solicited on additional features, including the addition of DPCP-specific data sources, system-searching functions, and report formats.

The project lead effectively solicited the interest and support of DDT management to ensure that financial and staff resources were available to develop the new tool. To sustain interest and support of management, the project lead presented draft content and DIDIT prototypes at various CDC and national public health meetings throughout the development process (Table 1). These presentations allowed management to realize the high level of interest among prospective users and the potential for the DIDIT as an important tool for diabetes surveillance. Updates were also shared with DDT management on an ongoing basis.

Development of a comprehensive reference tool such as the DIDIT requires a commitment of time and resources. The management of the DDT supported allocation of resources and time needed to create the DIDIT.

The DIDIT project lead had a clear vision of the type of tool that would fulfill the surveillance needs of the DPCP and the DDT. A strength of the project lead was her ability to communicate the vision of the DIDIT to the project team and stakeholders throughout the development process.

Development of the DIDIT involved input from stakeholders across the country. Clear and ongoing communication among stakeholders was essential to the development process. During the first in-person work group meeting, we learned that face-to-face interactions were highly appreciated by work group members and that these interactions helped build rapport among members. In-person meetings were arranged at national conferences to avoid issues of travel approval and costs. Timelines and other defined plans facilitated collaboration. A contractor who was skillful at organizing materials, facilitating meetings, motivating work group members, and responding to the needs of work group members was also essential. Because the work group volunteered its time to create the DIDIT, efforts were made to minimize the burden placed on its members. Minimizing this burden helped to maintain a core group of members who have actively participated for more than 3 years.

Development of both content and Web application took place incrementally and iteratively. Members of the work group reviewed the content in phases, allowing the content contractor to apply feedback to subsequent phases. Similarly, because an incremental process was conducted that involved analysis, design, and implementation at the same time, the contractors were able to make a demonstration model of the DIDIT during the early phases of development, which facilitated refinements to its content and design. Working with an actual tool triggered ideas among users for additional functions and alternative designs that may have been overlooked at the prototyping stage. A model also allowed us to obtain user input on database-driven features such as system searches.