## January 31 , 2011

For questions, contact:

Charles Ishikawa, MSPH Program Manager Public Health Practice cishikawa@syndromic.org
617

- 779

- 0886 

# Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance

International Society for Disease Surveillance (ISDS)
Meaningful Use Workgroup2 

## About ISDS

The International Society for Dise ase Surveillance (ISDS) is a 501 (c)3 not

- for

- profit organization founded in 2005 and dedicated to the improvement of population health by advancing the sc ience and practice of disease surveillance. ISDS’s membership represents public health profe ssionals, healthcare providers, researchers, government officials, and others engaged in infor ming and implementing national and international h ealth surveillance initiatives. ISDS works t oward a vision of timely, effective, and coordinated disease prevention and response among a skilled public health workforce. To achieve this goal, ISDS:

• Cultivates and supports action

- oriented interdisciplinary collaboration and exchange among public health practitioners, academic researchers, and other stakeholder groups working on surveillance at the local, state, national, and global levels;

• Promotes cutting edge research projects in the eme rging field of syndromic survei llance;

• Organizes the premiere annual conference on disease surveillance;

• Offers ongoing education and training opportunities to build knowledge, skills, and competencies in surveillance;

• Provides technical assistance and s ubject matter expertise to inform public health practice and policy;

• Serves as a valuable information resource for the surveillance community by maintai ning a web site and producing targeted communications.

For more details about ISDS, see http://www.syndromic.org

.



## Disclaimer

This work was supported by Cooperative Agreement Number 5U38HM000515

- 03 from the U.S. Centers for Disease Control and Prevention (CDC). Its contents are solely the responsibi lity of the author s and do not necessarily represent the official views of CDC.



## Suggested Citation

International Society for Disease Surveillance. (2011, January). Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance . Available online : www.syndromic.org/projects/meaningful

- use3 

## Acknowledgments

ISDS Meaningful Use Workgroup

• Michael A. Coletta, MPH ( Workgroup Chair), Virginia Department of Health

• Ryan Gentr y, Indiana State Department of Health

• Julia E. Gunn , RN, MPH, Boston Public Health Commission

• Richard S. Hopkins, MD, MSPH, Florida Department of Health

• Amy Ising, MSIS, University of North Carolina Department of Emergency Medicine at Chapel Hill

• Geraldine S. Johnson , MS, New York State Department of Health

• Bryant T. Karras MD, State of Washington, Department of Health

• Karl Soetebier, Georgia Department of Community Health

• David Swenson, MEd, State of New Hampshire, Department of Public Health Services

• Office of Surveillance, Epidemiology, and Laboratory Science and Career Development, CDC

o Public Health Surveillance Program Office

o Partnerships and Planning Activity: Pamela A. Meyer, PhD, MSPH

o Division of Healthcare Information: Samuel Groseclose, DVM, MPH; Taha Kass

- Hout, MD, MS

o Public Health Informatics and Technology Progr am Office:

o Standards and Inoperability: Nikolay Lipskiy, MD, DrPH, MBA

o Northrop Grumman: Sergei Li, PMP; Sundak Ganesan, MD; Mark Meadows; Adam Brow ning; Mary Hamilton



### ISDS Board of Directors

• David Buckeridge, MD, PhD, ISDS President, McGill University and Montreal Public Health Depar tment

• John S. Brownstein, PhD, ISDS Vice

- President, Harvard Medical School

• Howard Burkom, PhD, Johns Hopkins University Applied Physics Laboratory

• Wendy Chapman, PhD, UCSD School of Medicine, Division of Biomedical Informati cs

• Jean

- Paul Chretien, MD, PhD, Lieutenant Commander, US Navy

• Julia E. Gunn, RN, MPH, Boston Public Health Commission

• Bill Lober, MD, University of Washington

• Joseph S. Lombardo, PhD, Johns Hopkins Applied Physics Laboratory

• Marc Paladini, MPH, New York Ci ty Department of Health and Mental Hygiene



### Staff

• Charlie Ishikawa, MSPH

• Anne Gifford, MPH

• Rachel Viola

• Emily Cain, MPH

• HLN Consulting, LLC: Noam H. Arzt, PhD; Daryl Chertcoff; Maiko Minami


### Special Thanks

This work would not have been possible without the s upport of many people. We thank the following individuals for their invaluable contributions: Rita Altamore, Natasha Close, Phil Lowe, Aaron Kite

- Powell, and Walter Suarez. In addition, the members and staff from the following organizations have provided f eedback on prior versions of this document: Council of State and Territorial Epidemiologists, Associ ation of State and Territorial Health Officials, National Association of City and County Health Officials, the Public Health Data Standards Consortium , and the Electronic Health Records Association

. We are grat eful for the on

- going support and leadership of the Public Health Informatics Institute.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance

4 

## Table of Contents

Table of Figures & Tables

................................ ................................ ................................ . 5
Executive Summary

................................ ................................ ................................ .......... 6

1

. Background

................................ ................................ ................................ .................. 7
1.1 Purpose the ISDS Recommendation

................................ ................................ .................. 7
1.2 Recommendation Scope

................................ ................................ ................................ .... 9
1.3 Key Assumptions

................................ ................................ ................................ .............. 10



### 2

. The Core Business Processes of Syndromic Surveillance

................................ ......... 12

2.1 Goal

................................ ................................ ................................ ................................ .. 12
2.2 Objectives

................................ ................................ ................................ ......................... 14

2.3 Entities & Transactions

................................ ................................ ................................ ..... 14
2.4 Inputs

................................ ................................ ................................ ................................ 16



### 3

. Schematics : Core Busines s Process and Task Set

................................ .................. 18
3.1 Conduct Syndrome

- Based Population Health Monitoring (BP 1)

................................ .... 18
3.1.1 Task Set 1 (TS1): Collect and Process Data

................................ .............................. 25
3.1.2 Task Set 2 (TS2): Characterize, Interpret, and Analyze Data

................................ ..... 32
3.1.3 Task Set 3 (TS3): Notify and Engage Partners / Leadership

................................ ..... 37
3.1.4 Task Set 4 (TS4): Conduct Reach

- back

................................ ................................ .... 39
3.2 Establish and Maintain Data Sharing Partnerships (BP 2)

................................ ................ 42
3.3 Conduct Data Quality Assurance (BP 3)

................................ ................................ ........... 47



### 4

. Core EHR Requirements

................................ ................................ ............................ 53
4.1 Transmission and Reception of Data

................................ ................................ ................ 53
4.1.1 Frequency

................................ ................................ ................................ .................. 53
4.1.2 Emphasis on Unfiltered Data

................................ ................................ ..................... 53
4.1.3 Updating

................................ ................................ ................................ .................... 53
4.1.4 Anonymized / Pseudonymized Data

................................ ................................ .......... 54
4.2 Facility Registration Data

................................ ................................ ................................ .. 54
4.3 Key Terms and Definitions

................................ ................................ ................................ 55

4.4 Minimum D ata Set

................................ ................................ ................................ ............ 56


### Appendix A: Extended and Future Data Elements for Further Consideration

................ 66
Bibliography

................................ ................................ ................................ ................... 69Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance

5 

## Table of Figures & Tables

Figure 1: ISDS Stage 1 Meaningful Use Recommendation Development Process and Project Milestones 9

Figure 2: Adjusting existing biosurveillance standards to current PHSS practice 11

Figure 3: The Common Ground Preparedness Framework 13

Figure 4 Business context diagram for PHSS 15

Figure 7: Task Flow Diagram of BP 1

- Conduct Syndrome

- Based Population Health Monitoring
20

Figure 8: Task Flow Diagram for TS1

– Collect and Process Data 26

Figure 9: Task Flow Diagram for TS2

– Characterize, Interpret, and Analyze Data 33

Figure 10 Task Flow Diagram of Task Set 3 (TS3)

– Notify and Engage Partners/Leadership 37

Figure 11: Task Flow Diagram of Task Set 4 (TS4): Conduct Reach

- back 40

Figure 12 Task Flow Diagram for BP2: Establish and Maintain Data Sharing 43

Figure 13: Task Flow Diagram of Business Process 3 (BP3)

- Conduct Data Quality Assurance:
49

Table 1: Summary of inputs into the core, PHSS business processes that influence the decision points and pathway of the task flow. 16

Table 2: List of the Core Public Health Syndromic Surveillance (PHSS) Business Processes 18

Table 3: Description of table columns used in section 4.4, which contains the recommended minimum data set 55

Table 4: Minimum Data Set commonly used by public health authorities to conduct public health syndromic surveillan ce 56

Table 5: Extended data elements and data elements for future consideration to support public health syndromic surveillance 66Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance Executive Summary

6 

## Executive Summary

A pillar of current U.S. health reform efforts is promoting the effective use of health information technology to transform how health care is delivered and population health is improved. Of immediate importance for public health authorities (PHA) is getting ready for implementation of the Medicare and Medicaid Electronic Health Records (EHR) Incentive Programs (“Meaningful Use”), a major component of the Health Information Technology for Econ omic and Clinical Health (HITECH) Act within the 2009 American Recovery and Reinvestment Act legislation.
In the absence of appropriate standards for the public health syndromic surveillance (PHSS) Meaningful Use objective, it was deemed necessary to docum ent PHSS business processes and define a core set of EHR requirements to support current syndromic surveillance practice s and to provide a framework for system redesign in order to provide a nationwide and regional
situation awareness perspective for all h azards health

- related events.
On August 1, 2010, the BioSense Program supported ISDS in recommending standards that support PHA efforts to make meaningful use of EHR technology during Stage 1 of the Mea ningful Use programs. ISDS convened a Workgroup of pub lic health surveillance experts to re commend requirements that support the core business objectives of contemporary PHSS pra ctice. A consensus

- driven process was used to develop this recommendation. Input from the ISDS MU Workgroup served as the basis for early document iterations. Meaningful Use stakeholders then had an opportunity to provide comments from December 1

– 17, 2010, which further informed the final recommendation.

Concurrent to the creation of the Recommendation , the CDC worked to translate th ese r equirements into a HL7 2.3.1 and 2.5.1 messaging guide for syndromic surveillance.
The scope of this recommendation is the utilization of emergency department and urgent care patient data to assess community and population health for all

- hazards. Core EHR requir ements are described in HL7 to maintain consistency with the required standards of the CMS EHR Reimbursement Program. Variations in state and local laws and practices may result in additional EHR data requirements for PHSS.

This document detai ls 3 core PHSS business process recommendations:

1. Core objectives of contemporary PHSS and the minimum EHR data requirements widely needed to support the core ;

2. M odel core workflows, inputs and outputs of PHSS; and

3. A holistic picture for understanding how an EHR can add value and efficiently interface with a PHA.

In addition, 32 core data elements are proposed

. This is not an exhaustive list of data currently in use for PHSS, nor is it a “one size fits all” recommendation. Individual public health author ities may have additional data requirements that are necessary to support current practice.

This document is organized to lead the reader through a description of the core PHSS bus iness processes and then core EHR data requirements that support these proce sses.

• Section 1 provides background

.

• Sections 2 and 3 describe the context, objectives, business rules, inputs, and critical task

sets of the core processes.

• Section 4 describes data transmission and reception requirements, and a tabulated set of

data elements that constitute a minimum syndromic surveillance message.Final Recommendation: Core Business Processes and EHR Requirements for Syndromic Surveillance 1

. Background

7 

## 1. Background

ISDS applauds the Meaningful Use policy priorities of the Medicare and Medicaid Electronic Health Records (EHR) Incentive Programs, a major component of the Health Information Tec hnology for Economic and Clinical Health (HITECH) Act and part of 2009 American Recovery
and Re investment Act legislation

. ISDS strongly supports the inclusion of a public health syndromic surveillance objec tive in the Stage 1 M ean ingful U se rule for EHR certification. Furthermore, ISDS supports the continued inclusion of a public health surveillan ce objective in future meaningful use stages. ISDS me mbership is highly invested to the success of Stage 1, because success is essential to making the most of the CMS EHR Reimbursement Program and the tremendous opportunity it creates.

In the absence of st andards for the public health syndromic surveillance (PHSS) EHR certific ation "menu" objective, ISDS, with the support of the BioSense program (PHSPO/OSELS/CDC), convened a Workgroup of public health surveillance experts to quickly revive a standards d evelopment process that will inform current and future Meaningful Use stages.

In September 2010, the ISDS Meaningful Use Workgroup (MU Workgroup ) was charged with recommending requirements that support the core business objectives of contemporary PHSS

prac tice using a business process analysis approach. The reasons for this charge and a pproach are:

1. A volunteer Workgroup of ISDS members was convened to expedite the project due to time constraints and the urgent need for an appropriate, Stage 1 MU PHSS sta nda rd
2. A contemporary view of PHSS was developed because existing standards for r elated public health practices (e.g., biosurveillance or reportable conditions reporting) do not accurately represent the current PHSS capabilities of most state and local
PHA’s
3. R equirements for the core PHSS business objectives were documented because there is substantial innovation and new effective uses of electronic surveillance data

are constantly being discovered
4. Business process analysis was used because its artifacts are be st suited for the system re

- design work required to reach the full potential of the EHR to improve population and public health

