Skip directly to search Skip directly to A to Z list Skip directly to navigation Skip directly to page options Skip directly to site content

NSSP Updates


Welcome to NSSP Update


NSSP Update is published monthly by the National Syndromic Surveillance Program (NSSP) and brings you the latest news about the BioSense Platform. To learn more, visit the NSSP website. Link to more resources via the Syndromic Surveillance Community of Practice Portal.

NSSP Progress Toward Transitioning Legacy Data

The end of a lengthy process is in sight after moving data from the final few legacy sites to the BioSense Platform. By the end of January, the NSSP Team had converted 93% of site data into the production environment.

Legacy Data in Production

Of the 43 total legacy sites, 19 have data available in production ESSENCE, and an additional 20 are ready to load data into ESSENCE. Of the remaining sites, one is under final data quality review in production, and three are under site review in the staging environment.

We appreciate your patience throughout this transition. If you have questions, please contact the NSSP Service Desk.

Technology Update

Technology Update

In January, the BioSense IT development team worked on improvements to the Access & Management Center (AMC). These development efforts included security fixes and near-term improvements to user interface speed. Also, the team continues to work on the much anticipated AMC Master Facility Tool, which will deployed in phases beginning spring 2018.

Preparations are also underway for an upcoming SAS pilot. We look forward to having members of the community validate new documentation and explore how well SAS performs on the BioSense Platform under different scenarios.

Issues with Processing Temperature Measure and Units

We are troubleshooting data issues associated with “Initial temperature of the patient”:

  1. Adherence to Standards: Incoming data for “units” part of temperature do not consistently reflect the unit standards published in the Public Health Information Network Vocabulary Access and Distribution System (PHIN/VADS). The PHIN standard follows: The PHIN Standard
  2. NSSP Processing Issue: When data are ingested into ESSENCE, processing truncates the received temperature unit to only the first character.
  3. ESSENCE Processing Issue: ESSENCE normalizes temperature values based on unit values of “F” or “C” only, which does not align with all the current standards for units.We are modifying the process so that full units are ingested into ESSENCE (units are pulled from OBX-6.2). Once the NSSP units processing updates are made, NSSP will work with ESSENCE software developers from Johns Hopkins University Applied Physics Laboratory (JHU–APL) to expand the normalization algorithm to account for all units’ values.

Let’s dig a little deeper into these issues to understand what is currently going on:

Basic Processing

When NSSP receives a temperature through an OBX message, the numeric value sent in OBX-5 is stored in the Initial_Temp column in the NSSP Processed Table with 2 decimals, whereas the units sent in OBX-6.2 are stored in Initial_Temp_Units in the Processed table. The numeric value sent in OBX-5 is also stored “as is” in Str_Initial_Temp. So if, for example, the incoming temperature is 98.2, the Initial_Temp will contain 98.20 (2-digit decimal), and the Str_Initial_Temp will contain “98.2” (exactly what was sent in the message).

During ESSENCE ingestion, the value in the Processed Table Str_Initial_Temp column is concatenated with the first character of the Initial_Temp_Units by using a space separator, and the concatenated text is ingested into ESSENCE under a column also named Initial_Temp. Here’s an example:


Initial_Temp  (PROCESSED)

Initial _Temp_Units (PROCESSED)

Initial_Temp  (ESSENCE)

98.2 98.20
98.2 F

Normalization to Fahrenheit

Next, ESSENCE converts Initial_Temp to Initial_Temp_Calc. The goal is to store a normalized temperature based on a Fahrenheit (F) unit in Initial_Temp_Calc.

During this conversion, ESSENCE looks for a numeric temperature value followed by an “F” or “C” with a space separator in the Initial_Temp value. If an “F” is found—suggesting the temperature is based on Fahrenheit—no conversion is performed, and the value is stored “as is” in Initial_Temp_Calc. If a “C” is found, ESSENCE converts the number from Celsius to Fahrenheit and stores the converted value in Initial_Temp_Calc with 2 decimals. For example:

Initial_Temp (ESSENCE)


37.05852 C 98.71
99 F 99

