Report of the Tracking Network Workgroups Download as PDF [199 Kb]

Attachment B: Final Report Workgroup #2—Data Technology and Tracking Methodology

CDC and ATSDR invited people from inside and outside the government to assist them in developing an Environmental Public Health Tracking Network (EPHTN). The EPHTN, designed to enhance sharing of information and knowledge to allow people to make the best possible health decisions, has received widespread support from local, state and federal public health agencies. CDC, ATSDR, and their tracking partners should address three components critical to understanding the link between the environment and health outcomes:

• Hazards tracking
• Exposure tracking
• Health outcome tracking

The Data Technology and Tracking Methodology Workgroup focused on recommendations that included not just technologies, but also relationships, laws, standards, systems, and applications. The Workgroup also provided recommendations about tools, such as geographic information systems, health statistics, and many forms of communication.

The workgroup believed that the EPHTN should build on the National Electronic Disease Surveillance Systems (NEDSS), perhaps constructed as a program application module and thus fully integrated with other NEDSS program application modules. The workgroup assumed that the EPHTN should be able to:

• Conduct and support Web browser-based data entry and data management
• Accept, route, and process HL7 messages containing laboratory and clinical content
• Implement an integrated data repository
• Develop active data translation and exchange (integration broker) functionality
• Develop transportable business logic capability
• Develop data reporting and visualization capability
• Implement a shareable directory of public health personnel
• Implement a security system and appropriate security policies

The workgroup understood the EPHTN probably will have different developmental and use functions at the state and local levels than at the federal level.

Following are the recommendations of the workgroup.

Recommendation 1

The EPHTN should be developed in cooperation with NEDSS, the Environmental Protection Agency's (EPA's) National Environmental Health Exchange Network (The Exchange Network), and other national data architectures building upon existing partnerships between CDC, ATSDR, and other government, public, and private entities.

Rationale

• To help ensure consistency, compatibility and integration of conceptual and logical models, architects of the EPHTN should actively participate in the NEDSS development project to learn about NEDSS and provide environmental health perspectives to the ongoing NEDSS requirements-gathering processes.
   
• EPHTN architects should adopt existing NEDSS data and messaging standards where applicable. At the same time, they should participate in the NEDSS standards-development processes to help rectify deficiencies related to environmental health tracking.
   
• The EPHTN will benefit from learning and adopting best practices developed by the NEDSS architects. Furthermore, EPHTN architects could mitigate many of the risks by considering NEDSS' lessons learned, especially those resulting from work with such a broad base of stakeholders.

Next Steps

• Identify existing data and systems for feasibility of integration into the EPHTN development process
   
• Evaluate the NEDSS Base System and architectural elements for applicability to EPHTN requirements, and identify additional necessary elements (e.g.; geospatial components)

How does this relate to the RFP?

Proposals received should detail how the funding links NEDSS (CDC), the National Environmental Information Exchange Network (EPA), and other national architectures.

What are the short-term recommendations to CDC and ATSDR?

• Look at NEDSS (CDC) and the Exchange Network (EPA) architectures mentioned and determine whether they are useful tools
   
• Accelerate the integration of the blood lead screening and environmental health surveillance into a NEDSS compatible format
   
• Develop a technical advisory workgroup of experts to further explore EXML schemas, and identify the commonalities between NEDSS (CDC) and the Exchange Network (EPA)
   
• Collaborate to develop a user-friendly version of the technical workbook on NEDSS

What are the long-term recommendations to CDC and ATSDR?

Develop a module that will assist in the integration of NEDSS-compatible systems (CDC) with the Exchange Network (EPA)

Recommendation 2

The EPHTN should consist of a network of distributed data sources, all of which could receive or send data. Data providers should, to the extent possible, maintain their data at their location, in the data's original form, in the data providers' preferred database, and in their preferred formats.

Rationale

• Reinforces the concept that data-sharing is the responsibility of federal, state, and local agencies
   