As the Workgroup carried out its charge, the CDC worked in close collaboration with ISDS to expedite the translation of these re quirements into a HL7 2.3.1 and 2.5.1 messaging guide for syndromic surveillance. Version 1 of this PHIN Messaging Guide for Syndromic Surveillance will be released for broader stakeholder comment and collaborative development in January
2011.

Together, th is ISDS Recommendation and the CDC’s messaging guide are intended to meet the pressing need for PHSS standards for meaningful use. In the long

- term, ISDS hopes that this collaboration will serve as a foundation for advancing public health surveillance capa bilities and the development of EHR standards.


### 1.1 Purpose the ISDS Recommendation

The purpose of this document is to define the core of PHSS practice and the minimum EHR data requirements widely used to support the core. This recommendation provides the C DCFinal Recommendation: Core Business Processes and EHR Requirements for Syndromic Surveillance 1

. Background

8 and the Office of the National Coordinator for Health Information Technology (ONC), with bus iness requirements that will support Meaningful Use stakeholders in meeting the Stage 1 public health surveillance objective.

The purpose of this document is no t to provide technical guidance for message implement ation. For such information, please see the CDC’s PHIN Messaging Guide for Syndromic Su rvei l lance.

This document also does not attempt to define a future vision for PHSS or electronic public
health surv eillance as a whole. ISDS acknowledges that Meaningful Use is an opportunity to

re

- design public health surveillance for greater capability, efficiency, and effectiveness. This document is a necessary, preliminary step for redesign in so far as it provides a comprehensive and detailed starting point (i.e., current

- state business processes)

. Finally, the purpose of this document is not to recommend what PHSS should be, or advocate for a permanent data communication model. ISDS recognizes that the current pra ctice env ironment described in this document makes it difficult for EHR technology vendors to develop
scalable solutions. We recommend that as PHSS and EHR technologies evolve , stakeholders share best practices and lessons learned towards scalable and interoperable surveillance sol utions

. This document supersedes and replaces preliminary and provisional iterations that were r eleased on September 30 and December 1, 2010.



### 1.1.1 Development P rocess

A consensus

- driven process was used to develop this document (Figure 1). Input from the MU Workgroup served as the basis for early document iterations (i.e., preliminary and provisional recommendations) . Meaningful use stakeholders then had an opportunity to provide comments that have infor med this final document version. Input from public health stakeholders was c oordinated through the Joint Public Health Informatics Taskforce (JPHIT).

From December 1

– 17, 2010

, 4 1 stakeholders submitted comments to ISDS; approximately 20% were on behalf of private corporations or professional organization s

. E ligible healthcare professionals and hospitals, EHR technology vendors, and public health stakeholders provided input

.
Stakeholder comments have better contextualized this recommendation within efforts to e nhance public health surveillance with health information technology. Although, the majority of commentators endorsed this recommendation, most believe that there are critical outstanding
issues , including:

1. An urgent need for surveillance practice and technical standards for primary and inp atient care health data

2. Re design of the current PHSS communication model to incorporate Health Information Exchanges and facilitate the development of scalable EHR solutions

3. A coord inated, harmonized approach for public health “Electronic Surveillance”

4. Expansion of the recommended minimum data elements list to accommodate the r equirements of advanced PHSS systems

5. Further incorporation of federal PHSS business processes and requirementsFinal Recommendation: Core Business Processes and EHR Requirements for Syndromic Surveillance 1

. Background

9 The MU Workgroup acknowledged and excluded many of these issues from the current re commendation process due to the rapid timeline. ISDS is, however, already working to address
these issues in collaboration with other stakeholders. We will main tain a Frequently Asked Questions webpage to share and discuss stakeholder comments and questions.

Date Activities Outcomes

Stage 1: Preliminary Recommendation

July

– Sept , 2010 • Draft minimum syndromic surveillance dataset based on contemporary practice and existing standards (Figure 1)

• Workgroup develops high

- level business objectives

• Workgroup reviews and modifies draft minimum

dataset • High

- level picture of public health syndromic surveillance

• Minimum data elements

commonly used in public health syndromic surveillance

Sept 30

, 2010 • Release Preliminary Recommendation • Provide stakeholders with pr eliminary guidance

Oct

– Nov

, 2010 • Receive general comments, feedback and inquiries from stakeholders • Limited stakeholder Input for provisional recommendation

Stage 2: Provisional Recommendation

Oct

– Nov

, 2010 • Workgroup performs in

- depth business process analysis of public health syndromic surveillance and updates EHR requirements • Describe business processes in detail, and minimum dataset based on best pra ctices

Dec 1

, 2010 • Release Provisional Recommendation • Provide stakeholders with guidance for comment

Dec 1

– 17 , 2010 • Public comment period: On

- line comment form • Broad stakeholder input for final recommendation

Stage 3: Final Recommendation

Dec 2010 • ISDS refines recommendations based on stakeholder input • Guidance reflects board stakeholder input

Jan 2011 • Release Final Recommendation • Fulfill need for guidance on public health syndromic su rveillance EHR certification o bjective

Figure 1 : ISDS Stage 1 Meaningful Use Recommendation Development Process and Project Milestones


### 1.2 Recommendation Scope

Several factors govern the scope of the core business process es and the PHSS message r equirements detailed in this document. These factors are: d ata source; surveillance goal; and message and vocabulary standards.Final Recommendation: Core Business Processes and EHR Requirements for Syndromic Surveillance 1

. Background

10 

### 1.2.1 Factors

Data Source: Data on emergency department (ED) and urgent care (UC) patient visits captured by health information system and s ent to a public health authority defines the scope of this
recommendation.

Since PHSS practitioners have the greatest amount of experience and shared practices with ED and UC data, they are the best resources for describing business processes and data r equirements that have broad applicability among public health authorities.

Surveillance Goal: Assessment of community and population health for all

- hazards defines the scope of this recommendation.

Given the potential of PHSS systems to assess a broad rang e of community health and health indicators, an all

- hazards perspective is necessary for analyzing these systems and defining their core health data requirements.

Message and Vocabulary Standards: Standards that support current and continued PHSS improveme nts, while maintaining consistency with those standards required by the CMS EHR Reimbursement Program define the scope of this recommendation.



### 1.2.2 Primary Care and Inpatient Data

Although limited to ED and UC data, ISDS believes that the core business process es and data requirements presented herein are applicab le to patient visit data from primary care ( PC ) and inpatient care (IC) settings. Outside of UC settings, however, the public health surveillance community has limited experience in using these d ata for PHSS.

ISDS recommends that work to adapt the core data elements for PC and IC data ( see Section 4.4) commence as early as possible in 2011. The adaptation process must accommodate d irect participation from all stakeholder groups, especially repres entatives from the eligible care provider and EHR technology vendor communities since the relevant clinical and technological workflows are new to public health surveillance experts.



### 1.2.3 Potential Future Data Elements

A table of data elements that are in use by some jurisdictions, but not widespread enough to be included as part of the core minimum data set is appended to this document for inform ational purposes only

. As PHSS standards evolve beyond this recommendation, the MU Workgroup believes that t h ese data elements will be first in

- line for adaptation as an optional
extension to the core minimum data set

. In addition, the appendix also presents other data elements and related issues that the MU Workgroup discussed in order to carry these ideas forwa rd for future development of PHSS
standards.



### 1.3 Key Assumptions

Several facts premise these recommendations and influence how they should be read and uti lized.

1. As PHSS and health information technologies evolve, new capabilities and business pra ctice will emerge and requirements will changeFinal Recommendation: Core Business Processes and EHR Requirements for Syndromic Surveillance 1

. Background

11 2. There is great variation in practices, technology, responsibilities, and resources across fe deral, state, and local jurisdictions in the field of PHSS
3. Variations in state and local laws and practices may result in addit ional EHR data requir ements for PHSS
4. HIPAA does not restrict covered entities (e.g., healthcare organizations) from sharing health records with public health agencies that are authorized by law to receive health data
5. Public health authority will be able to receive, manage, analyze, and meaningfully use HL7
messages

Figure 2 : Adjusting existing biosurveillance standards to current PHSS practice

– Expert practitioners of public health syndromic surveillance (PHSS) consulted existing biosurveillance standards to draft a set of minimum data that are commonly used by state and local public health authorities . This draft set served as the starting point for the ISDS MU Workgro up’s recommendation. These existing biosurveillance use cases do not necessarily describe how the core data elements for PHSS (see Section 4.4.) will develop in the future.Final Recommendation: Core Processes and EHR Requirement s for Public Health Syndromic Surveillance 2

. The Core Business Processes of Syndromic Surveillance

12 

## 2

. The Core Business Process es of Syndromic Surveillance

Business process es describe the means by which organizations accomplish a goal to produce something of value. These processes detai l the consecutive tasks or task sets through which value is added. In contrast to use cases, business process es provide a holistic picture for u nderstanding how an information system can add value for its users and interface with other o rganizational activ ities to build efficiencies. 1

Th e three, core business process es for PHSS is based on a current

- state analysis of practice

. Informed by widely used and best practices, this model is intended to guide stakeholders in planning, designing or implementing EHR solutions during Meaningful Use, Stage 1

. This model may also serve as a basis for system redesign.

This section describes critical , characterizing components of the core business processes , i ncluding:

1. R ole of PHSS within the three core public health functions
2. Core PHSS business objectives
3. Entities and high level transactions that are key to PHSS
4. Inputs that are required for production



### 2.1 Goal

Of the three, core public health functions recommended by the Institute of Medicine in, “The Future of Public Health”, PHSS is a part of the assessment function. Similar to other survei llance processes (e.g., laboratory

- confirmed reportable conditions, or behavioral risk factor su rveillance), PHSS systems utilize health data to produce information in support of an overarc hing public health surveillance goal to:

“...regularly and systematically collect, assemble, analyze, and make available inform ation on the health of the community, including statistics on health s tatus, community health needs, and epidemiologic and other studies of health problems.” 2

In contrast to other surveillance processes, PHSS is unique due to its use of near "real

- time" patient data and statistical tools. PHSS processes enable public health authorities to provide timely assessments of population health that, in conjunction with other core and event

- specific activities, assist with determining and assessing the implementation of public health action. This is particularly useful for event detec tion, situation awareness, and response management. However, it is important to emphasize that PHSS information is one of many artifacts produced by a public health authority’s surveillance function

. Given its value to public health surveillance, PHSS is best contextualized within the Common Ground Preparedness Framework (Figure 3). PHSS processes produce information that may trigger a response, alter risk mitigation strategies, or impact the allocation and distribution of

resources.

1 Public Health Informatics Institute. (2006). Taking Care of Business: A collaboration to define local health department business processes. Decatur, GA: Public Health Informatics Institute

2 Committee for the Study of the Future of Public Health. The Future of Public Health: Summary & Recommendations. (1988) pg. 7Final Recommendation: Core Processes and EHR Requirement s for Public Health Syndromic Surveillance 2

. The Core Business Processes of Syndromic Surveillance

ISDS Meaningful Use 13

Figure 3 : The Common Ground Preparedness Framework was developed through a three

- year collaboration of eight state or local health departments, brought together to define public health’s business processes related to preparedness. The framework has three phases: Pre

- Incident, Incident, and Post

Incident. 33 business processes are contained in six business process groups: Prepare, Monitor, Investigate, Intervene, Recover, and Manage. Syndromic

surveillance is located within the Moni tor process group. A 34 th process involving communications supports all the other processes. Arrows indicate information flow between processes or process groups. (Gibbson, Theodore and Nichole)Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 2

. The Core Business Processes of Syndromic Surveillance

ISDS Meaningful Use 14 

### 2.2 Objectives

Business objectives are statements that reflect what an organization seeks to achieve with its processes. Based on the Workgroup ’s analysis of PHSS, seven objectives were identified. Each, by way of a PHA’s core surveillance function, contributes to ensuring the health and
well

- being of community and population health through public health interventions and activ ities.

In conjunction with other core public health activities, PHSS business objectives include the following:

1. Provide ongoing, timely intelligence and data on public health threats or health cond itions of interest
2. Support early identification or ruling out of public health threats, cond itions of public health importance, or suspected incident(s)
3. Assist in characterizing population groups at greatest risk
4. Assist in assessing the severity and magnitude of possible threat(s) and the effectiv eness of control measures
5. Assist with continual e valuation and development of new and improved surveillance practic es 6. Keep stakeholder organizations, public health leadership, and the public informed (as appropriate) about conditi ons of public health importance
7. Support collaborative efforts with health p roviders, media, first responders, and go vernment decision makers



### 2.3 Entities & Transactions

A context diagram is used to illustrate the participants and the information flows necessary for business. Participants, referred to as entities, are represented in the diagram as circles. L ines between enti ties represent information flow or transac tion . The straight lines have arrows that indicate the direction of the transaction as information is exchanged between entities.

The context diagram reflects the relationships and boundaries that exist between entities of PHSS (Figure 4). While the context diagram shows the relationships between PHSS entities, they do not reflect the sequence or order of transactions, processes or t asks.

The focus for this document is the interaction between Hospital ED and UC health data providers and the PHA or their designee. The health data sent from an ED or UC provider
consist s of the recommended minimum data set described in Section 4.4.

Tran sactions between the PHA and the remaining entities may occur at different parts of the business processes. However, it is recommended that an assessment be conducted to detail these interactions when applying this recommendation to any specific practice e nvironment.Final Recommendation: Core Processes and EHR Requirement s for Public Health Syndromic Surveillance 2