Historically, ESSENCE has always searched for “F” or “C.” But a unit value of “F” or “C” does not include all values associated with the current PHIN standard for units. Currently, no unit other than “F” or “C” is converted or normalized. As a result, the Initial_Temp_Calc is NULL.

Even if NSSP processing did ingest the full units’ value in ESSENCE instead of only the first character, the current temperature processing rules in ESSENCE would not accommodate the PHIN standard or variations outside the original ESSENCE use of “F” or “C.” Therefore, although you may be sending data that comply with PHIN standards, you might see NULL values for Initial_Temp_Calc and only the first character of the unit in ESSENCE under Initial_Temp.

Here are some examples of how these current issues manifest in the data:

Processed Table Data


(as is)

(2 decimals)

(as is)

(NSSP truncation)

(ESSENCE normalization based on “F” or “C”)

98.3 98.30 degree Fahrenheit 98.3 d NULL
997.9 997.90 DEGREE FAHRENHEIT 997.9 D NULL
NULL NULL NULL 99:97.4:98.5 NULL
98.2 98.20 FAHRENHEIT 98.2 F 98.2
97.1 97.10 Degrees Fahrenheit NULL NULL
97.5 97.50 Degrees Fahrenheit 97.5 D NULL
998.2 998.20 NULL 998.2 NULL
36.8 36.80 degree Celsius 36.8 d NULL
36.8 36.80 Cel 36.8 C 98.24

Please keep in mind that we are working to adjust the NSSP ingestion process so that ESSENCE receives the full units value. And, in turn, this will enable ESSENCE updates to the normalization process so that all units are considered. The NSSP Team is working with developers from JHU–APL on how best to address these issues. Meanwhile, we hope this explanation helps you understand any oddities you might observe while reviewing your data in ESSENCE.

Top of Page


Figure 1

Figure 1. The Chief Complaint Processor (CCP) categorizes text.

Q: What is the purpose of the Chief Complaint Processor (CCP)?

A: The CCP categorizes chief complaint text into as many syndromes and subsyndromes as the text matches (figure 1).

To understand how the ESSENCE Chief Complaint Processor works, keep in mind that “chief complaint” is any type of text string or combination thereof:

  • One word: “fever”
  • Several words: “shortness of breath”
  • Verbose text: “patient was seen with a cough that had been persistent for 3 weeks along with additional head aches and chills”
  • Text with abbreviation: “sob”
  • Text with negation: “patient was not vomiting”
  • Text with misspellings: “patient was mot vomiting”
  • First person: “I am having chest pain”
  • Other languages: “estoy teniendo dolor en el pecho”

A syndrome is a group of associated symptoms:

  • Fever
  • GI
  • Respiratory

A subsyndrome is a smaller, specific group of associated symptoms:

  • Abdominal pain
  • Difficulty breathing
  • Diarrhea

The difficulty in categorizing text mounts when new medical terms or colloquial shorthand is used to describe something or when a negation is used that is not adjacent to the term it negates (figure 2). For example, a chief complaint might include “I had a fever last night, but since this morning no fever, nausea, or vomiting.” The follow-up question one must ask is whether this is still someone with a fever. The “no” response has to reference all three symptom terms that follow it. This difficulty is further compounded when exceptions are noted in the chief complaint (figure 3).

Figure 2

Figure 2. In this example, the Chief Complaint Processor (CCP) translates NVD into nausea, vomiting, and diarrhea.

Figure 3

Figure 3. Processing becomes more sophisticated when the Chief Complaint Processor (CCP) translates NVD and accounts for terms mentioned but not observed.

Q: What are the differences between NSSP core data (raw and processed) and ESSENCE data?

A: This is easiest to understand by following the flow of data and seeing the three points where data are processed: Processing 1 (RAW table), Processing 2 (Processed and Exceptions tables), and Processing 3 (ESSENCE tables).

Conceptual Diagram of Data Flow and Processing

Processing 1 RAW Table

Incoming messages are scrubbed before being stored in the RAW table along with other metadata (e.g., arrival date and time, feed name, batch file name, and message status). During the scrubbing process, specific HL7 segments that might have personally identifiable information, or PII, are obfuscated as a precautionary measure:

  • Alphabetic characters are replaced with “Xs”
  • Numbers are replaced with “9s”