• Allows information to be collected locally and accessed, queried, and retrieved globally
   
• Preserves the data-providers' ownership of data. Allows data providers to control access to data that meets their local privacy requirements
   
• Probably minimizes the federal agencies' enforcement of state privacy requirements and thus protects data in case of a Freedom of Information Act request
   
• Allows data to be stored in native format, thus maintaining the original purpose of the data collection
   
• Minimizes the likelihood that a data provider will need to commit to reengineering existing systems to work within EPHTN
   
• Provides the ability for translating the native data model of the data provider to other data models
   
• Enables other data models to be either EPHTN standard data models or dynamically user-defined data models
   
• Allows tapping into large number of existing databases in shorter time
   
• Makes data location transparent to users

Next Steps

• Identify and contact for input and ideas the individual providers, industry groups, and other government agencies that support this approach
   
• Resolve the many issues that remain. These include whether one or multiple standard data model should be defined or whether the system should allow for an infinite number of "virtual" data models to be dynamically created; exploration of the pros and cons of the data model options; and research of open architecture standards and best practices.

How does this relate to the RFP?

• Proposed projects should prototype the concept of distributed data sources that moves away from data repositories and toward distributive services
   
• Funding should include pilots to test the integration of NEDSS, EPS'sExchange Network, and other national architectures

What are the short-term recommendations to CDC and ATSDR?

• The technical advisory workgroup suggested under recommendation #1 should explore the issues of integration of systems
   
• Integration completed by the technical advisory workgroup should be a funded project.

What are the long-term recommendations to CDC and ATSDR?

• Choose architecture for implementation and a distributed model from the recommendations of the pilots and the technical advisory workgroup
   
• Measure for baseline information to ascertain where the state is as it relates to integration with the EPHTN; provide technical assistance to states to achieve integration by providing blueprints for measuring how far states need to go to fully integrate and measure success
   
• Create system for continued opportunities for discussion

Recommendation 3

The EPHTN should adopt metadata standards that allow users to find and use data available in the EPHTN.

Rationale

• Provides users the ability to search the Web for EPHTN-related reports and databases
   
• References both spatial and nonspatial components of the data. For example, nonspatial data may include textual and coded records on the clinical measurements of a disease, such as stage of cancer, or documentation of an exposure, such as mercury toxicity. Spatial data would reference geographic location of data such as the spatial distribution of an exposure or disease.
   
• Complies with existing Federal Geographic Data Committee (FGDC) metadata standards and ISO 11179 standards. An example of an ISO Metadata standard can be found on the FGDC website [external link]


Regardless of the metadata profile used (most profiles are searchable across existing data libraries), data documentation is a first step. Without it there is no data sharing and limited accessibility to data resources. Outside of the CDC firewall, and at its highest level of abstraction, one could envision the following EPHTN metadata core elements for documentation and sharing:
 
1. Title
2. Author/ contact/ responsible party
3. Abstract
4. Date of publication of availability
5. Date of last modification
6. Medium (e.g., CD-ROM, URL)
7. Geographic coverage (e.g., state, county, census tract, ZIP code, geocode)
8. Key words (e.g., searchable)
9. Access constraints
10. Use constraints
11. Data dictionaries (data fields and vocabulary)
     
• Enables EPHTN to link historical databases. To accomplish this task, databases need to define the appropriate metadata standards to assign to legacy databases. This will ensure maintenance of data compatibility, documentation of inconsistencies, and management of data files that have been created through different means over time.

Next Steps

• Establish an inventory of metadata standards (i.e., health outcomes, hazards, spatial, and exposures) capability. At a minimum, models include existing FGDC metadata standards and applicable ISO 11179 standards. The inventory should include a description of the appropriate standard and a rational for its application to a specific data source.
   
• Create an appropriate metadata standard-creating mechanisms for selected databases encompassed in the EPHTN. This standard also would include elements unique to the EPHTN (e.g., considered as extensions to existing metadata file elements). The EPHTN task force conceivably would lay the groundwork for a national metadata standard for environmental tracking and health, which easily could be searched through the FGDC Clearinghouse.