. The Core Business Processes of Syndromic Surveillance

ISDS Meaningful Use 15 Figure 4 Business context diagram for PHSS: This context diagram illustrates the relationships that exist between entities of PHSS and shows the flow of information required by the core business processes

. The focus of this final recommendation is the interaction between ED and UC data and the PHA o r their designee

. The data sent from the ED or UC provider consists of the recommended minimum data set described in Section 4.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 2. The Core Business Processes of Syndromic Surveillance

ISDS Meaningful Use 16 

### 2.4 Inputs

Inputs are information or variables received by a business that affect process outputs

. For PHSS, there are seven kinds of inputs that influence the surveillance information produced by
the core business process es

.
Table 1 summarizes the various inputs. These inputs affect the processes at points that are indicated in the business process task flow diagrams deta iled in Section 3

.

Table 1 : Summary of inputs into the core, PHSS business process es that influence the decision points and pathway of the task flow.



### Health Data
Health data from a provider sent to a public health authority are required for PHSS. These data are the observations for the PHSS epidemiological operations and analyses. The scope of this
recommendation is health data on ED and UC visits

.


### Health Condition of Interest

As with other public health surveillance processes, population health is assessed for defined health conditions in PHSS. Best practices for monitoring the following conditions are well d efined: Indicators of Infectious Disease, Environmental Exposures, Injury, Exacerbations of Chronic Disease Conditions, and Health Care Utiliz ation

. Practices for monitoring Exacerb ations of Mental Health Conditions are rapidly developing.



### Purpose
PHSS systems are utilized for three general purposes: 1) Event Detection; 2) Response Ma nagement; and 3) Situation Awareness

. When a public health aut hority engages its PHSS sy stem, the purpose influences the delivery of the surveillance information.

Input Name Summary of Input

Health Data Emergency Department (ED), Urgent care (UC) visits

Health Condition of Interest Indicators of: Infectious Disease, Environmental Exposures, Injury, Mental Health Conditions, Health Care Utilization, and Exacerbations of Chronic Disease Conditions

Purpose Event Detection, Response Management, Situation Awareness

Context Routine, Elevated risk due to an anticipated threat, Elevated risk due to a present threat

Information from other Pu blic Health Activities and
Processes Advice from subject matter experts; Distribute data from neighboring jurisdictions; statistical patterns or aberration characterized by other surveillance systems (e.g. NEDSS); or an astute clinician’s case report

Outsi de Influences Media reports; weather patterns; air quality measurements; and polit ical factors

Level of Authority Local, State, Federal, District, Senior Decision

- MakerFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 2. The Core Business Processes of Syndromic Surveillance

ISDS Meaningful Use 17 

### C ontext
A context is formed by the circumstances within which a public health authority operates a PHSS system. Context is subject to change. There are t hree contexts within which PHSS sy stems operate:

• Routine use : PHSS systems are routinely used for public health surveillance inform ation. Routine utilization can be daily, weekly, monthly, seasonal, or annual. Examples include: Seasonal influenza

- like

- illness monitoring, daily review for unusual clusters of illness, or annual ED utilization for injury care.

• Elevated risk due to an anticipated threat: There are circumstances where the potential for a population h ealth threat is high. In this context, a threat is anticipated, but not a ctually present. Examples include: Recurring events such as marathons or local sporting events; and single events

, such as larger sporting events (e.g. Super B owl), or events of
national significance

, including political conventions and international diplomatic visits

.

• Elevated risk due to a present threat: Sometimes a threat to population health is pr esent. Examples include: Recurring events

, such as heat waves or the response an d r ecovery phases following a natural disaster; and single events

, such as communicable disease outbreaks or exposures to hazardous materials.



### Information from other Public Health Activities and Processes

PHSS outputs are influenced by the information and participation of parties from other public health activities and processes. Examples include: A dvice from subject matter experts; D istri bute data from neighboring jurisdictions; statistical patterns or aberration characterized by other surveillance systems (e.g. NEDSS); or an astute clinician’s case report.



### Outside Influences

Information from outside processes influences PHSS processes. Examples include: Media r eports; weather patterns; air quality measurements; and political factors.



### Level of Authority

Parties from multiple levels of authority contribute to PHSS. Surveillance analysts, public health investigators, epidemiologists, and senior decision makers from local, regional, state, or federal jurisdictions can be involved.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 18 

## 3

. Schematics: Core Business Processes and Task Sets

A business process describes a set of activities and tasks that logically group together to a ccomplish a goal or produce something of value for the benefit of the organization, stakeholder, or public. 3

In this section, the core business processes of public health syndromic surveillance (Table 2) are described in detail, along with the tasks and decision points that consecutively produce PHSS information. Drawn primary from the perspective of a PHSS analyst and rendered as a generalized model, EHR vendors, hospitals and eligi ble health professionals should work with PHA’s to identify significant idiosyncrasies.

ID Business Process or Task Set Name

BP 1 Conduct Syndrome

- Based Population Health Monitoring

TS 1 Collect and Process Data

TS 2 Characterize, Interpret, and Analyze Data

TS 3 Notify and Engage Partners / Leadership

TS 4 Conduct Reach

- back

BP 2 Establish and Maintain Data Sharing Partnerships

BP 3 Conduct Data Quality Assurance

Table 2 : List of the Core Public Health Syndromic Surveillance (PHSS) Business Processes


### 3.1 Conduct Syndrome

- Based Population Health Monitoring (BP 1)

Conducting syndrome

- based population health monitoring is the core business process of public health syndromic surveillance. Upon identifying a potential public health concern through the characterization, interpretation, and analysis of data, the public health syndromic surveillance unit determines whether to escalate a potential concern, notifies and engages partners and leadership when applicable, assists in determin ing whether a response is needed, and may assist in the response actions.

Objective of the Business Process : To conduct syndrome

- based population health monito ring and assist in the assessment, detection, communication, and response to public health
condit ions of interest.

Trigger :
For routine monitoring, the trigger is ED / Urgent Care data made available or sent at least every 24 hours.

Other triggers include: knowledge of events considered to be of elevated risk; information from
other Public Health act ivities or outside influences that indicates a possible health condition of interest that warrants monitoring.

3 Public Health Informatics Institute, “Taking Care of Business: A Collaboration to Define Local Health Department Business Processes”, Decatur, GA, 2006.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 19 Assumptions of the Business Process : It is assumed that a data sharing partnership has a lready been established between the data provider and receiver. See Business Process 2 (BP2): Establish and Maintain Data Sharing Partnerships.

Input to the Business Process : Health data; Level of authority; Health condition of interest; Purpose; Output of QA business process; Information from other public health activities and processes; Outside influences.

Output of the Business Process : May include: Reports (Routine/SITREP); Documentation of the response or what was seen or not seen in the data; Health al erts; Information to public health leadership/PIO role.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 20 .

Figure 5 : Task Flow Diagram of BP 1

- Conduct Syndrome

- Based Population Health Monitoring: Monitor and assist in the assessment, detection, communication, and response to public health conditions of interest.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 21 

### Conduct Syndrome

- based Population Health Monitoring (BP 1)

Monitor and assist in the assessment, detection, communication, and response to public health conditions of interest.

All numbers refer to the flow diagram for BP 1 (Figure 7) unless otherwise noted.

BP1

- 1 : Collect and Process Data (TS1)

• The Public Health Authority (PHA) receives ED/Urgent Care Visit health data and e ngages the task set Collect and Process Data (TS1)

• See Collect and Process Data (TS1) for a detailed description of this task set.

• The inputs that affect the decisions and pathway within this task set are Health Data; Context; Purpose; and the output of the Conduct Data QA (BP3) business process, which is a semantically validated/cor rected data source.

• The main output of this task set is the results of the automated statistical algorithms and counts, which include time series and summary counts of flags.

BP1

- 2: Characterize, Interpret, and Analyze Data (TS2)

• Once the data are collected and processed, the data are characterized and analyzed.

• See Characterize, Interpret and Analyze (TS2) for a detailed description of this task set.

• The inputs that affect the decisions and pathway within this task set are Context; Health Condition of Interest; Purpose; Level of Authority; Data from Other Public Health (PH) Processes; Outside Influences, and the output of the Conduct Data QA (BP3) busi ness process, which is a semantically validated/corrected data source.

• The output of this task set is conclusions and results of characterization and pattern analysis; Purpose; and Health Condition of Interest.

BP1

- 3 : Escalate or Ramp

- up?

• This question is answered by the PHSS analyst who analyzed and characterized the data in TS2

- Characterize, Interpret, and Analyze Data. Based on the results and co nclusion in TS2, the analyst determines whether to escalate or ramp

- up any issues based on th e specifics of results, the severity of the issue, and potential for spread.

• The specific criteria to determine whether an issue should be escalated vary across j urisdictions and depend greatly on the specifics of the issue.

BP1

- 4: Engage Relevant Partners?

• If an issue is escalated, the question of whether to engage relevant partners and/or leadership is answered by the PHSS analyst and depends on a variety of inputs, i ncluding: variables that quantify the severity and potential spread of the poten tial co ncern; the level of authority of the PHA; the context; purpose; health condition of inte rest; outside influences (e.g. media or political).

o Example: From the results of analysis, i f an analyst suspects a possibility of bacterial meningitis , but the probability is questionable or low , then the analyst may decide to contact the data provider directly to follow

- up. However, if the analyst detects a strong possibility of bacterial meningitis from data gathered in one day , the analyst would likely engage leadership.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 22 

### Conduct Syndrome

- based Population Health Monitoring (BP 1)

Monitor and assist in the assessment, detection, communication, and response to public health conditions of interest.

All numbers refer to the flow diagram for BP 1 (Figure 7) unless otherwise noted.

o Example: Some local jurisdictions may engage data providers more frequently since there are fewer intermediaries between the two parties. At a local juri sdiction, if an analyst sees ‘Anthrax’ in a chief complaint field, prior to engaging leadership, the analyst may first confirm with the data provider that ‘Anthrax’ is not referring to the vaccination.

• The criteria for making this decision vary widely across jurisdictions.

BP1

- 5: Notify and Engage Partners / Leadership (TS3)

• See Notify and Engage Partners / Leadership (TS3) for a detailed description of this
task set.

• Partners refer to Local, Regional, State Authority, Colleague, Designee, or Federal. Partners include public health and emergency preparedness.

• The output of this task set is a decision for next steps.

BP1

- 6: Continue?

• Based on the output of the task set Notify and Engage Partners / Leadership (TS3), the PHSS analyst / PHA determines whether to take further action or not.

BP1

- 7: Concern Identified By Other Systems

• There are instances where other systems identify a potential concern and request fo llow

- up by public health syndromic surveillance to find relevant PH SS data.

BP1

- 8: Select Approach Based on Context and Health Condition of Interest

• The PHSS analyst determines whether additional analysis is needed (TS2) or whether to proceed with conducting reach

- back based primarily on the context and health condition of interest.

• Example: If an analyst discovers the possibility of Anthrax, the analyst may decide there is an immediate need to acquire additional information (“breaking the glass”, e.g. chart review) rather than further refinement of the data.

BP1

- 9: Conduct Reach

- back?

• The question of whether to conduct reach

- back is answered by the PHSS analyst based primarily on the results and analysis thus far, the context, and the health cond ition of interest.

BP1

- 10: Conduct Reach

- back (TS4)

• See Conduct Reach

- back (TS4) for a detailed description of this task set.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 23 

### Conduct Syndrome

- based Population Health Monitoring (BP 1)

Monitor and assist in the assessment, detection, communication, and response to public health conditions of interest.

All numbers refer to the flow diagram for BP 1 (Figure 7) unless otherwise noted.

BP1

- 11: Response Needed?

• This question of whether a response is needed is answered by the PHA and PHSS an alyst based on variables that quantify the severity and potential spread of the concern, including: volume; characteristics; geographic spread; tight cluster in time; or tight cluster in time and space.

• Inputs that may influence the decision include: conte xt, health condition of interest, and outside influences.

Response Actions (BP1

- 12 through BP1

- 18)

BP1

- 12 through BP1

- 18: When a response is initiated, gradient of activities may be act ivated depending on the purpose, context, level of authority, health condition of interest, and outside influences. The PHA may engage in one or more of these response actions; not all response actions will be necessarily activated. These actions are not conducted in a linear order and one action may influence one or more of the other actions.
Dissemination of Information (BP1

- 12 through BP1

- 16)

BP1

- 12: Dissemination of Information: Disseminate SS Information / Output As
Needed
This task is to capture activities related to disseminating PH SS information or output not captured by the other dissemination of information actions (BP1

- 13 through BP1

- 16)

BP 1

- 13: Provide Summary Information to SITREP
Summary information is reported to a situation report (SITREP) in order to establish
and maintain situation awareness for the PHA and public health leadership.

BP 1

- 14: Send Health Alert
Health alerts are sent through Health Alert Networks (HANs), which help disseminate important health information and link local health departments to one another and to
other organizations critical for preparedness and response: community first

responders, hospital and private laboratories, state health departments, CDC, and other federal agencies. 4 Health alerts may also be sent through CDC’s Epi

- X, which provides communicatio n and sharing of preliminary health surveillance information for CDC officials, state and local health departments, poison control centers, and other public health professionals. 5