Note. Obfuscation is applied to fields with a length >= 2.

A scrubbed message is stored “as is” in the message column in text format, allowing you to easily pull and review HL-7 messages used for processing data. An NSSP-assigned Message_ID is also stored to link the RAW record to other tables processed downstream (i.e., Processed table, Exceptions table, and data details in ESSENCE).

RAW data include all messages received. Multiple messages can be associated with the same patient visit—and again, the RAW data include all messages. These data can be useful in tracing the original HL-7 messages associated with visits of interest. For example, if data quality issues are identified in other downstream tables or in ESSENCE, you may trace the original HL7 message to assess if an issue is with incoming data versus an issue with internal processing. In addition, the RAW data are useful in assessing whether data are timely, the volume is as expected, and the message meets minimum eligibility criteria for further processing. Certain criteria must be met before a message is deemed valid and acceptable for further downstream processing. These are referred to as “filter checks.”

Minimum Criteria to Pass Filter Checks Applied in Raw Message Table:

  • Message date/time must be sent (MSH-7)
  • Message must be an ADT message (MSH-9.1=ADT)
  • Sending facility must be sent (MSH-4.2 or MSH-4.1)
☑    If all criteria “pass,” the message_status  in the RAW message table is set to “New,” and processing to the Archive Processed message table may begin. Once processing is complete, the status is set to “Read.”
☒      If one or more criteria “fail,” the message_status  is set to “Filtered,” and no further processing takes place.

Processing 2 Processed/Exceptions Tables

Next, on the basis of NSSP business rules, the messages stored in RAW with a message_status=‘New’ are parsed and processed into tables. Incoming messages are parsed, and data are extracted and stored in Processed table columns. Additional columns are calculated based on NSSP business rules. The names of the calculated columns are given a “C_” prefix. In addition, the business rules require referencing the Master Facility Table (MFT) and supporting Crosswalk table to ensure incoming data have Facility Identifiers that are registered in the MFT.

Additional criteria are applied to determine if the message’s data content meets minimum processing criteria. If data pass the minimum criteria, the processed data are triaged to the “successful” Processed table that, from this point forward, contain Processed data for ingestion into ESSENCE. If data fail to meet minimum criteria, the data are triaged to the “unsuccessful” Exceptions table, and an accompanying Except_Reason table is updated to record the reason(s). (Note: the Processed and Exceptions tables have the same file structure. One table reflects data triaged successfully, whereas the other table reflects data triaged as unsuccessful.)

Minimum Criteria for Ingestion to Processed Message Table:

  • Patient ID must exist and be > 2 characters
  • Visit Date must exist as valid date and be >= 8 characters
  • Facility ID must exist (must contain a value in EVN-7.2 or MSH-4.2)
  • Facility ID from message must appear as active facility on MFT (Note: As for Staging tests, when facility status is set to Onboarding, data will successfully process to the Staging Archive data.)

☑    If all criteria “pass,” the record is stored in the main Processed table.
☒    If one or more criteria “fail,” the record is triaged to the Exceptions table, and no further processing takes place.

Processing 3 ESSENCE Data

Next, more business rules are applied to ingest the Processed data into ESSENCE. Records associated with the same patient visit are “collapsed” into one physical record to prepare data for analysis and visualization. For each visit, ESSENCE populates a column with info present in the last message processed for that visit, with some exceptions: special rules are applied to Patient Class, Chief Complaint, Discharge Disposition, and Discharge Diagnosis.

  • Process uses “First non-NULL value” or “Last non-NULL value.”
  • Companion history fields store information across all messages, which constitutes a single visit.

From this point forward, we refer to these data as “ESSENCE data.”