The public as well as the scientific community expect CDC and ATSDR information technology to provide easy and rapid access to information and data. A EPHTN metadata repository will fulfill this expectation.

How does this relate to the RFP?

Products of state grants should include metadata that relate to databases created with the funds

What are the short-term recommendations to CDC and ATSDR?

• Work with EPA to develop an agreement regarding metadata standards that would be useful to the EPHTN.
   
• Using the technical advisory workgroup suggested under recommendation #1, explore the issues of metadata standards

What are the long-term recommendations to CDC and ATSDR?

Implement this recommendation

Recommendation 4

EPHTN architects should work with federal partners and private standard-setting organizations to share, create, or modify data processing, performance, and technology standards.

Rationale

• Design of the EPHTN should be based on standards currently in place, but it should also be flexible enough to anticipate future changes and advances in technology and evolutions in standards, including hardware, software, transactions, and data and communications standards.
   
• The EPHTN should be technology-neutral. It should emphasize the functionality needed for environmental health tracking. The system for communications and data exchange should facilitate interchange of data at all stages of readiness and response, as well as for ongoing purposes such as surveillance and tracking of chronic diseases.
   
• The EPHTN should permit data sharing between public health and nonpublic health partners (e.g., hospitals, laboratories, health plans, urgent-care facilities, clinics, and providers).
   
• However, a security infrastructure must be in place to protect the integrity of the data and to recognize several different levels of access, from technical and maintenance and security protocols to clinical care coordination to public access inquiries. For example, the EPHTN should aim to provide public information through having standard FAQs and "off the shelf" answers (e.g., where are disease clusters?) as well as through allowing search engines for more tailored data inquiries from researchers and federal agency staff.

Although the EPHTN's users may be the research community and other stakeholders, the EPHTN should be designed to provide accessible and useful information for policy makers and the public, while observing privacy and security standards.

Next Steps

• Design the EPHTN to incorporate three general domains of indicators: Hazards, Exposures, and Health Effects. Within the Health domain, data sources include laboratories, hospitals, health plans, private providers, and poison control centers, and other sources. Some standards may be unique to one domain; others may apply across sources (e.g., HIPAA privacy standards). Further investigation is needed.
   
• To ensure preparedness, identify and resolve contradictory and overlapping standards. This task is simply too large for any one group to plan or execute alone. Several models exist for standards development. For example, the public sector may require that private-sector standards be observed, as is the case with banking information and health plan data (also known as "deemed status").

Development of the EPHTN is a complex, crosscutting effort that will require a collaborative, team-oriented approach within and across federal agencies.

How does this relate to the RFP?

Projects for pilots should identify which standards have been used for a specific project.

What are the short-term recommendations to CDC and ATSDR?

Inventory and compile a list of applicable standards

What are the long-term recommendations to CDC and ATSDR?

Implement, adopt, and use standards

Recommendation 5

EPHTN architects should adopt a formal technology-neutral methodology for modeling, analysis, and design of the EPHTN. This will provide both an architectural framework and technical guideline for the surveillance facts of the diseases, conditions, environmental hazards, and environmental exposures relevant to the EPHTN. Formal models should be developed to encompass the business model, workflow models, partner models, process models, use case models, options analysis models, data-flow models, and data models.

Rationale

• Ensures that clear lines of organizational barriers, communication, programmatic processing, scientific decisions, and technical implementations can be defined
   
• Documents decisions, defines stakeholders, and guides discussion to formalize these key facets of the network and enable implementers to take advantage of new technologies as the technology become available
   
• Provides improved communication and dialogue with existing models such as the NEDSS Public Health Conceptual Data Model (PHCD) and the Health Level 7 (HL7) Reference Information Model as well as models developed by other organizations

Next Steps

• Perform a tool kit needs-assessment and evaluation for the Unified Modeling Language (UML) methodology and notation to create and support the various models required for the EPHTN
   