4 http://www.bt.cdc.gov/documentsapp/han/han.asp

5 http://www.cdc.gov/epix/Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 24 

### Conduct Syndrome

- based Population Health Monitoring (BP 1)

Monitor and assist in the assessment, detection, communication, and response to public health conditions of interest.

All numbers refer to the flow diagram for BP 1 (Figure 7) unless otherwise noted.

BP1

- 15: Provide Information to PIO Function/Role

• The PHA provides necessary information to the person fulfilling the Public Info rmation Officer (PIO) role. The PIO role may vary across jurisdictions ranging from a dedicated PIO person/unit in larger PHAs, to public health leadership fulfilling the role.

• The role of the P IO is to be a communication spokesperson for the PHA by pr oviding information to the public and media.

BP1

- 16: Inform Health Care Providers

The PHA may communicate separately with health care providers to provide additional information or instructions that are relevant to and can be performed by health care providers.

• Example: A PHSS unit detects a cluster that may potentially be a gastrointe stinal outbreak within a geographic area. Therefore, the PHA sends out targeted alerts to specific hospitals within the geographic area so that they may be able to identify, evaluate, and provide medical intervention more effectively to their patients and/ or those affected persons seeking medical care.

BP1

- 17: Activate PH / Preparedness and Response Resources
Public health and preparedness and response resources are activated if it is determined that the issue is significant enough to spend resources for intervention. Intervention may be a ctivities related to increasing educational awareness or situation awareness.

BP1

- 18: Launch a Formal PH Investigation
A formal public health investigation is launched if the issue is severe enough or poses a
threat l arge enough where further investigation is required.

BP1

- 19: Further Action?
When a potential issue does not require additional escalation, this question is answered by the PHSS analyst to determine if any further action is needed.

Further Actions for Non

- Escalated issues (BP1

- 20 through BP1

- 23)

BP1

- 20 through BP1

- 23: A gradient of responses for non

- escalated issues that may still r equire further action depending on the purpose, context, level of authority, health condition of interest, and outside influences. The PHA may engage in one or more of these actions; not all actions will be necessarily activated. These actions are not conducted in a linear order and one action may influence one or more of the other actions.

BP1

- 20: Watch and Wait

Watch a nd wait is to bookmark the issue and to note it in the system and/or documentation that no action is required at the present, but will be “watched” in the event that additionalFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 25 

### Conduct Syndrome

- based Population Health Monitoring (BP 1)

Monitor and assist in the assessment, detection, communication, and response to public health conditions of interest.

All numbers refer to the flow diagram for BP 1 (Figure 7) unless otherwise noted.
data prompts further analysis and evaluation.

BP1

- 21: Dispel Rumors

Public h ealth s yndromic surveillance analysis and data interpretation are often used to assist with dispelling rumors that an issue thought to be of public health significance is not actually
a threat.

BP1

- 22: Document Suspicion

Whether or not an issue is concluded to be significant, any suspicions along with the data, activities, results, analysis, and interpretation are documented. Documentation is important since an issue that is not considered significant at present may later be found to have signif ican ce over a time period.

BP1

- 23: Reporting
Depending on the purpose and context, reporting may be conducted in order to provide i ncreased situation awareness. Reports may be in the form of routine reporting or a SITREP.


### 3.1.1 Task Set 1 (TS1): Collect and Process Data

In this task set, the PHA collects data, pre

- processes the data to prepare them for automated analysis, and runs statistical algorithms against the data to provide the PHSS analyst an initial
set of results to review.

Objective: To collect data from data providers ; semantically (BP2) and syntactically validate and process data in order to make the data usable for analysis ; calculate counts ; and to run automated statistical algorithms on the processed data for the PHSS analyst to review.

Tri gger : ED / Urgent Care data sent by the data provider at least every 24 hours.

Input to the Business Process : Health Data; Context; Purpose

Output of the Business Process : Counts and results of the automated statistical algorithms,
which include time serie s and summary counts of flags. Within this business process, aggr egated, categorized data sets may be shared with external systems, such as Distribute 6 and BioSense.

6 Distribute is a project of ISDS that is dedicated t o real

- time data evaluation, allowing for more rapid surveillance and improved decision

- making.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 26 Figure 6 : Task Flow Diagram for TS1

– Collect and Process Data : The PHA collects and pre

- processes data to prepare them for automated analysis, and runs statistical algorithms against the data to provide an initial set of r esults for review.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 27 

## Collect and Process Data (TS 1)

The PHA collects and pre

- processes data to prepare them for automated analysis, and runs statistical algorithms against the data to provide an initial set of results for review.

All numbers refer to flow diagram for TS 1 (Figure 8) unless otherwise noted.

Collect Data

#1 : Data Provider Collects and Transmits a Batch of Patient Data to PHA (Bucket Method)

#2 : Data Provider Transmits Patient Data to PH A (Drip Method)

#3 : PH A Collected Records

• There are two identified ways in which data providers transmits data to the Public Health Authority (PHA)

o Bucket Method: The data provider collects records on their end and transmits

a batch of records to the PHA within the agreed timeframe (e.g. once every 24 hours). (TS1

- 1)

o Drip Method: The data provider transmits individual records without batching (TS1

- 2) by a more frequent time period (e.g. every 15 minutes) and the PHA collects the records prior to processing data (TS1

- 3). In this case, the colle ction/batching of records is conducted on the PHA side.

o The method of data delivery varies across juri s dictions and is established and agreed upon between the data provider and PHA.

• Filtering

- see detailed note at the bottom of this section about filtering of data.

o It is highly recommended that data providers transmit all available patient data as specified in this provisional recommendation and do not filter their data. The effectiveness of public health syndromic surveillance is greatly increased when all records a re available for analysis. It is recognized that there are juri sdictions that have data providers transmit select records (e.g. records that i ndicate a reportable disease condition).

#4 : PHA Receive Raw Data

• The PHA receives the raw data from the data provider.

#5 : ETL (Extract, Transform, Load) into Database

• Extract, Transform, and Load (ETL) is an automated process in which an individual r ecord (HL7, comma delimited, etc) is parsed and transformed so that the record can be loaded into the public health syndromic surveillance database.

• The load process may include very basic checks that preserve the integrity of the dat abase, such as verifying that record has a primary key, etc.

#6 : Newly Collected Data Set

• After the ETL process, the individual records are collected and a data set is created.

• Whether data are received from the data provider via the bucket or drip method, if needed, the PHA will collect data for a specific timeframe (e.g. 24 hours) prior to m o v-Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 28 

## Collect and Process Data (TS 1)

The PHA collects and pre

- processes data to prepare them for automated analysis, and runs statistical algorithms against the data to provide an initial set of results for review.

All numbers refer to flow diagram for TS 1 (Figure 8) unless otherwise noted.
ing forward. This is done so that the analysis of data is meaningful and complete.

• The collection timeframe will vary by jurisdiction and by individual data provider. For example, if the PHA normally receives 90% of a data provider’s records by 10:00am, it may proceed to the next step.

• The output of this step may be used as an input into the Conduct Data Quality business process (BP3),

Pre

- Processing Data

#7a : Validate Data Integrity for Syntactical Correctness

• For the newly collected data set, the PHA validates data integrity for syntactical co rrectness.

• Syntactical correctness is a “grammatical” check to verify that the record being tran smitted is complete and in the correct format, e.g. correct data type and length, no missing fields, etc. The me aning or interpretation of the data is not validated.

• Example: Syntactical validation fails due to a clerk entering a ‘pipe’ character in the chief complaint field, which is interpreted by the PH SS system as a new field, ther efore shifting all of the subs equent fields over.

#7b : Conduct Data QA (BP3)

• In addition to the validation of data for syntactical correctness, the PHA also conducts data quality assurance to verify 1) that data are received from all expected data pr oviders, and 2) the data are validated and corrected for semantic correctness, co mpleteness, and consistency (the meaning of the data). See Conduct Data QA business process (BP3) for further details on this task flow.

• The output of the Conduct Data QA business process is data that are semantically val idated, corrected, or accepted.

#8 : For Each Record, Insert and/or Selectively Update Fields

• The PHA system will insert and/or selectively update existing records based on synta ctical and semantically correct data on a matching identifier.

• There are variations in the type of identifiers that are used across jurisdictions for matching. Unique identifiers include fields such as Visit ID, Patient ID, Medical Record Number (often dif ferent from a more anonymous Patient ID) or a combination of ide ntifiers such as Hospital ID and Visit ID.

• The matching identifier helps determine if the record is a new record or an update of an existing record.

• For updates, not all fields will require up dating. The criteria of how, when, and what to update varies across jurisdictions. In addition, some jurisdictions may opt to concat enate updated values with original values rather than overwriting previous values.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 29 

## Collect and Process Data (TS 1)

The PHA collects and pre

- processes data to prepare them for automated analysis, and runs statistical algorithms against the data to provide an initial set of results for review.

All numbers refer to flow diagram for TS 1 (Figure 8) unless otherwise noted.

#9 : Validated, Updated Data Set

• After inserting new records or updating existing records, the data set is considered a validated, updated, or accepted data set by the PHA.

#10 : Prepare Individual Records For Analysis: Clean and Prepare Dataset for Categor ization (Spelling, Abbreviations, Char acter Negation, Grammar, etc).

• This step is part of the process of preparing the individual records for analysis.

• In this step, the PHA cleans and prepares the validated, updated dataset for categor ization. The process is done to improve the quality of the data.

• The approaches to processing varies across jurisdictions and can include any of the fo l lowing:

o Standardize text; remove punctuation; fix spelling; change abbreviations into whole words; remove CAPS; remove extra spaces; remove extra characters; fix punctuation; conduct character negation; fix grammar, etc.

• This is the pre

- processing step prior to text parsing conducted in the next step.

#11 : Prepare Individual Records For Analysis: Categorize Records into Syndromes, Sub

- syndromes, Health Conditions of Interest (Pre

- defined, New, Automated, Default, Routine)

• Once the data are cleaned, the PHA parses the text, categorizes and maps records to different syndromes, sub

- syndrome, and health conditions of interest. This step may
use natural language processing methods.

• Example: If chief complaint data says “I have nausea and am throwing up.” If the words “throwing up” and “nausea” are GI components, they would be mapped to the GI category.

• These categories that are used may be pre

- defined, ad hoc, automated, default, or ro utine. Ad hoc or new categories may be added as a default or routine category.

o Example: Pre

- defined or default categories may be disease conditions, such as varicella or meningitis, or an environmental exposure, such as a he at

related or cold

- related disease.

o Example: An ad hoc category may be developed as a result of a single, recent event with an elevated risk, such as an oil spill.

• The ad hoc queries are important within this step since it allows PHSS to adapt to and fur ther process data based on a particular context or situation that may be new or unique.

o This reinforces the need for data sent to the PHA for syndromic surveillance to
be unfiltered by the data provider . It provides the broadest flexibility for su rveillanc e activities in various contexts.

o This also reinforces the emphasized request by PHSS that the data providersFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 30 

## Collect and Process Data (TS 1)

The PHA collects and pre

- processes data to prepare them for automated analysis, and runs statistical algorithms against the data to provide an initial set of results for review.

All numbers refer to flow diagram for TS 1 (Figure 8) unless otherwise noted.

transmit the chief complaint field as a free text value, with the most d escriptive text available . Free text provides the greatest flexibility in categori zing records into conditions that may not be apparent or match coded values.

#12 : Prepare Individual Records For Analysis: Assign Individual Records to Person, Time, and Place Strata (Age Group, Geographic, etc)

• After categorizing records into syndromes, sub

- syndromes, or health conditions of i nterest, the PHA assigns or “bins” the records into person, time, and place strata.

o Examples of strata: age group; facility or hospital system; geographic region; disposition.

• Ad hoc strata may be created , used, and incorporated as part of the default stratific ation groups.

• The assigning of records to strata may be saved and stored in the PHSS database, or may be conducted through the system interface as a “report” or “view’ of the data without saving.

#13 : Categorized Data Set

• The output of the Prepare Individual Records for Analysis process results in a categ orized data set ready for analysis.

#13a : Output: Data to External Systems (e.g. Distribute, BioSense)

• Sometime during the Pre

- Processing Tasks, the PHA may send data to external sy stems, such as Distribute or BioSense.
Processing Data (Automated)

#14 : Calculate Counts of Categorized Data By One or More Strata for Population Analysis (Configurable)

• The PHA takes the categorized data and has the PHSS system calculate counts of the categorized data by one or more strata for population analysis.

• There is variation in what strata are used across jurisdictions. Strata include: sy ndromes and sub

- syndromes ; age group; zip code; hospital; gender; other dem ographics.

• These counts may or may not be stored in the database.

• Strata are configurable.

#15 : Analysis Data Set

• After counting by strata, the data set is now available for automated statistical alg orithms.

#16 : Run Automated Statistical Algorithms (Configurable)

• The PHA takes the analysis data set and runs automated statistical algorithms using itsFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 31 

## Collect and Process Data (TS 1)

The PHA collects and pre

- processes data to prepare them for automated analysis, and runs statistical algorithms against the data to provide an initial set of results for review.

All numbers refer to flow diagram for TS 1 (Figure 8) unless otherwise noted.
syndromic system. Systems, such as ESSENCE 7 , allow multiple data sources to be compared.