To summarize, the BioSense Platform receives HL7 messages that are stored in the RAW table (processing #1). Messages are parsed, data are extracted, and business rules are applied so that data and supporting calculated fields can be stored in columns in the Processed table or triaged to Exceptions as needed (processing #2). Processed data are ingested into ESSENCE, and records associated with the same patient visit are “collapsed” into one record for use within the ESSENCE application (processing #3).

We thank NSSP’s Analytic Data Management (ADM) Team for this explanation. Members of the ADM Team are available to answer questions and discuss data quality reports. To schedule a one-on-one discussion, please contact the NSSP Service Desk.

Top of Page


Data—the foundation for making sound public health decisions—must be managed from collection through analysis and reporting. NSSP can work with sites to assess and improve data quality. Each month, NSSP provides site-specific reports on three essential and integrated measures of data quality: completeness, timeliness, and validity. Reports can be accessed in each site’s secure shared folder and are available toward the end of the month. The Data Quality Corner can help you use these reports to bolster and maintain the integrity of your site’s data quality.

Why are my records not being processed?
Why are my records not being processed?

Your data (also called records or messages) might NOT meet NSSP’s minimum criteria for processing.

Incoming data are always filtered. That’s because any data missing MSH-7, MSH-9.1=ADT, or MSH-4.2 or MSH-4.1 cannot be processed. Similarly, incomplete or invalid data—called exceptions—cannot be processed and are set aside.

When data are filtered or set aside as exceptions, you can use the Data Quality Completeness Report to investigate why these data are not being processed.

How to:

  1. Go to the Completeness Report.
  2. Look under the “XX_Exceptions” tab to see a list of data processed, sent to exceptions, or filtered.

Investigation Tip: The information is provided by feed and facility and is separated by Exceptions Reason.

I’m seeing odd values in some columns that are supposed to be standardized. Where is this coming from?

Ideally, as part of electronic data being exchanged, pertinent data should be standardized. Much of the NSSP data conform to CDC’s Public Health Information Network Vocabulary Access and Distribution System—or, PHIN VADS. And when data do not conform, that’s when data can look, well, odd.

How to:

Here’s what to do if data look odd:

  1. Go to the Validity Report. This report indicates whether data conform.
  2. Select a tab for the column you’re interested in.Each column’s tab shows data that conform or do not, overall, by feed and by facility. Column tabs include specific values associated with conforming and nonconforming categories. For example, you can filter on column F, “Value,” and select $All_NonConforming to identify feeds and facilities that send nonconforming values. You can even review the values being reported.

Investigation Tip: Each column tab links to the Summary tab. The Summary tab conveniently links to the associated PHIN VAD standard, providing a quick way for check the standard values. The Summary tab in current reports links to the Data Dictionary. The Data Dictionary includes a return link to the Summary tab.

We thank NSSP’s Analytic Data Management (ADM) Team for this explanation. Members of the ADM Team are available to answer questions and discuss data quality reports. To schedule a one-on-one discussion, please contact the NSSP Service Desk.

Top of Page


We continue our series of articles examining literature that advances the practice of syndromic surveillance. This month’s article adds to the knowledge about ED visits for falls attributed to inclement weather.

Risk of Fall-Related Injury due to Adverse Weather Events, Philadelphia, Pennsylvania, 2006–20111

Each winter, public health departments in cold regions of the country caution the public about winter hazards such as frostbite, black ice and snow-covered roads, and overexertion from shoveling snow. After a particularly harsh bout with two ice storms in 2011, the Philadelphia Department of Public Health (PDPH) received notification from its syndromic surveillance system (BioSense) of higher than usual fall-related visits to one of its local hospital emergency departments (EDs). Since PDPH does not routinely monitor injury-related visits, health officials chose to investigate further.

Rather than examine falls related to specific storms, the authors chose to study fall-related ED visits from December 2006 through March 2011 for one location, which would give them a better understanding of the relationship between weather and affected populations. The study examines risk by age and timing of falls—two useful pieces of information for public health messaging.

The authors’ initial research indicates that more could be done to target public health messages about the risk of falls during adverse weather. They state the long-term health consequences and economic toll on the healthcare system, citing Murray et al, who equate increased ED workload during adverse weather to a “major accident” or “moderate disaster.”2 The authors describe their source of injury data and study methods. In their results, they note that 15 days during winter months were identified as “high-fall days.” On these days, compared with “control” days, “18- to 64-year olds were twice as likely to receive ED care for fall-related injuries.”1 Since the ED visits occurred from 7:00 AM to 10:59 AM,1 these findings suggest that certain strategies aimed at commuters—such as delayed openings or work closures—could reduce falls. Another strategy the authors suggest is to communicate with hospital ED staff about the potential increase in visits during the morning commute.

Private industry might be hesitant to adopt these strategies. Then again, private industry may look at reputational risk, especially during emergency situations. To this end, public health departments need to be a technical source of information for media and a credible source of data to support public health recommendations and strategies.

1Gevitz K, Madera R, Newbern C, Lojo J, Johnson CC. Risk of Fall-Related Injury due to Adverse Weather Events, Philadelphia, Pennsylvania, 2006–2011. Public Health Reports [Internet]. 2017 July/August [cited 2017 Nov 6];132(1 Suppl). Available from:

2Murray IR, Howie CR, Biant LC. Severe Weather Warnings Predict Fracture Epidemics. Injury. 2011;42(7):687–90.

Top of Page


NSSP 2018 Annual Recipient Meeting - Maintaining and Advancing Syndromic Surveillance
Upcoming Events
February 7 Data Validation Support Call
February 20 NSSP Surveillance Community of Practice Call: 3:00–4:30 PM ET. The discussion will be “Winter weather + ILI = seasonal surveillance/winter surveillance activities.” Click here to register.
February 20 Scheduled vendor patches in staging environment: 6:00–10:00 AM ET
February 22 Scheduled vendor patches in production environment: 6:00 AM–12:00 PM ET
February 27–March 1        NSSP 2018 Annual Recipient Meeting: Maintaining and Advancing Syndromic Surveillance (formerly the Grantee Meeting); Atlanta, Georgia
April 17–20, 2018 Preparedness Summit; Atlanta, Georgia

Note: To access the Surveillance Community of Practice group resources, you must be signed in to your account. To create an account, click here.

Top of Page


Last Month’s Technical Assistance Updates
January 3     Data Validation Support Call: 3:00–4:00 PM ET
January 17     Scheduled vendor patches in staging environment
January 19                                 Scheduled vendor patches in production environment

Top of Page


The NSSP is refining its definition of participation. Since 2016, the community and NSSP Team have worked to improve what’s at the core of the BioSense Platform—its data quality and data flow. As a result, the NSSP has a much improved data flow that accounts for variations in feeds and attempts to ensure data are as complete as possible. Also, thanks largely to the community, the Master Facility Table (MFT) is robust and accurately reflects the facility type(s) used for identifying emergency facilities, registered facilities that send syndromic surveillance data to the BioSense Platform, and facilities with which NSSP has established relationships.

Taken together, the NSSP can now account for facilities, data feeds, and state participation in ways that were difficult to imagine two years ago. NSSP is using this information to explore alternate approaches for estimating data representativeness and to establish new baselines for measuring and reporting program participation.

Until these new baselines for participation are established, current estimates show that NSSP receives data from more than 4,000 facilities. Of these, about 2,567 are emergency departments (EDs) that actively submit data, which means that about 60% of all ED visits in the country are being represented (based on American Hospital Association data). At least 55 sites in 45 states, including the District of Columbia, participate in NSSP. Although NSSP is pleased with participation to date, sites with data in production do not always translate into sites with broad ED coverage.

Map of United States with inserts depicting Alaska and Hawaii. Map is color coded. Dark blue indicates sites with data in production: Alaska, Washington State, Oregon, Idaho, Montana, North Dakota, Minnesota, Wisconsin, Michigan, Nevada, Utah, Arizona, New Mexico, select counties in Texas that are unidentified by name, Nebraska, Kansas, Missouri, Illinois, Arkansas, Louisiana, Mississippi, Alabama, Georgia, Florida, Tennessee, Kentucky, West Virginia, Virginia, North Carolina, Maryland, Pennsylvania, New York State, New Jersey, Vermont, New Hampshire, Massachusetts, Maine, and a few counties in California, Colorado, and Iowa that are unidentified by name. Light blue indicates sites that are onboarding: South Carolina and select counties in California and in Indiana that are unidentified by name. Pink indicates sites that might onboard but no tentative plans have been made: Indiana, Ohio, Connecticut, Rhode Island, and select counties in California and in Texas that are unidentified by name. Light green indicates planning is unknown: Delaware, California, Wyoming, South Dakota, Colorado, Iowa, Oklahoma, and Texas. White indicates “not planned,” and shows Hawaii.

Definitions: NSSP consolidates facilities that provide data under a single data administrative authority called a site administrator. These facilities and single-site administrator constitute a site.

Top of Page


Data Validation Support

Conference calls are held the first Wednesday of each month, 3:00–4:00 PM ET, to assist with data validation compliance. For more information, contact the NSSP Service Desk.

Top of Page


Get Ready to Collaborate!

NSSP’s 2018 Annual Recipient Meeting—Maintaining and Advancing Syndromic Surveillance—will be held in Atlanta, Georgia, on February 27–March 1, 2018. Through presentations, roundtable discussions, and hands-on training, participants will learn how to improve the nation’s situational awareness and respond to hazardous events and disease outbreaks. In addition, Rear Admiral Michael F. Iademarco, MD, director of the Center for Surveillance, Epidemiology, and Laboratory Services (CSELS), will meet with funding recipients to answer questions.

Registration and hotel information have been emailed to funding recipients and the agenda posted. If you did not receive this information, please contact your project officer. We look forward to another successful annual meeting!

*State and local public health authorities receive funding through CDC-RFA-OE15-1502: Enhancing Syndromic Surveillance Capacity and Practice.

Texas Uses Syndromic Surveillance to Show Rise in ED Visits after 2014 Case of Ebola

Success Story - Texas

In 2014, after the first case of Ebola Virus Disease was confirmed in Dallas–Fort Worth (DFW), Texas, public concerns led to unprecedented media attention and exacerbated fears of a widespread outbreak. Emergency department (ED) visits in metropolitan DFW increased significantly—both within and outside the symptom profile for Ebola Virus Disease.

Texas used its North Texas Syndromic Surveillance System and ESSENCE analytics to study how ED visits changed among metropolitan DFW residents after the case was reported. Ultimately, health officials determined most increases in ED visits were not due to EVD symptoms because the people seeking care had no fever, had not reported travel, and had not been exposed to the man confirmed to have EVD.

Still, the findings described in this success story give one pause. Were ED visits increased by the “worried well”? The study shows how SyS data improve situational awareness by characterizing populations seeking healthcare services and by identifying geographic areas with an uptick in use of healthcare services.

Washington State is Positioned Well to Report Syndromic Surveillance Data

Before the state mandated that emergency departments (EDs) report syndromic surveillance results, the Washington State Department of Health (DoH) had already registered all EDs and established a reporting protocol. Having such broad support from healthcare facility partners strengthened the legislators’ position on the bill and helped them balance the public health value of collecting syndromic surveillance data against the hospital costs for submitting data.

Nearly all Washington State EDs are part of larger clinical networks that, without the mandate, could opt out if their electronic health record vendors were to change. To lose even one of these larger networks would devastate the representativeness of the state’s data. The mandate for EDs to report syndromic data eliminates this concern.

Further, although the mandate has not changed Washington State DoH’s process for registering facilities to begin reporting, the mandate protects the integrity of the state’s syndromic surveillance data and reassures data users that the Rapid Health Information NetwOrk (RHINO), which provides syndromic surveillance data, will continue to be of high quality and readily available to them for years to come.

New York Uses SyS to Show ED Visits More than Doubled on New Year’s Day

A December 2017 City of New York press release1 reminded the public about dangers associated with alcohol misuse:

  • Emergency department visits related to alcohol are highest on New Year’s Day 
  • Overall, from 2011 to 2015, there was a 35 percent increase in visits to the emergency department due to alcohol-related injuries

Supportive data were provided by the health department’s syndromic surveillance (SyS) system. In fact, SyS data showed that visits to the emergency department more than doubled on New Year’s Day—particularly between 1:00 and 4:00 AM. The press release goes on to state “alcohol misuse costs nearly $6 billion in citywide economic productivity losses each year in New York City.”

Here’s how ED visits compared across several celebrated events:

Emergency Department Visits

We applaud New York City for accessing SyS data to inform the public about alcohol misuse. Read the press release for a comprehensive approach to making resources available to educate the public, health professionals, and community-based coalitions.

1Press Office of New York City Department of Health and Mental Hygiene. #099-17 Health Department Reminds New Yorkers to Stay Safe on New Year’s Eve; Releases Latest Data on Injuries Involving Alcohol [press release]. New York City; 2017 Dec 29.


Please share your successes for improving data representativeness; data quality, timeliness, and utility; SyS practice; and the use of SyS data for public health action and response. Simply fill out the NSSP Success Stories Template and email to us.

Top of Page


Definition Library

Help Build the Syndrome Definition Library

The Syndromic Surveillance Community of Practice is beta testing its Syndrome Definition Library. Look for syndromes by keyword. Filter search results by platform or author name.

To name a few topics, the library includes Heat-related Illness, Homeless Population, Zika, West Nile and Saint Louis Encephalitis, Chikungunya and Dengue, (various) Mass Gatherings, Opioid Diagnosis Codes, Fireworks Injuries, Agriculture-related Injuries, Hazardous Materials, and Rabies Exposure.

Trending Topics

Do you have a question for the community but don’t know the best place to ask? Join the community discussions on the Forums. Community members are sharing ideas about topics ranging from data quality improvements to ways to connect MPH students with public health opportunities internationally. Come join our conversations!

Workgroup and Committee Updates

  • Data Quality Committee (DQC)—The DQC met with representatives from CDC and electronic health record (EHR) vendor Cerner to discuss strategies for addressing data quality issues. Thank you to our partners for joining the call. The DQC provides a forum in which successes are celebrated. Plus the DQC enables the community to connect with representatives from public health jurisdictions, EHR vendors, and other concerned stakeholders to understand and work through onboarding and production maintenance data quality challenges. Joining the DQC is a great way to keep up with the latest community data quality concerns. For information from the January call or to participate in upcoming DQC activities, please visit our group on the International Society for Disease Surveillance (ISDS) website or contact Sophia Crossen (
  • Metadata Visualization Application (MVA) Workgroup—The MVA workgroup has been contacting current participants to initiate an effort to standardize EHR vendor names and products. If standardized information were integrated into the application, users could view data quality metrics by vendor names and products, which can be important determinants in data quality.
  • Urgent Care (UC) Workgroup—The UC Workgroup is finalizing its presentation of the UC Justification and support documents (e.g., How to Create a Jurisdictional UC Facility Listing, Best Practices for Onboarding UC Facilities).

Interested in joining a chapter, committee, or workgroup? You can find a list of the groups here.

Messaging Guide

The Messaging Guide Workgroup thanks everyone who submitted comments on the Implementation Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient, and Ambulatory Care Settings, Release 2.3. More than 200 comments were received across the June–July and November comment periods. The workgroup is now partnering with community members and vendors to address the comments and update the guide in preparation for HL7 Balloting in 2018. According to HL7 requirements, the name of the guide has been updated to the HL7 2.5.1 Implementation Guide for Syndromic Surveillance.

If you are interested in joining, please visit the Messaging Guide Workgroup page to access the working documents and call-in information.

Development of HL7 2.5.1 Implementation Guide for Syndromic Surveillance*

Time Frame Activity
2015 Version 2.0 Released
2016 Erratum and Clarification Document Released for Version 2.0
2017 Summer Version 2.2 Released for Community Comment and Consensus
2017 Winter Version 2.3 to be Released for Review and Community Comment
2017 March Version 2.4 Finalized for HL7 Balloting
2018 May HL7 Balloting Begins
2018 Fall HL7 Balloting (anticipated) Completed and HL7 2.5.1 Implementation Guide for Syndromic Surveillance Released

*This document was retitled in January 2018.

NSSP Community of Practice Call

Please join the monthly NSSP Community of Practice (CoP) Call (previously titled the Surveillance CoP Call). This call engages stakeholders and sparks collaborative efforts to share guidance, resources, and technical assistance.

The next call will be held on February 20, 2018, 3:00–4:30 PM ET and will be on Winter weather+ ILI=seasonal surveillance/winter surveillance activities. Click here to register.

Top of Page