• Create and define a formal process to develop formal models for the EPHTN
   
• Link models from the EPHTN to the enterprise architecture framework for the organizations involved in the EPHTN

How does this relate to the RFP?

The grantees should be required to include a project representative to participate in the modeling process

What are the short-term recommendations to CDC and ATSDR?

• Prioritize the model type, and find the methodology
   
• Establish capacity for technical assistance on modeling for the states to use in state projects funded under the RFP
   
• Develop, use, and evaluate case models

What are the long-term recommendations to CDC and ATSDR?

Choose a methodology from knowledge gained from this process

Recommendation 6

The EPHTN should identify, integrate, and make available tools for data analysis, interpretation, and presentation. To the extent possible, data dissemination should use automation tools, such that "the data finds the user" rather than forcing users to repeatedly search for information when new updates are available.

Rationale

EPHTN users, such as researchers, public health professionals, policy developers, members of Congress, public officials from other agencies, and the media, will have widely varying needs and levels of expertise. EPHTN should be available for all types of users and inquiries ranging from locating disease clusters to specific health effects of exposures. Therefore, the EPHTN should make it as simple as possible for those users to request and receive standardized information over the network, while offering advanced functionality for more sophisticated consumers. Essential elements include:

• Answers FAQs, not necessarily data when appropriate
   
• Provides search and retrieval functions and customizable query systems
   
• Links issues through ecologic analysis, thus clarifying strengths and limitations for users
   
• Provides data visualization and exploratory data analysis

 
• Provides export capability to "industry" standard formats such as spreadsheet, database, text file (all nonproprietary)
   
• Provides a clearly defined and available open architecture so users can create tools
   
• Enables online data dissemination accompanied by release of printed standard reports, as appropriate, and electronic versions which should be available in a non-proprietary format (e.g., *. PDF) online
   
• Provides tight integration with NEDSS to allow EPHTN users access to SAS under the NEDSS license

Next Steps

• Define key user groups and their information needs
   
• Develop a conceptual framework for the EPHTN, which will encompass the user interface requirements for accessing and analyzing data, as well as presentation and report writing
   
• Assist with the interpretation and visualization of data for novice users or general audiences to help them make informed decisions
   
• On the basis of user interface and information requirements, identify specific functional components including linkages to pre-existing databases for retrieval
   
• Maintain applicable industry standards and flexibility to anticipate technologic changes

How does this relate to the RFP?

• Funded projects should include use of tools for data analysis, interpretation, and presentation.
  
  
• Grantee development of a public use data set (PUDS) or other accessible and understandable data dissemination, as appropriate, should be encouraged.

What are the short-term recommendations to CDC and ATSDR?

Work with the NEDSS Analysis, Visualization, and Reporting (AVR) team. The NEDSS AVR staff should collaborate with EPHTN staff to accelerate development of tools for data analysis, interpretation, and presentation.

What are the long-term recommendations to CDC and ATSDR?

Make available for data analysis, interpretation, and presentation a suite of options and choices of tools that employ open architecture, and function as "turn-key" systems.

Recommendation 7

Architects of the EPHTN should explore developing relationships with private providers (i.e., physicians, health care plans, pharmacies, emergency departments, poison control centers, and laboratories) to gain access to nontraditional surveillance and tracking sources.

Rationale

• EPHTN will be designed to incorporate three general domains of indicators: hazards, exposures, and health effects. Each of these domains has several data and information sources reporting to different federal, state, and local agencies, ranging from mandatory reporting to voluntary reporting to no reporting.
  
  
• Potential data sources for the EPHTN are fragmented. For example, data on environmental hazards are tracked by ATSDR's Hazardous Substances Emergency Events Surveillance (HSEES) system. Several groups at EPA maintain a variety of databases, such as TRI and others, and generally monitoring is specific to releases of one chemical agent (e.g., chlorine) but without links to exposure.
   