• With most systems, the PHA may recalibrate their algorithms as needed. Statistical a lgorithms are automated, but not static, so custom and ad hoc statistical algorithms may be added and configured. In addition, custom or ad hoc algorithms may be added as a default o r “automated” algorithm.

• Statistical algorithms may include time series, maps, summary counts of flags, co mparison of results to historical data.

• The context and purpose (inputs) may affect the type of statistical algorithms that are

run. For example, if there is limited baseline data, the timeframe for any statistical a lgorithms run may be limited to daily trends.

#17 : Post Results for Surveillance Analyst

• Following the running of statistical algorithms on the data set, the PHSS system posts the results for the surveillance analyst.

o The analyst may include: the Public Health syndromic surveillance coordin ator; PH nurse; epidemiologist; analyst.

• After reviewing the data and reviewing any flags, the surveillance analyst may choose to rerun the automated statistical algorithms on a subset of the data set, or on add itional data.

7 http://essence.jhuapl.edu/ESSENCE/Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 32 Additional Notes and Recommendations Related to the Task Set:

Filtering

It is highly recommended that data providers do not filter their data and transmit all available data elements as specified in this recommendation.

The power and effectiveness of PHSS is significantly increased when all records are available to the PHA for epidemiological analysis. Complete, unfiltered dat a are the basis for a robust and clear picture of community health. Filtering records at a facility level applies a selection process that may bias the results of epidemiological analyses on an inter

- facility or inter

regional level, thereby limiting situa tion awareness and a PHA’s ability to assess population
health.



### 3.1 .2 Task Set 2 (TS2): Characterize, Interpret, and Analyze Data

This task set is the central activity that the public health syndromic surveillance ( PH SS) unit
conducts. This task set is the “art of syndromic surveillance,” where characterization of data and manual analysis and review are conducted in order to understand the meaning and signif icance of the data.

Objective of the Business Process : To characterize, interpret, and analyze the da ta to unde rstand the meaning and significance of the data.

Trigger : Completion of Task Set 1 (TS1) Collect and Process Data

. Input to the Business Process : Results generated from Task Set 1 (TS1) Collect and Process
Data ; Health Condition of Interest; Purp ose; Context; Level of Authority; Data from Other Public Health Processes; Outside Influences.

Output of the Business Process : Conclusions and Results of Characterization and Pattern Analysis; Health Condition of Interest; PurposeFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 33 Figure 7 : Task Flow Diagram for TS2

– Characterize, Interpret, and Analyze Data : This task set is the central activity that the public health syndromic surveillance ( PH SS) unit conducts. It is the “art of syndromic surveillance,”
where ch aracterization of data and manual analysis and review are conducted in order to understand the meaning and significance of the data.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 34 

## Characterize, Interpret, and Analyze Data (TS 2)

This is the “art of syndromic surveillance,” where characterization of data and manual analysis and review are co nducted in order to understand the meaning and significance of the data.

Numbers refer to the flow diagram from TS 2 (Figure 9) unless otherwise noted.
Characterize and Interpret Results

#1 : Review Results from TS2
, #2 : Run Ad Hoc Analysis,

#3 : Characterization of Results

• The PHSS Analyst manually reviews the result generated from Task Set 1 (TS1) Collect
and Process Data , runs ad hoc analysis of the data, and uses a variety of methods to
characterize the results.

o Examples of individuals that may fill the PHSS analyst role include, the Public Health syndromic surveillance coordinator, a PH nurse, an epidemiologist, and/or other PHA

- designated staff.

• These three tasks, (TS2

- 1) (TS2

- 2) (TS2

- 3), occur in conju nction with one another. The three tasks proceed in a circular flow, where the results of one task may affect a se cond task, which may then prompt or affect the third task conducted.

o Different inputs and variables will affect how the three tasks are engage d. This process may be repeated in different ways taking into account different inputs, such as the context or health condition of interest.

o As the three tasks are conducted, there is an output of increased information about the health condition of intere st and purpose. Both of these variables are also inputs into this task set.

• Menu set of characterization methods: The analyst uses any of the following methods, as applicable, for the characterization of data. The list shows a representative list of
charac terization methods; it does not necessarily represent an exhaustive list. As a menu set, all of the methods are optional and select methods may be applied. The o rder in which the methods are listed does not imply a linear order:

o Sorting and Grouping: By zi p code; age group; disposition; facility; time of arr ival, syndromes, sub

- syndrome combinations.

o Frequency and Distribution Analysis

o Time Series Analysis: Compare the trend line over time, e.g. looking at the

mo v ing average over 7 days.

o Time Series Analysi s Across Historic Norms (Years): Compare current data against data over previous years, e.g. Flu is 5 times higher this year than last
year.

o Line

- Listing / Drill Down

o Other Statistical Algorithms

o Review Flags:

! Review flags generated by automated statistic al algorithms in TS1: Co l-Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 35 

## Characterize, Interpret, and Analyze Data (TS 2)

This is the “art of syndromic surveillance,” where characterization of data and manual analysis and review are co nducted in order to understand the meaning and significance of the data.

Numbers refer to the flow diagram from TS 2 (Figure 9) unless otherwise noted.

lect and Process Data , and

! Review additional flags generated during the refinement of results within
this task set.

o Generate Flags: Generate additional flags as a result of further refinement and analysis of data within this task set.

o Geo

- Spatial Analysis (Facility, Zip Code of Residence): Maps; geographical representation and/or spatial

- oriented flags, e.g. comparison of data from where a patient lives vs. where the patient receives care (which hospital they presented).

o Severity A ssessment

o Data Quality Check: Internal Consistency, Misclassification

• The characterization methods are applied as appropriate for the Context, Health Cond ition of Interest, and whether a baseline had been established.

o For example, if the context is a sing le event classified as a present elevated risk of short duration, then a baseline may not exist nor can be established. Thus, the time series analysis across historic norms would not be applicable.

• The analyst applies the selected characterization method o n a single data source. The characterization method is repeated for each data source.

#4 : Output: Characterized Results

• For each data source, the PHSS analyst analyzes, interprets, and characterizes the r esults. The output is a series of characterized results for each data source.

#5 : Conduct Data QA (BP3)

• Throughout this task set, the PHSS analyst may conduct data quality assurance (BP3) on the data in order to further refine and improve data quality.

• In BP3, the analyst verifies that the data are validated and corrected for semantic co rrectness, completeness, and consistency (the meaning of the data). See Conduct Data QA business process (BP3) for further details on this task flow.

• The output of the Conduct Data QA business process is data that are semantically val idated or corrected.

Synthesize / Characterize Results in Context

#6 : Pattern Analysis Across Syndromic Data: Compare Outcomes Across Individual Characterizations (TS2

- 4 Output) for Corroboration or Mosaic

• Once each PHSS data source has been analyzed, interpreted, and characterized, the PHSS analyst compares and combines the data sources with each other.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 36 

## Characterize, Interpret, and Analyze Data (TS 2)

This is the “art of syndromic surveillance,” where characterization of data and manual analysis and review are co nducted in order to understand the meaning and significance of the data.

Numbers refer to the flow diagram from TS 2 (Figure 9) unless otherwise noted.

• The analyst conducts a pattern analysis across all syndromic data. By comparing and combining data, the analyst assesse s patterns across the data sources to see if there is a larger, overall pattern of the data through a mosaic or Gestalt perspective.

• The analyst looks for patterns that raise suspicions or flags.

o Example: An analyst is monitoring and observes an unexpect ed pattern (e.g. age distribution) that may be meaningful and warrant additional investigation, but may not have raised a flag through the automated system analysis (TS1) because it does not have statistical significance.

• This task is conducted by the PHS S Analyst and/or PHA

- designated staff in conjunction with TS2

- 6: Factor Information From Other Sources and TS2

- 8: Pattern Analysis: Compare Outcomes Across Non

- Syndromic Data.

#7 : Factor Information From Other Sources (e.g. Colleagues, Other Situation Inf orm ation, Media)

#8 : Pattern Analysis: Compare Outcomes Across Non

- Syndromic Data

• In synthesizing data for interpretation, the PHSS analyst and/or PHA

- designated staff analyzes other sources and factors for additional information. Other sources include
i n formation within PHSS (e.g. other colleagues, epidemiologists, field staff; Distrib ute data); within public health (e.g. other situation information, NEDSS); and outside of public health (e.g. weather patterns, media reports, other governmental agencies and offices).

• In using additional data sources, the analyst and/or PHA

- designated sta ff looks for pa tterns of concern and compares outcomes across non

- syndromic data.

• This task is conducted in conjunction with TS1

- 6: Pattern Analysis Across Syndromic
Data.

#9 : Refine Analysis?

• The PHSS analyst and/or PHA

- designated staff determines if the results have been r efined to the point where the analyst is able to draw meaning out of the results, draw conclusions or interpretations, has excluded all null hypotheses, and/or satisfied all of the important questions.

• If the answer is no, then the analyst reengages the task set and continues the manual analysis, interpretation, and characterization until a meaningful result is attained or null hypothesis is proved.

• If the answer is yes, then the results have been refined enough so that the results h ave meaning and the analyst is able to contribute to / advise the next steps.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 37 

### 3.1 .3 Task Set 3 (TS3): Notify and Engage Partners / Leadership

When a potential public health concern is identified and escalated, the public health syndromic surveillance u nit notifies and engages relevant partners and leadership when applicable, to d etermine follow

- up actions.

Objective of the Business Process : To notify and engage relevant partners and leadership to determine whether to further escalate a potential public health concern.

Trigger : A potential public health concern is escalated and determined that relevant partners and/or leadership is necessary to determine next steps.

Input to the Business Process : Results generated from Task Set 2 (TS2) Characterize, Inte rpret, and Analyze Data.

Output of the Business Process : Decision to further escalate the potential public health co ncern.

Figure 8 Task Flow Diagram of Task Set 3 (TS3)

– Notify and Engage Partners/Leadership: When a potential public health concern is identified and escalated, the public health syndromic surveillance unit notifies and engages relevant partners and leadership when applicable, to determine follow

- up actions.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 38 

## Notify and Engage Partners / Leaders hip (TS 3)

When a potential public health concern is identified and escalated, the public health syndromic surveillance unit notifies and engages relevant partners and leadership when applicable, to determine follow

- up actions.

Numbers refer to the flow diagram from TS 3 (Figure 10) unless otherwise noted.

#1 : Engage Relevant Partners (e.g. Local, Regional, State Authority, Colleague, or Designee

• Relevant partners are engaged so that a determination can be made on next steps of whether to continue to escalate the issue or to abort. Partners include local, regional, state authority, colleague or designee. Partners include both

pu b lic health and preparedness. The partners engaged vary across jurisdictions and level of authority.

• Some jurisdictions may no t need to evaluate whether leadership should be e ngaged at this point. For these jurisdictions, the PHA and relevant partners may review and confirm conclusions from previous tasks and proceed to determining the next steps.

• For jurisdictions that may need to engage leadership, the PHA and relevant partners determine if this issue is high profile / priority.

#2 : High Profile / Priority?

This question is answered by the PHSS unit and engaged partners. The issue is categ orized as high level priority based on health condition of interest, outside influences, pu rpose, and context.

#3 : Engage Leadership
If the issue is categorized as high priority, then leadership is engaged.
Once leadership is engaged, leadership makes a decision on the next steps.

#4 : Review and Confirm Conclusions from Characterize, Interpret, and Analyze Data Task Set (TS2)

If the issue is not high profile/priority, the PHSS unit and relevant engaged partners r eview and confirm the conclusions from Characterize, Interpret, and Analyze Data (TS2).Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 39 

### 3.1 .4 Task Set 4 (TS4): Conduct Reach

- back

Reach

- back is the process of acquiring additional data about patient(s) where there is a pote ntial public health concern. Reach

- back is conducted when the PHA needs additional inform ation t o determine whether a response should be initiated.

Objective of the Business Process : To conduct reach

- back for additional patient data to i nform the decision of whether to escalate a response for a potential public health concern.

Trigger : Decision to conduct reach

- back for additional data.

Input to the Business Process : Health Condition of Interest; Level of Authority; Purpose

Output of the Business Process : Additional information to inform the decision of whether to
further escalate a r esponse for a potential public health concern.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 40 Figure 9 : Task Flow Diagram of Task Set 4 (TS4): Conduct Reach

- back: Reach

- back is the process of acquiring additional patient data where there is a potential public health concern . Reach

- back is conducted when the PHA needs additional information to determine whether a response should be initiated.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 41 

## Conduct Reach

- back (TS 4)

Reach

- back is the process of acquiring additional patient data where there is a potential public health co ncern. Reach

- back is conducted when the PHA needs additional information to determine whether a r esponse should be initiated.

Numbers refer to the flow diagram for TS 4 (Figure 11), unless otherwise noted.

#1 : Query for Relevant Record(s) (Candidate Cases)

• The PHSS analyst queries the PHSS database for the relevant record (candidate case)

#2 : Acquire Record “Key” (e.g. Medical Record Number, Patient Identifier)

• During the query, the PHSS analyst acquires the unique record. The record “key” that is used varies across jurisdictions. Examples include: medical record number, unique patient identifier, visit identifier, and any combination of identif iers.

#3 : Check Accessible Systems for Additional Information (e.g. Reportable Disease Database)

• The 

### PHSS Analyst and/or PHA

- designates staff may first check accessible systems, such as the reportable disease database, for additional information. There are cases when these accessible systems may provide enough inform ation to proceed to the next step.

• For example, if the syndromic data indicates ‘measles’, and the reportable di sease database has a record of a person with a matching profile (using key a ttributes such as age, gender, facility location, etc) seen on the same date, then the analyst may decide to end the reach

- back process since the case is already being investigated.

#4 : Contact Data Provider?

• Based on the available information discovered through the accessible systems,
the PHSS analyst determines whether the data provider should be contacted for additional information.

#5 : Contact Data Provider and Request Additional Patient Information

• If the PHSS analyst decides to contact the data provider for additional inform ation, then the PHSS analyst proceeds to contact the data provider and makes a request for additional patient information.

#6 : Gather and Provide Additional Patient Information to PHA

• The PHSS analyst gathers any additional patient information from the da ta pr ovider and provides the results to the PHA.

#7 : Determine Next Action

• If the PHSS analyst decides not to contact the data provider, then the analyst will determine the next set of actions.

• Once the PHSS analyst gathers and shares with the PHA any additional patient information from the data provider, the analyst and the PHA determine the nextFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 42 

## Conduct Reach

- back (TS 4)

Reach

- back is the process of acquiring additional patient data where there is a potential public health co ncern. Reach

- back is conducted when the PHA needs additional information to determine whether a r esponse should be initiated.

Numbers refer to the flow diagram for TS 4 (Figure 11), unless otherwise noted.

set of actions. 

### 3.2 Establish and Maintain Data Sharing Partnerships (BP 2)

The core syndromic surveillance activities rely on conclusions drawn from data that are chara cterized, interpreted, and analyzed. This business process establishes the partnerships between the PHA and data providers so that the PHA may receive data to conduct public health sy ndromic surv eillance.

Objective of the Business Process : To establish and maintain data sharing partnerships for the purpose of obtaining data to conduct PHSS

. Trigger : The public health authority (PHA) identifies a potential data sharing partner.

Input to the Busin ess Process : Context; Health Condition of Interest.

Output of the Business Process : An established data sharing partner.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 43 Figure 10 Task Flow Diagram for BP2: Establish and Maintain Data Sharing Partnerships: Data sharing par tnerships are established for the purpose of obtaining data to conduct public health syndromic surveillance.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 44 

## Establish and Maintain Data Sharing Partnerships (BP 2)

Data sharing partnerships are established for the purpose of obtaining data to conduct publi c health syndromic surveillance.

All numbers refer to the flow diagram for BP 2 (Figure 12) unless otherwise noted.

BP2

- 1 : Ensure necessary laws, regulations, policy, or legal agreements in place to
establish transactions

• Prior to establishing any data sharing partnerships, the PHA ensures that all of
the necessary laws, regulations, policy, or legal agreements are in place to be able to establish transactions

BP2

- 2: Develop a strategy and approach for prioritizing implementation queue

• The PHA develops a strategy and approach for prioritizing the implementation of data sharing with data providers. This step is important to identify from the PHA perspective which data providers need to be prioritized in order to incr ease e ffectiveness of public health syndromic surveillance.

BP2

- 3 : Establish contacts and relationships with health care setting leadership or designee

• The PHA establishes contacts and relationships with the leadership of the health care settings and/or their designee. Buy

- in and support from the healthcare se tting leadership is important to strengthen the partnership.

• Both parties discuss and agree on the purpose, roles, responsibilities, and e xpectations of the data sharing partnership. As part of estab lishing the partne rship, the PHA 

### provides basis and rationale 

### to the data provider to justify the need for the requested data, and what the data provider may expect in return, e.g. how their data will be protected.

• There may or may not be a formal data sh aring agreement established between the data provider and the PHA. Data sharing partnerships vary widely across j urisdictions and data providers.

BP2

- 4: Negotiate data elements for sharing

• Data provider and receiver negotiate the data elements that will be shared and discuss any local or state

- specific laws or regulations that may affect data sha ring.

BP2

- 5: Legal Approval / Agreement Needed?

• This question may be answered by the data providers (health care setting) to d etermine if legal approval / agreement is needed prior to the data sharing partne rship being established. Some data sources (e.g. temporary med tents at the Boston Marathon) may or may not need same level of legal agreement.

BP2

- 6: Legal review and approval

• If required, the data provider conducts a legal review and provides approval for the data sharing partnership.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 45 

## Establish and Maintain Data Sharing Partnerships (BP 2)

Data sharing partnerships are established for the purpose of obtaining data to conduct publi c health syndromic surveillance.

All numbers refer to the flow diagram for BP 2 (Figure 12) unless otherwise noted.

BP2

- 7: Hand

- off for implementation

• The data sharing specifications are handed off to staff who will implement the data sharing.

BP2

- 8: Establish procedures and contacts for follow

- up

• The PHA and data provider establish procedures and contacts for follow

- up. Fo l low

- up contacts include both: 1) technical contacts for data transmission i ssues, and 2) clinical contacts in the event that the PHA needs to “break the glass” and 

### request additional data about patients while conducting sy ndromic surveillance, and 3) administrative contacts for procedural or u nresolved technical or clinical issues

. BP2

- 9: Collect facility registration data/complete facility registration survey

• If used, facility registration metadata are captured for the data provider through

a facility registration survey that the data provider completes.

• Many jurisdictions capture and facility data used as metadata in order to
strea m line data transmissions and prevent the need for facility data elements (such as facility address) to be sent repeatedly. Only the facility identifier would
be sent with the da ta and the identifier would be cross

- referenced to a facility registration database maintained by the PHA.

• See Section 4 for additional information about Facility Registration data.

BP2

- 10: Establish contacts and relationships with data provider technical staff

• The PHA establishes contacts and relationships with the technical staff of the data provider to begin implementing the data sharing specifications.

BP2

- 11: Identify and configure data transmission mechanism

• The data provider technical staff identifies and configures the data transmission
mechanism. The type of data transmission mechanism is determined by the PHA and may include, but is not limited to: NHIN, PHIN

- MS, VPN, sFTP, EBXML, HTTPS

. BP2

- 12: Identify message format (e.g., HL7 me ssage definition)

• The PHA and data provider technical staff work together to identify the message format that will be used for data transmission, e.g. the HL7 message definition.
Testing: Message Validation

BP2

- 13: Send a test message for validation to an external validator (e.g., NIST)

• The data provider is instructed to transmit a test message for validation, such as to an external validator, such as NIST, to conduct basic message validation and help troubleshoot basic message construction issues.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 46 

## Establish and Maintain Data Sharing Partnerships (BP 2)

Data sharing partnerships are established for the purpose of obtaining data to conduct publi c health syndromic surveillance.

All numbers refer to the flow diagram for BP 2 (Figure 12) unless otherwise noted.

BP2

- 14: Pass?

• The question is answered by the data provider once the test message is tested against the validator.

BP2

- 15: Transmit a test message(s) to public health authority's (PHA’s) test env ironment

• Once the test message passes the baseline test a gainst the validator, the data provider transmits a test message(s) to the PHA’s test environment.

BP2

- 16: Pass Message Validation Testing?

• This question is answered by the PHA once the data provider transmits a test message to the PHA’s test environment.

• If the test does not pass, then the PHA and data provider identify the issue and resolve the problem. The data provider is instructed to re transmit the test me ssage to the PHA’s test environment.
Testing: Tuning

BP2

- 17: Commence routine data transmission to PHA’s test environment

• If the message validation testing passes, then the data provider is instructed to commence the testing phase of regular ongoing data transmission to the PHA’s test server to determine the steps needed, if any, to fine

- tune the data.

BP2

- 18: Identify and control for systemic idiosyncrasies by facility/system of the data (esp. chief complaint or other free text data)

• Once the testing phase of regular ongoing data transmission is initiated, the PHA begins to identify and determine how to control for systemic idiosyncrasies that are produced by the data provider system.

BP2

- 19: Conduct f ace validity check (e.g., compare to pre

- existing data, logs, le gacy system, metadata information)

• The PHA and the data provider conduct a face validity check of the data, inclu ding comparing the data against pre

- existing non

- HL7 PH SS data, logs, legacy system data, and metadata i nformation

BP2

- 20: Conduct t imeliness and completeness checks

• The PHA and data provider check on the timeliness of data transmissions and the completeness of data being transmitted.

BP2

- 21: Pass Tuning Testing?

• This question is answered by the PHA once the data are fine

- tuned and val idated.

• Note that the process of tuning the data and testing data against the test serverFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 47 

## Establish and Maintain Data Sharing Partnerships (BP 2)

Data sharing partnerships are established for the purpose of obtaining data to conduct publi c health syndromic surveillance.

All numbers refer to the flow diagram for BP 2 (Figure 12) unless otherwise noted.
may be an extended period of testing, such as 30

- 60 days.

• If the data do not pass tuning testing, then the PHA and data provider collab orate to identify and resolve any issues. The data are put through the tuning tes ting process until the data pass.

BP2

- 22: Commence routine data transmission to PHA’s production server

• If the data pass the tuning testing, the data provider is instructed to commence routine data transmission to the PHA’s production server.

Testing: Production Validation

BP2

- 23: Conduct Data QA ( BP3)

• Once data are transmitted to the PHA’s production server, the testing of data undergoes the data quality assurance business process as described in BP3: Conduct Data Quality Assurance.

BP2

- 24: Pass Production Validation Testing?

• This question of whether the data transmission passes production validation testing is answered by the PHA.

• If the data transmission passes production validation testing, then this process is completed and the data provider begins reporting its data.

BP2

- 25: Keep in Production ?

• If the data transmission does not pass production validation testing, then the PHA determines whether it can continue to be tested against the production server, or whether the testing must go back to the testing protocol. 

### 3.3 Conduct Data Quality Assurance (BP 3)

The PHA conducts quality assurance to determine whether data are being transmitted from expected data partners and whether the data being transmitted are semantically correct, co mplete, and consistent with data normally sent by the data pr ovider.

Semantic correctness refers to validation of the meaning of the data and whether the code va lues and/or interpretation of the data are correct. In this business process, the PHA troubl eshoots any errors that prevent data from being transmitted. After semantically evaluating transmitted data, if any “flaws” exist, the PHA will control for the “flaws”, accept the data as they are, or collaborate with the data provide to correct the “flaws” if possible. The determin ation of “flawed” data is from a p ublic health perspective to verify whether the data can be used
for PHSS

. Objective of the Business Process : To conduct quality assurance on data being reported for public health syndromic surveillance and to resolve any data reporting issues.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 48 Trigger : Com pletion of Collect Data tasks within Task Set 2 (TS1) Collect and Process Data

. Input to the Business Process : Context; Health Condition of Interest; Purpose.

Output of the Business Process : Semantically validated, corrected, or accepted data source(s).Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 49 Figure 11 : Task Flow Diagram of Business Process 3 (BP3)

- Conduct Data Quality Assurance: Quality assu rance is conducted on the data in order to determine 1) whether data are being transmitted from all of the expected data partners, and 2) whether the data being transmitted are semantically correct, complete, and consistent with data normally sent by the data provider.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 50 

## Conduct Data Quality Assurance (BP 3)

Quality assurance is conducted on data being reported for PHSS and to resolve any data repor ting issues.
All numbers refer to the task flow diagram for BP 3 (Figure 13) unless otherwise noted.

BP3

- 1: Did Expected Data Providers Transmit Data to Public Health Authority (PHA) ?

• Transmission

- level check: This question is answered by the Public Health Autho rity (PHA) to determine whether the PHA has received all expected data from all of their data sharing partners. The expectation is based on the data sharing agreement established between each data provider and the PHA in Business Process 2 (BP2)

– Establish a New Data Sharing Partner

. BP3

- 2: For Each Data Source, Validate Data for Semantic Correctness (e.g. Code Values), Completeness, Consistency. Includes both automated checks and ident ification of end user problems.

• For each data source, the PHA validates the semantic correctness, completeness, and consistency of the data.

• Semantic correctness refers to validation of the meaning of the data. The valid ation checks whether the code values and/or interpretation of the da ta are co rrect. Translation errors are corrected on the PHA side.

o Example of code value validation: The data sent for the field, Patient Class, contains a value “Newborn” that is not a part of the expected code set for the field.

o Example of interpretation validation: Chief complaint contains “OD”, which is translated to “Right Eye” instead of the correct translation of “Overdose”.

o Example: the abbreviation of “ms ” for “ mother states” is translated into “mental status”, resulting in a large number of neurol ogical flags.

• Completeness validation refers to the completeness of

o The data set. Based on the data provider’s reporting history, the PHA d etermines if it appears as though only a portion of the expected entire vo lume of the data provider’s records have been sent.

o Individual data elements. In addition to completeness, the semantic v ali d ity of each or selected data elements is assessed. (e.g., completeness of gender and expected ratio of gender values).

• Consistency validation refers to whether the data bei ng sent are inconsistent with previously sent records from the data provider. Example: The gender of a p atient is reported as “ Male ” , whereas the previously reported gender of the same patient was “ Female ”

. BP3

- 3: Any “Flawed” Data?

• This question is answered by the PHA after semantic validation has been co mpleted. The determination of “Flawed” Data is from a public health perspective to verify whether the data can be used for syndromic surveillance. See BP3