• Exposures (e.g., to chemical agents) are tracked by the Departments of Defense and Veterans Affairs, but the source of exposure is not always clear. (Note: Military data may not be available for public use, but military installations should be included in local public health preparedness planning and exposure monitoring efforts). For example, biomonitoring data generally are available only through NHANES, which only has data from 5000 people nationally; until NCEH state biomonitoring planning grants progress to implementation, this will remain the case.

Next Steps

In addition to NEDSS, two large initiatives are under way that will direct affect the development of the EPHTN in terms of the availability of laboratory, medical, and public health data. Notably, CDC is participating in the eHealth Initiative, a consortium of vendors, health plans, and other industry leaders that are working on connectivity of clinical data systems.

CDC also has developed guidance for state applications for bioterrorism funding provided by Congress. In January 2002, Congress made about $1 billion available to strengthen state and local preparedness for bioterrorism and "other public health emergencies" by upgrading disease reporting systems, increasing hospital and laboratory capacity, and improving communications systems.

• In collaboration with other workgroups and other initiatives at CDC and ATSDR, develop a framework for availability of EPHTN data by sources: already available, in development, not in development
   
• Identify the activities in CDC's eHealth Initiative that could develop infrastructure on which the EPHTN could build
  
  
• Evaluate the impact of CDC's technical guidance that accompanies bioterrorism preparedness funding for states, and identify the data sources and information systems that states are likely to develop and deploy
   
• Develop a strategy to monitor whether states are developing similar systems and models for connectivity of systems, particularly across jurisdictions and types of providers (e.g., data-sharing among hospitals in a metropolitan area)
   
• Develop priorities and a timeline for EPHTN development based on availability of data
   
• Identify exposure information and tracking capacity from poison control centers to integrate them with public health and medical data systems

It should be noted that each of these domains is governed by a variety of standards and is in varying stages of computerized record keeping, so some sources would be available sooner for building a protype of the EPHTN than other sources.

How does this relate to the RFP?

• The RFP should strongly encourage collaboration with private partners
   
• The RFP should strongly encourage collaboration with other government agencies that are not among the usual public health partners.

What are the short-term recommendations to CDC and ATSDR?

Inventory private data sources

What are the long-term recommendations to CDC and ATSDR?

• Develop relationships with private partners that are formal data sharing partnerships
   
• Integrate data from these sources into the EPHTN

Recommendation 8

EPHTN architects should ensure data-sharing agreements exist between relevant agencies at the state and federal levels. These interagency agreements, or memoranda of understanding (MOU), allow the agencies that collect data under specific legal authority to release those data to the agencies that need them for policy development and program planning (e.g., state, local, EPA, NIH, poison control centers, USGS, NOAA, NASA, DOE).

Rationale

• Protect integrity of its data transactions, guide data transaction security provisions, and schedule data submissions
   
• Outline the expectations for adherence to common data standards and technical infrastructures, and the means to define issues for which no established data standards– such as metadata and associated information– exist

The basic structure (in the form of an MOU template from which specifics can be developed) should be provided to EPHTN participants. EPHTN should provide technical assistance to its participants both during the development phase of MOUs, and during the implementation and operation phases, when MOU modifications may be desired. EPHTN should also provide direct assistance, through grant support, to offset agency staff time necessary for MOU development.

During the MOU development phase, separating (or at least clearly distinguishing) the MOU portions that address data, data access, and transfer mechanisms from those that address data use may be useful. Issues of data use are far more complex and political than those concerning secured access, yet the two can easily can become confusing, and progress on each stymied. Furthermore, to the extent possible, MOUs should reference (and encourage) the use of common standards and exchange infrastructure. The EPHTN will not be able to achieve its broader goals unless this standard infrastructure is used, and if it is used, the MOUs can simply reference it, rather than having to duplicate it each time.

Elements of an MOU

The initial section of an interagency agreement (i.e., MOU) should state the purpose of the document and the public benefit from this relationship between the participating agencies. (For example, an MOU for surveillance does not stand alone but rather operates in the context of a broader interagency agreement.)