- 2 for the description of semantic validation to determine if data is “flawed”.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 51 

## Conduct Data Quality Assurance (BP 3)

Quality assurance is conducted on data being reported for PHSS and to resolve any data repor ting issues.
All numbers refer to the task flow diagram for BP 3 (Figure 13) unless otherwise noted.

BP3

- 4: Assess Impact

• If the data is categorized as ‘’flawed” in any way, the PHA assesses the impact or severity of any “flaws”.

BP3

- 5: Workaround by PHA?

• This question is answered by the PHA receiving the data. Based on the asses sment of the impact of any “flawed” data, the PHA determines whether it can conduct a workaround to be able to use the data for PHSS

. BP3

- 6: Control for Semantic Error in Pre

- processing or Interpretation. Develop New Method to Adjust or Control for Error . Accept “flawed” data if useable.

• If the PHA determines that it can conduct a workaround for the “flawed” data, or that the data are useful in a “flawed” state, it proceeds to control for the sema ntic error or accept the data with the known limitations. New methods for adjus ting or controlling for any errors are developed as needed.

BP3

- 7: Problem with Receiving System at PHA?

• This question is answered by the PHA if an expected data provider has not sent their data, in order to determine if the error is caused by the receiving system at the PHA. The PHA conducts an internal investigation of its receiving system to make the determination.

BP3

- 8: Fix Problem with Receiving PHA System

• If the PHA determines that the error in accepting the data from the data provider is caused by the receiving PHA system, the PHA fixes the problem with its sy stem.

BP3

- 9: Is Back Data Available?

• The PHA asks the data provider whether back data are available during errors where the data was not received by the PHA.

BP3

- 10: Recover Data: Request Back Data

• The PHA requests back data from the data provider to recover any data not r eceived.

BP3

- 11: Notify Data Provider of Missing/”Flawed” Data

• If PHA determines that the missing expected data is not due to the receiving PHA system, then the PHA will notify the data provider of the missing data.

• If PHA receives data from the data provider but assesses that the impact of any “flaws” is too severe or a workaround not possible, then the PHA will noti fy the data provider with details of the “flawed” data.

BP3

- 12: Determine Cause(s) of Missing/”Flawed” Data

• The PHA works with the data provider to identify the cause of the error whereFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 3

. Schematics: Core Business Process and Task Set Schematics

ISDS Meaningful Use 52 

## Conduct Data Quality Assurance (BP 3)

Quality assurance is conducted on data being reported for PHSS and to resolve any data repor ting issues.
All numbers refer to the task flow diagram for BP 3 (Figure 13) unless otherwise noted.
data is not being reported. Causes of the error may include:

o Data transmission protocol error

o Hardware issues

o Data provider information system issues

o Data aggregator issues

o Other software issues

BP3

- 13: Collaborate with Data Provider to Solve Issue with Reporting

• Once the cause of the error is determined, PHA collaborates with the data pr ovider to resolve the problem.

BP3

- 14: Test Data Reporting, Transmission, Receipt of Data

• Once the data error is determined as being resolved, the PHA and data provider test the data reporting, transmission, and receipt of data.

BP3

- 15: Document Data Issues or Gaps. Add Disclaimers to Reports as Needed

• PHA will document any issues, workarounds, or gaps in the data, and add di sclaimers to reports as needed, when:

o PHA controls for any semantic errors in data, which may impact the analysis of the data.

o Back data are not recoverable

o Any issues or problems are noted that may impact analysis of the data.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4

. Core EHR Requirements for Syndromic Surveillance

ISDS Meaningful Use 53 

## 4

. Core EHR Requirements

ISDS recommends the following requirements for data transmission, reception, and minimum data set for public health syndromic surveillance. It is to guide and pr ovide a foundation upon which stakeholders can build messaging requirements for the syndromic surveillance Meanin gful Use objective.

The following recommendations may need to be adapted to the laws and practices of the local or state jurisdiction

. 

### 4.1 Tran smission and Reception of Data

This section focuses on the transmission of electronic health data from healthcare providers (senders) and reception by public health authorities (receiver). Health data transmitted are ca ptured in a health information system during a patient’s visit to a healthcare facility.

Senders within the scope of this recommendation include: hospitals, emergency departments, urgent care centers, hospital corporations, corporate third party operators of information br okers, regional data centers for hospitals, health information exchanges (HIE), and regional health information organizations (RHIO).

Receivers are state and local public health authorities, or a designated third party

. A public health authority (PHA) is broadly defined a s including agencies or authorities of the United States, states, territories, political subdivisions of states or territories, American Indian tribes, or an individual or entity acting under a grant of authority from such agencies and responsible for publ ic health matters as part of an official mandate 8

. 

### 4.1.1 Frequency

The frequency of data transmitted from the sender to the receiver is at least every 24 hours.

All parties involved in the transmission ( e.g. , eligible healthcare provider, EHR technology ve ndor, information brokers, and PHA ), will need to determine and agree upon the specific, r equired periodicity of data exchange for particular jurisdiction s

. 

### 4.1.2 Emphasis on Unfiltered Data

It is highly recommended that data providers do not filter thei r data and transmit all available
data elements as specified in this recommendation.

The power and effectiveness of PHSS is significantly increased when all records are available to the PHA for epidemiological analysis. C omplete , unfiltered data are the basis for a robust and clear picture of community health. Filtering records at a facility level applies a selection process that may bias the results of epidemiological analyses on an inter

- facility or inter

regional level , thereby limiting situation aware ness and a PHA’s ability to assess population
health.



### 4.1.3 Updating

Data providers should transmit all fields as specified by the data set specifications. When a field’s value is updated in the data provider’s system, the updated record should be sent to the

8 Thacker, S., “HIPAA Privacy Rule and Public Health, Guidance from CDC and the U.S. Department of Health and Human Services”, MMWR, April 11, 2003 / 52;1

- 12Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4

. Core EHR Requirements for Syndromic Surveillance

ISDS Meaningful Use 54 PHA. Exceptions to this are specifically indicated in the minimum data set (Table 4)

. The criteria for how, when, and what to update may vary across jurisdictions.

PHA ’s use unique identifiers to match and reconcile records for updating. There are variations in the type of identifiers that are used across jurisdictions for matching. Unique identifiers i nclude fields such as Visit ID, Patient ID, Medical Record Number (often different from a more anonymous Patient ID), or a combination of identifiers such as Hospital ID and Visit ID. The matching identifier is used to determine if the record is a new record or an update of an exis ting record. Some PHA ’s may opt to concatenate updated values with existing values in the PHSS data set rather than overwri ting previous values.



### 4.1.4 Anonymized / Pseudonymized Data

Anonymizing data is the process that removes the association between identifying data and
the patient . Pseudonymizing data is the process by which identifying fields within a data record are repla ced by artificial identifiers.

In addition to HIPAA, variations in state and local laws restrict or allow various degrees of ide ntifying data to be exchanged between data provider s and the PHA. Individual jurisdictions
should develop their specifications in accordance with applicable state and local laws.

Developing a standard approach for anonymizing and/or pseudonymizing data is out of scope for this Final Recommendation. Identifying a standard approach to anonymize and pseud onymize data is recommended f or future efforts

. Any work done to develop a recommended a pproach should reference e xisting national standards that address this issue, such as HITSP /C39

. 

### 4.2 Facility Registration Data

When data sharing partnership s are established (as described in the business process: Esta blish and Maintain Data Sharing Partnerships (BP2) ) , s ome PHA’s may choose to register facility
metadata to identify , validat e , and assess data transmission . The use of facility registration
data may streamline d ata transmission by eliminat ing the need for select data elements, such as treating facility address and data transmitter address, to be repeatedly sent.

The meta data captured to register a facility may include , but not limited to :

• Facility Name

• Facility Location / Address

• Unique Facility Identifier

• Umbrella Organization, if applicable

• Facility Type or Specialty

As State

- wide Health Information Exchanges (HIEs) develop

, facility registration must be further developed to ensure that the facility metadata ar e current

, complete, and accessible to PHA’s for PHSS

.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4

. Core EHR Requirements for Syndromic Surveillance

ISDS Meaningful Use 55 

### 4.3 Key Terms and Definitions

This section defines the table columns used in section 4.4, which contains the reco mmended minimum data set.

Table 12 : Description of table columns used in section 4.4, which contains the recommended minimum data
set

Column Name Definition

Data Element Name Name of the minimum data set element.

Description of field Description of the data element

Usage Refers to whether an element is a required or optional field. The Usage codes are:

R

– Required: Indicates that the field is a required field and must be supported by the EHR system. A value must be pr esent in the field in order for the message to be accepted.

RE

– Required, but can be empty: Indicates that the field is a required field and must be supported by the EHR system. The reporting of data is setting

- specific. If data are present, then they must be reported. However, if there are no data captured in the f ield due to the setting (e.g. no chief complaint data for a trauma patient) and the field is blank, the message may be sent with the field containing no data.

O

– Optional: Indicates that this field must be supported by the EHR system, but the transmissio n of the values captured in these fields is optional. Specific usage of these data elements
shall be determined at the state or local

- level jurisdiction.

Cardinality Minimum and maximum number of times the element may a ppear.

Notes Additional notes describing rules pertaining to the data el ement, processing of the data element field, or identifying rel evant values for the data element.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4. Core EHR Data Requirements 4.4 Minimum Data Set

ISDS Meaningful Use 56 

### 4.4 Minimum Data Set

The following table contains a minimum list of data elements commonly used by PHA’s to conduct PHSS

. This list does not repr esent the entire list of data elements needed to support the full spectrum of current practice. Therefore, the actual data elements and specifications are subject to change in accordance with applicable state and local laws and practices.

Table 13 : Minimum Data Set commonly used by public health authorities to conduct public health syndromic surveillance

# Data Element
Name Description of Field Usage Card inality Value Set Notes

Treatment Facility Identifiers

1 Facility
Identifier (Trea ting) Unique facility identifier of facility where the patient originally pr esented (original pr ovider of the data) R [1..1] National Pr ovider Identifier • Use facility identifier for state or local reporting only. This is due to agre ements w ith many health data provi ders that explicitly state that states or localities will not expose them to a third party like the federal gover nment when reporting above state level.

• This number should be specific for each facility location (not a number

repre senting an umbrella business)

It is recommended that National Pr ovider Identifier (NPI) be used for the Facility Identifier.

2 Facility Name
(Treating) Name of the treating facility where the p atient originally pr esented O [0..1] • If this data element is captured and maintained as part of the facility regi stration process, it may not be sent with every message. See section on Facility Registration.

• This data element captures data forFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4. Core EHR Data Requirements 4.4 Minimum Data Set

ISDS Meaningful Use 57 # Data Element Name Description of Field Usage Card inality Value Set Notes

the treating facility where the patient presented.

3 Street address of trea ting facility location O [0..1]

4 City of treating facility
location O [0..1] Free text

5 County of treating f aci l ity location O [0..1] Free text

6 Facility

Location
(Treating)

State of treating facility
location O [0..1] FIPS 5

- 2

Use numeric codes • If this data element is captured and maintained as part of the facility regi stration process, it may not be sent with every message. See section on Facility Registration.

• These data elements capture data for the treating facility where the patient presented.

7 Facility / Visit Type Type of facility or the visit where the patient presented for trea tment RE [0..1] TBD Examples of relevant values include:

• Emergency Department (ED)

• Urgent Care

• Primary Care

• Specialty Care

This data element captures data for the treating facility where the patient pr esented.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4. Core EHR Data Requirements 4.4 Minimum Data Set

ISDS Meaningful Use 58 # Data Element Name Description of Field Usage Card inality Value Set Notes

8 Report Date/Time Date and time of report transmission from original source (from treating facility) R [1..1] If data flows through an intermediary or third party, the intermediary must keep the original date/time of transmission.

Patient Demographics

9 Unique Patient Identifier Unique identifier for the patient R [1..*] HL7 Table 0203 • Examples of U nique Patient Identifiers

are Patient Account number or a Master Patient Index (MPI) number.

• This data element may be used as the

unique identifier used between the data sender and receiver to identify the r ecord.

• The cardinality allows multiple identif iers to accommodate situations where a data provider sends multiple identifiers, such as patient MPI number in addition to patient account number.

• In addition, if the message goes

through a data intermediary, such as an HIE, then multiple patient identifiers may exist. In such cases, it is important that all intermediaries retain and pr ovide all ass ociated patient identifiers for the patient.

10 Medical Record
# Patient medical record number O [0..1] HL7 Table 0203 • It is recommended that data providers submit the patient medical record nu mber to facilitate identification of the p a-Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4. Core EHR Data Requirements 4.4 Minimum Data Set

ISDS Meaningful Use 59 # Data Element Name Description of Field Usage Card inality Value Set Notes

tient, in the event of a required follow

up investigation. Without the medical record number, the work required to fo l low

- up on the records of interest greatly increases for the data provider and may cause unacceptable delays in public health response. In addition, the medical record number may aid in r ecord de

- duplication efforts and may o ften aid in the resolution of apparent transcription errors.

11 Age Numeric value of p atient age at time of visit R [1..1] LOINC Code
21612

- 7 • Note: Sending DOB is may not be an acceptable alternative to sending age due to possible restrictions in data privacy. Data providers and receivers should determine specific data r estrictions on age for their jurisdiction.

• The data requested is the patient’s age at time of visit. The age should not update over time as the patient
ages.

12 Age units Unit corresponding to numeric value of p atient age (e.g. Days, Month or Years) R [1..1] UCUM
Age Units Relevant Age Unit values:

• Days

• Weeks

• Months

• Years
Use the unit that is applicable to and d escribes the numerical age valueFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4. Core EHR Data Requirements 4.4 Minimum Data Set

ISDS Meaningful Use 60 # Data Element Name Description of Field Usage Card inality Value Set Notes

13 Gender Gender of patient RE [0..1] HL7 v2.5.1 A dministrative Sex (Table 0001)

14 City/Town City/Town of patient
residence O [0..1] Free text

15 Zip Code Zip Code of patient
residence RE [0..1] USPS • Provide a minimum of 5 digits for d omestic zip code.

• Foreign postal codes should be su pported.

16 State State of patient res idence RE [0..1] FIPS 5

- 2

Use numeric code

17 Country Country of patient
residence RE [0..1] ISO 3166

- 1
Country Value Set • Use 3 character codes

18 Race Race of patient RE [0..*] CDC Race Category Value Set • The patient may have more than one race defined.

19 Ethnicity Ethnicity of patient RE [0..*] CDC Ethnicity Group Value Set

Patient Health Indicators

20 Unique Visiting
ID Unique identifier for a patient visit R [1..1] HL7 Table 0203 • A visit is defined as a discrete or unique face

- to

- face clinical encou n-Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4. Core EHR Data Requirements 4.4 Minimum Data Set

ISDS Meaningful Use 61 # Data Element Name Description of Field Usage Card inality Value Set Notes

ter within a service department or l ocation. 9

• This data element may be used as the unique identifier used between
the dat a sender and receiver to ide ntify the record.

21 Visit Date /
Time Date/Time of patient presentation R [1..1]

22 Date of onset Date that patient b egan having symptoms of condition being r eported RE [0..1] LOINC Code
11368

- 8 (Illness / Injury Onset Date / time)

23 Patient Class Patient classification within facility RE [0..1] HL7 v.2.5.1 P atient Class (Table 0004 ) • It is recommended that PHA co nstrain the transmitted data using the patient class code set (exa mple: only transmit records where patient class = E, I, O). There is a potential for a large amount of data if not constrained.

• If the PHA does not choose to co nstrain these data with separators

, this field will be critical to process, constrain, and/or filter the data as

n eeded by the PHA

.

Relevant Patient Class values:

9 The definition of a unique visit in this final recommendation differs from BioSense. BioSense rol ls multiple visits within a 24

- hour period into one visit.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4. Core EHR Data Requirements 4.4 Minimum Data Set

ISDS Meaningful Use 62 # Data Element Name Description of Field Usage Card inality Value Set Notes

• E: Emergency

• I: Inpatient

• O: Outpatient

• P: Pre

- admit

• R: Recurring patient

• B: Obstetrics

24 Chief Co mplaint / Reason for visit Short description of the chief complaint or reason of patient’s visit, recorded when seeking care RE (see notes) [0..*] LOINC Code
21612

- 7:

Free text (Pr eferred)

Or

ICD

- 9 Clinical Modification dia gnosis code (i nclu d ing E

- codes and V

- codes)

Or

ICD

- 10 Clinical Modification dia gnosis code • This value is critical for PHSS and
is considered REQUIRED . Ho wever, there are settings or scenarios where this field may be blank (e.g. trauma patient). Therefore, the U sage value is ‘RE’.

• This field needs to be the richest and most complete free text d escription of the patient's chief co mplaint. If both the free text chief complaint text and drop down s election chief complaint text is avai lable, send only the free text chief complaint. If the chief complaint is only from drop down list fields, then

co ncatenate all drop down list chief complaints selected for that r ecord/visit and submit.

• For updates: Some hospital sy stems automatically overwrite chiefFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4. Core EHR Data Requirements 4.4 Minimum Data Set

ISDS Meaningful Use 63 # Data Element Name Description of Field Usage Card inality Value Set Notes

Or

SNOMED Di sorder/ Disease domain complaint with final diagnosis when the final diagnosis code is assigned. The chief complaint text sh ould NOT be replaced with other info rmation either manually or by the data provider’s system. It is imper ative that chief complaint text r emains how it was captured in the
ED

25 Triage Notes Triage notes for the patient visit O [0..1] LOINC Code
54094

- 8 ( Triage Note) :

Free text • Triage notes should be sent as free
text

• This field should NOT include patient identifiable information. This may r equire practitioner education and training for the proper / intended use of this field

• Triage notes may benefit from add itional processing (e.g. negation processing, natural language pro cessing, etc.) in order to maximize the utility of the data.

26 Diagnosis / E xternal Cause of Injury Code Diagnosis code or e xternal cause of injury code (for injury

- related visits) of patient cond ition RE [0..*] ICD

- 9 Clinical Modification dia gnosis code (inclu ding E

- codes and
V

- codes)

Or • Do not delay sending of patient d ata for diagnosis or verification proc edures . Patient data should be sent even if the diagnosis/injury code is
not available.

• Any new data can be sent as an u pdate to correct errors or to transmit data that was previously unavailable.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4. Core EHR Data Requirements 4.4 Minimum Data Set

ISDS Meaningful Use 64 # Data Element Name Description of Field Usage Card inality Value Set Notes

ICD

- 10 Clinical Modification dia gnosis code

Or

SNOMED Diso rder/ Disease d omain • Include V

- codes and E

- codes

• This field is a repeatable field so mu ltiple codes may be sent.

• The first diagnosis code should be the principal diagnosis.

• When the first

- listed diagnosis code (principal diagnosis) is an injury, also provide one or more supplemental external

- cause

- of

- injury codes or E

codes. E

- cod es provide useful i nformation on the mechanism and i ntent of injury, place of occurrence, and activity at the time of injury.

27 Clinical Impre ssion Clinical impression (free text) of the dia gnosis O [0..1] LOINC Code
44833

- 2 • This field is typically a free text field and is distinct from the diagnosis
code.

28 Diagnosis Type Qualifier for Diagnosis / Injury Code specifying type of diagnosis RE [0..*] HL7 v2.5.1 Dia gnosis Type (Table 0052)

29 Discharge Di sposition Patient's anticipated location or status fo llowing ED /UC visit RE [0..1] National Uniform Billing Committee (NUBC)

– Patient Status

UB04 codes • This field will update with multiple submissions.

• Include both the code and text d escription of the code.

• Discharge disposition should not be updated once the patient becomes an inpatient.

30 Disposition Date and time of di s- RE [0..1] Transmit this field as empty if the patient has not been discharged. Do not wait toFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance 4. Core EHR Data Requirements 4.4 Minimum Data Set

ISDS Meaningful Use 65 # Data Element Name Description of Field Usage Card inality Value Set Notes

Date / Time position transmit data elements until patient is discharged.

31 Initial Temper ature Patient’s first recorded body temperature, i ncluding units RE [0..1] LOINC Code
11289

- 6 (BODY TEMPERATURE)

UCUM for Coded
Numeric Units • Temperature may provide value in classifying certain conditions, such as pandemic flu.

• Units of the temperature should also be included.

32 Initial Pulse Oximetry Patient’s first recorded pulse oximetry value RE [0..1] For Generic Pulse Oximetry:

Use LOINC Code
59408

- 5

UCUM for Coded
Numeric Units
Units = % percentFinal Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance Appendix A: Extended and Future Data Elements for Further Consideration

ISDS Meaningful Use 66 

## Appendix A: Extended and Future Data E lements for Further Consideration

The following table contains a list of extended data elements and data elements for future consideration.

The extended data elements are fields that are recognized as currently in use by some jurisdictions, but not widespread enough to be included as part of the core minimum data set. These data elements are considered an optional extension of the core minimum
data set fo r jurisdictions that wish to include them for implementation.

The future data set contains data elements that will be considered for inclusion into the core minimum data set for future iterations. These future data elements may or may not be currently used by jurisdictions.

Table 14 : Extended data elements and data elements for future consideration to support public health syndromic surveillance

# Data Element
Name Description of Field Notes

Extended Data Set (Usage: Optional)

33 Pregnancy Status Pregnancy status of the patient • Pregnancy status helps determine the risk factor for certain di seases or conditions, such as H1N1 influenza, Arboviral, Brucellosis, gastroenteritis, Acute Hepatitis B, Acute Hepatitis C, Hepatitis D & E, L isteriosis, Lyme disease, Malaria, Q Fever, Relapsing Fever, R ubella, West Nile Virus, Yellow Fever

34 Initial ED Acuity Assessment Assessment of the s everity of the patient’s
condition • This data element helps determine the severity of the patient’s co ndition.

• The triage nurse assesses the severity of the patient’s condition and how many resources are required. An example of the assessment may be to use a scale of 1 to 5 to indicate a range of severity.

35 Laboratory O rder data set Data elements related to the ordering of lab oratory tests for the p atient • The individual data elements related to laboratory orders have not yet been determined. If used, the specific data elements should be specified and agreed upon by individual jurisdictions and their
data sharing partners.

• Laboratory order data elements help identify possible health co nditions of interest to public health.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance Appendix A: Extended and Future Data Elements for Further Consideration

ISDS Meaningful Use 67 # Data Element Name Description of Field Notes

• Due to the possible high volume of data, jurisdictions may wish to
limit the type of laboratory order data that is transmitted.

36 Laboratory R esults data set Data elements related to the results of labor atory tests conducted on the patient • The individual data elements related to laboratory results have not been determined. If used, the specific data elements should be specified and agreed upon by individual jurisdictions and their data sharing partners.

• Laboratory results data elements help determine the proportion of positive results (denominator data) and the amount of testing b eing conducted at a given time. It may help in the abi lity to differe ntiate when a signal is due to procedural change or an outbrea k.

• Due to the possible high volume of data, jurisdictions may wish to limit the type of laboratory results data that is transmitted.

Data Elements for Future Consideration

37 Patient Street
Address Patient ’s street a ddress of residence

38 Patient Date of Birth (DOB) Patient ’s date of birth

39 Insurance Co verage Patient’s type of insu rance coverage This data element is to capture a high

- level description of insurance, such as Medicare, Medicaid, Private Insurance, and Self

- pay.

40 Diagnosis Date/Time Date/Time associated with the Diagnosis / Inju ry Code

41 Vital Sign

related data elements Data elements that are related to the patient’s vital sign measur ements Vital sign elements for consideration are heart rate, respiratory rate , blood

pressure (SBP/DBP) , BMI, pulse rate, height, and weight

.Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance Appendix A: Extended and Future Data Elements for Further Consideration

ISDS Meaningful Use 68 # Data Element Name Description of Field Notes

42 Observation, symptoms, and clinical findings Data element(s) d escribing the observ ation, symptoms, and clinical findings for a patient’s condition • This data element(s) has the potential to large since it may be a full nurse / physician dictation.

• This may be a group of data elements rather than a single data el ement.

43 S everity of il lness related data elements Data elements that are used to assess the s everity of the patient’s illness Data elements for consideration include ventilated indicators, intubated i ndicators, and desaturation.

44 Highest Te mperature Highest recorded te mperature, including units • Highest temperature may provide a more accurate value in classifying certain conditions, such as pandemic flu.

• Units of the temperature should also be included.

45 Procedure Code Procedure code to identify the health i ntervention provided to the patient • Procedure code is useful in distinguishing whether the patient received a vaccination for a disease or treatment for the actual disease.

• This is applicable to primary care settings.Final Recommendation: Core Processes and EHR Requirement s for Public Health Syndromic Surveillance Bibliography

ISDS Meaningful Use 69 

## Biblio graphy

1. U.S. Department of Health and Human Services, Centers for Medicare & Medicaid,
Electronic Health Record Incentive Program: 42 CFR Parts 412, 413, 422, and 495 CMS

- 0033

- P, RIN 0938

- AP78
2. U.S. Department of Health and Human Services, Office of the National Coordinator for Health Information Technology, Health Information Technology : Initial Set of Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, Final Rule: 45 CFR Part 170, RIN 0991

- AB58
3. National Health Information Network (NHIN), Population Workgroup , NHIN Trial Impl ementation, Biosurvei llance Use Case Requirements Document, version 1.0, April 29,
2008
4. Health Information Technology Standards Panel (HITSP) Membership, HITSP Encounter Message Component, HITSP/C39, Released for Implementation 20090708 V2.3
5. Buehler et al. Syndromic surveillance practice in the United States: Findings from a su rvey of state, territorial, and selected local health departments. Advances in Disease Surveillance (2008) vol. 6 (3) pp. 1

– 20
6. Gibson, Theodore, and Buchanan. Placing Surveillance in a Preparedn ess Business Process Framework: The Common Ground Preparedness Framework . ISDS 9 th Annual Conference (2010).
7. Public Health Informatics Institute. (2006). Taking Care of Business: A collaboration to define local health department business processes. Decatur , GA: Public Health Info rmatics Institute

8. Thacker, S., “HIPAA Privacy Rule and Public Health, Guidance from CDC and the U.S. Department of Health and Human Services”, MMWR, April 11, 2003 / 52;1

- 12