The second section of an MOU should describe the overall roles and responsibilities of the participating agencies and the relationship between them. It covers the statutory authority of each agency, arrangements for cost-sharing, mechanisms for resolution of differences (such as with data interpretation), and procedures for amendment of the MOU.

The final section of the MOU should specify details of activities. This includes the list of data systems, procedures for data transfer, frequency of data transfer, procedures for data quality control (such as compliance or enforcement for those reporting data), limitations on the use of data, mechanisms for preservation of confidentiality of data with personal identifiers (such as during record linking), conditions for data release, responsibility for interpretation and dissemination of results, procedures for identification and resolution of data gaps, specification of responsibility for follow-up investigations, and a statement of the need for flexibility to adapt to changing data needs. Typical MOUs for electronic data exchange additionally include arrangements for network administration, data standards, and data exchange templates.

How does this relate to the RFP?

CDC, ATSDR, and their partners should investigate and make available typical MOUs for data sharing and retrieval.

What are the short-term recommendations to CDC and ATSDR?

• Funded projects should develop MOUs, as appropriate
   
• Establish a MOU allowing CDC, ATSDR, and states access to EPA environmental data and allowing EPA and states access to CDC and ATSDR health data
   
• Work with staff from the EPA Exchange Network to develop standard templates for MOUs. Make these "boilerplate" MOU templates available to state health agencies, along with technical assistance to aid in necessary modifications to meet local needs

What are the long-term recommendations to CDC and ATSDR?

• In collaboration with Exchange Network staff, provide ongoing technical assistance to states in maintaining MOUs
   
• Develop MOUs with the full range of agencies that hold data appropriate for EPHTN

Recommendation 9

EPHTN architects should develop a comprehensive information security plan and include technical specifications describing the plan in the construction of the EPHTN.

Rationale

Several federal different statutes and regulations govern data security standards, and state privacy laws also apply. Individual agency protocols also influence security of data access and transmission. CDC's recent technical guidance to states on bioterrorism funding applications also can be expected to play a major role in state data security protocols.

To ensure that federal privacy protections (e.g., HIPAA) are adequately addressed, EPHTN should:

• Identify different types of users who may need access to EPHTN data
   
• Evaluate the data to be shared
   
• Develop a method for secure electronic information exchange (e.g., encryption, digital certificates, virtual private network, public/ private key infrastructure, biometrics, secure tokens) for information so regulated (i.e., patient claim data under Medicaid or other insurance agency)
   
• Nonsecure, nonregulated information also could be transmitted using these methods or by more traditional means (unencrypted e-mail, FTP, U. S. mail, or overnight delivery service), depending on the volume of information to be exchanged and the capacity of the secure network to do so.

Access to data will be managed locally using lightweight directory access protocol (LDAP), by state and local health departments (or agents) in accordance with applicable state-specific laws and regulations (i.e., state partners will determine which data elements [table rows, columns, and cells] will be available for sharing).

However, the EPHTN architects need to allow for aggregated, de-identified data to become available for research and policy purposes, as well as for educating the public and policy makers about health effects associated with environmental exposures.

Although the EPHTN's primary users may be the research community, the EPHTN also should be designed to provide accessible and useful information for policy makers and the public, while observing privacy and security standards.

Next Steps

• Review CDC's "Public Health Information Technology Functions and Specifications" (for Emergency Preparedness and Bioterrorism) dated February 8, 2002.
   
• Ensure that public health partners are involved in developing and implementing standards-based data specifications.
   
• Identify the levels of access and types of user groups who will need access to EPHTN data.
   
• Identify other federal agency models for providing "tiered access" to different user groups (e.g., anonymous access through the Web; registration using e-mail; registration using title, address, contact information; verification procedures).
   
• Develop a comprehensive, long-term strategy for "tiered access" to protect data security while making data available as appropriate for public use.