NSSP Update – March 2019
- Featured Webinar Series: Are you considering taking on a leadership role in one of our NSSP–CoP Community Groups? Check out this two-part webinar series of NSSP–CoP experts as they discuss their personal evolution in leading community groups and offer practical advice on how to facilitate groups and meetings.
Part 1: Leading Community Groups tackles the question “What does it mean to be a leader of a community group?” Hear from current leaders on how they transitioned from being active participants on group calls to representing their fellow community members. In this webinar, the panelists discuss what it means to be a “Chair” and the leadership prerequisites. They also discuss how members can build from their experiences and gain confidence to serve as leaders. Here’s some insight from our panelists:
“We are in this to improve public health and it doesn’t happen unless people step up to make what’s important happen. Don’t think of yourself as stepping up to decide what goes on. Think of yourself as stepping up to link people together to facilitate making things happen.”—Joe Gibson, Marion County Public Health Department, 2019 ISDS Board PresidentLEADERSHIP SERIES
“Take a chance to try something new. You may be surprised at what you gain from this experience. This could be the experience of your career!”—Krystal Collier, Arizona Department of Health Services, NSSP CoP Steering Committee Chair
“This webinar provided the context and history of how leaders within the community came to lead various ISDS workgroups and committees. It was very insightful to understand professional development within the broader syndromic surveillance community of practice.”—Samuel Prahlow, Florida Department of Health
“It can be very rewarding, and you can do so much more when you are connected to people who have complementary skills and connections.”—Howard Burkom, Johns Hopkins University Applied Physics Laboratory, ISDS Research Committee Chair
NSSP Community of Practice Call
Please join the monthly NSSP CoP call. This call is powered by community members who share guidance, resources, and technical assistance. The call includes a forum for discussion and questions. The next call is on March 19, 2018, 3:00–4:30 PM ET. We will discuss spring health hazards and update listeners on the status of the HL7 2.5.1 Implementation Guide for Syndromic Surveillance. Click here to register for the entire call series.
Workgroup and Committee Updates
- Data Quality Committee (DQC): The DQC is excited to announce that MisChele Vickers is taking on the role of DQC Co-Chair alongside Elyse Kadokura. MisChele is the Syndromic Surveillance Public Health Research Analyst for the Alabama Syndromic Surveillance Program. She brings more than 12 years of experience in research, analysis, and interpretation of health-related data and general data analytics.Also, the DQC wants to share its 2019 goals for the DQC leadership team:
- Aim for more guest speakers and member participation.
- Create resources for members: expert contact list, best practices resource, knowledge library, and lines of communication with vendors of electronic health records.
- Vary call topics: applied science, technical topics, data quality best practices and monitoring, changes and updates to Promoting Interoperability Program (formerly, Meaningful Use).
Syndrome Definition Committee (SDC): The SDC is excited to announce the release of Developing, Evaluating, and Disseminating Definitions for Syndromic Surveillance in Public Health Practice: A Guidance Document, now available on the ISDS Surveillance Knowledge Repository.SDC members recently voted on the next syndrome definition to develop as a committee. Highest rated topics include: firearm injury, injection drug use, mental health, pregnancy, and homelessness. If your public health jurisdiction has developed a syndrome on any of these topics, please submit it to the Syndrome Definition Library here.
Note: To submit a syndrome, you must have an account on the Surveillance Knowledge Repository. Register for a FREE account here.
- Technical Committee (TC): NSSP will be moving forward with the changes discussed at the January meeting. These include modifying ESSENCE business process rules to replace uninformative Chief Complaint terms if they are the first non-null Chief Complaint and a meaningful Chief Complaint is later received. We continue to seek input on the terms that would be considered uninformative. Please post your suggestions to the forum. Also, additional fields (C_Death, Facility_Type_Code, Facility_Type_Description, PIN, and Visit_ID) will be available for querying in the ESSENCE query portal. Please visit the forums and listen to the meeting recording from January for details about these changes. We anticipate that the next version of the BioSense Platform Enhancements document will be posted in March. The next Technical Committee Quarterly meeting will be held on April 4, 2019, at 2:00 PM ET. We are currently in the process of forming the agenda for this meeting, so if you have issues you would like to discuss, please let us know via the forums.
- Message Guide Workgroup (MGWG): The MGWG is looking for community members, including vendors, to assist with final recommendations to the proposed HL7 2.5.1 Implementation Guide for Syndromic Surveillance (see schedule below). The group holds weekly calls (Tuesday, 2:00 PM ET). To participate, please join the group on healthsurveillance.org or email Dave Trepanier at email@example.com to be added to the listserv and calendar series.
Implementation Guide for Syndromic Surveillance
|HL7 2.5.1 Implementation Guide Milestones*|
|2015||Completed Version 2.0 Final RELEASE**|
|2016||Released Erratum and Clarification Documents for Version 2.0|
|2017 Summer||Released Version 2.2 Working Draft for Community Comment and Consensus|
|2017 Winter||Released Version 2.3 for Review and Community Comment|
|2018 March||Released Version .09|
|2018 Spring||Submitted DRAFT HL7 Guide for Balloting: Implementation Guide for Syndromic Surveillance Release 1.0 Standard for Trial Use (STU) HL7 Version 2.5.1|
|2019 March||Submit Request to Publish Implementation Guide as a “Standard for Trial Use”|
|2019 Spring (April–June)||90-day Publication of Implementation Guide to HL7 Members|
|2019 July||Release to Public: HL7 2.5.1 Implementation Guide for Syndromic Surveillance for Trial Use Version 1|
* Milestones last updated January 30, 2019.
** Version 2.0 is currently being used; subsequent versions are working drafts only.
Shaded activities have been completed.
Funding Opportunities Supporting Syndromic Surveillance
We want to make you aware of two funding opportunities that support syndromic surveillance:
- The National Center for Injury Prevention and Control (NCIPC) has released the Overdose Data to Action (CDC-RFA-CE19-1904D), due May 2, 2019. This request for application builds upon the Enhanced State Opioid Overdose Surveillance (ESOOS) program. Contact your ESOOS coordinator for more information.
- The Epidemiology and Laboratory Capacity (ELC) competitive funding announcement was released February 28, 2019. Activities previously funded under NSSP will now be included under project C, Health Information Systems (HIS) capacity. Contact the ELC HIS lead for additional information.
Conference Call Describes Integration of NSSP Activities with HIS
On February 13, 2019, a conference call was held for recipients of NSSP funding to explain how activities will be integrated into the Health Information Systems (HIS) capacity component of CDC’s Epidemiology and Laboratory Capacity (ELC) for Infectious Diseases cooperative agreement.
Query Terms from January 2019
A key feature of NSSP–ESSENCE is its ability to use free-text definitions across different fields to generate custom queries. The SyS community can use this feature to develop and refine category definitions and to identify and respond to public health events that may not be apparent in established categorical definitions (i.e., syndromes, subsyndromes, and Chief Complaint and Discharge Diagnosis [CCDD] categories).
This word cloud summarizes free-text and coded values that epidemiologists and data analysts queried in ESSENCE during January 2019. Only NSSP super administrators can query ESSENCE usage logs to learn what queries are run nationwide and how long they take to complete. This word cloud was generated using the Wordcloud2 package in RStudio. The relative size of the terms suggest the frequency of use in a query.
Do you enjoy seeing national-level data depicted in a word cloud? Let us know!
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.
You Don’t Seem to be My Type!
Common Issues with Chief Complaint Code and Text Placement
Chief Complaint is a bread-and-butter data element for syndromic surveillance. Given the variation in how Chief Complaint has been reported in feeds over the years, the NSSP developed processing rules to search for Chief Complaint data by selecting the first non-null value found in specific segments:
- OBX*-reported Chief Complaint text (chief_complaint_text)
- PV2-3 reported Admit Reason description (admit_reason_description)
OBX-reported Chief Complaint Text
The first non-null value found is stored as the “calculated” Chief Complaint in the NSSP core processed data column named C_Chief_Complaint. This calculated Chief Complaint is used by ESSENCE (chiefcomplaintorig, chiefcomplaintparsed, and CCDD). More complete Chief Complaint (C_Chief_Complaint) data = enhanced capacity for ESSENCE surveillance.
Hierarchical rules aside—sometimes the calculated Chief Complaint is missing even though Chief Complaint data exists somewhere in the HL7 feed.
Let’s say, for example, you’re reviewing an NSSP Data Quality Completeness Report that indicates zero percent completion for the calculated Chief Complaint (C_Chief_Complaint)—BUT, you’re certain that Chief Complaint is being reported through an OBX and that Admit Reason is being reported through PV2-3. So, what’s going on?
Per the current Syndromic Surveillance Message Guide, the Chief Complaint reported in an OBX segment should be formatted text, stored in OBX-5, and sent with the OBX-2 data type set to “TX.” Consider the following (fictional) segment of an HL7 message:
Upon detection of TX in OBX-2, NSSP’s processing rules pull Chief Complaint from OBX-5.1 to store in Chief_Complaint_Text as NSSP-processed data. The data type will be stored in Chief_Complaint_Type.
Let’s look at the same example BUT with an incompatible data type called Coded with Exceptions, or “CWE.” Here’s how NSSP processes the code and where Chief Complaint is stored:
Upon detection of CWE in OBX-2, NSSP’s processing rules assume the data in OBX-5.1 are code that should be stored in Chief_Complaint_Code. In this example, nothing would be stored in Chief_Complaint_Text. Unlike the preceding example, the Calculated Chief Complaint will not be sourced from Chief_Complaint_Text because the field is empty.
So, how can you correct the formatting?
Change the data type to TX:
Or . . .
Change the format of the OBX-5 to a CWE format:
Here’s the data rule that shows how NSSP processes Chief_Complaint_Text through OBX:
|Chief_Complaint_Text||OBX-5 segments where:
* OBX-3 Observation Identifier is 8661-1 and/or 11292-0
* OBX-2 = “TX” or “CWE”
Select all non-null values and concatenate:
IF OBX-2 = “TX,” then Chief_Complaint_Text = OBX-5.1
IF OBX-2 = “CWE,” then Chief_Complaint_Text = concatenate (OBX-5.9, OBX-5.2, OBX-5.5)
PV2-3 Reported Admit Reason Description
Per the current Syndromic Surveillance Message Guide, Admit Reason is reported in PV2-3 and should be structured as a Coded Element (CE data type). NSSP processing will parse the segment and attempt to pull and store both a code and description from this Coded Element. The processing rules follow:
|Admit_Reason_Description||Direct input from HL7 message:
Select first non-null value and concatenate if repeating.
|Admit_Reason_Code||Direct input from HL7 message:
Select first non-null value and concatenate if repeating.
Consider the following (fictional) segment of an HL7 message:
Notice the description is in PV2-3.2. The ^ separates PV2-3.1 (code) from PV2-3.2 (description). NSSP processing rules store the description sent in PV2-3.2 to Admit Reason_Description.
Let’s take this same example without the ^ that separates a code from a description. What happens in NSSP processing? Where does the Admit Reason description get stored?
Because there’s no leading ^, NSSP processing assumes data in PV2-3.1 are code and stores the description in Admit_Reason_Code. As shown in previous examples, the Calculated Chief Complaint will not be sourced from Admit_Reason_Description because the field is empty.
How to correct?
Prefix the description with a ^ so that the description is now in PV2-3.2:
Q: How do I create an API “request”?
A: An application programming interface, or API, is ideal for extracting data from ESSENCE for reports you create routinely (daily situational reports for hospitals, monthly operational reports for policy makers, and opioid overdose results to measure local progress). By using the API, you don’t have to go to the ESSENCE user interface each time to pull essential data.
The first step is to create an R script or R Markdown file and load the necessary packages. By default, some packages might be in your system library. But if not, you can install them by clicking on the packages tab in the bottom-right corner of RStudio, then clicking Install.
Here are the package names and configuration statement you’ll need to get started:
Next, define the ESSENCE API URL as an object in the RStudio session. Shown below is an example of R code for an ESSENCE API request. “Authenticate” refers to the credentials that your RStudio session will pass to ESSENCE so that it knows what data you are allowed to see. “Import Data” tells RStudio what data to get from that URL. And, lastly, you will need to add two to three lines of code that tell R how to format whatever data are pulled from ESSENCE (not shown). This example API URL is for data that create a time series graph in ESSENCE, but there are five other APIs that are available in ESSENCE, depending on your needs.
essenceAPI<- "https://essence.syndromicsurveillance.org/nssp_essence/api/timeSeries?endDate=12Jan2019&ccddCategory=ili %20ccdd%20v1&percentParam=noPercent&geographySystem=hospitaldhhsregion&adatasource=va_hospdreg& detector=nodetecteor&startDate=7Oct2018&timeResolution=weekly&medicalGroupingSystem= essencesyndromes&userId=455&aqtTarget=TimeSeries"
api_response<-GET(essenceAPI, authenticate(key_list("essence")[1,2],key_get("essence", key_list("essence")[1,2])))
This explanation was provided by CDC Health Scientist Aaron Kite-Powell from his presentation at the ISDS 2019 Annual Conference: How to Use RStudio with ESSENCE Application Programming Interfaces. Upcoming newsletters will include more info about APIs. Also see ESSENCE documentation on APIs (login required).
Measles Syndrome Definition Available in ESSENCE
Measles (Rubeola) is a highly contagious but vaccine-preventable viral disease. From January 1 through February 7, 2019, about 101 cases of measles were confirmed in 10 states.1
NSSP–ESSENCE now offers a syndromic surveillance query for identifying potential cases of measles from syndromic data that can complement ongoing efforts to track and analyze the disease. The new measles CCDD category v1 query accesses Chief Complaint (CC) and Discharge Diagnosis (DD) fields to pull visits related to measles. The query searches for the terms “measles” and “rubeola” and for ICD-10 and SNOMED diagnosis codes for measles. The query also contains negation terms that, for example, exclude visits for measles immunization. Analysts and epidemiologists can use this new query to understand trends and clustering of measles-related visits at national, regional, and state and local levels.
1CDC. Measles Cases and Outbreaks: Measles Cases in 2019 [Internet]; Atlanta (GA): CDC; 2019 Feb 18 [cited 2019 Feb 7]. Available from: https://www.cdc.gov/measles/cases-outbreaks.html
New Measles Syndrome Definition Can Improve Early Detection
Measles is highly contagious, especially for babies and young children. If one person has it, 90% of the people close to that person who are not immune will also become infected.
Measles outbreaks can quickly grow in size and are highly taxing on state health resources. Syndromic surveillance queries for measles will give insight into measles outbreaks. By expanding syndromic surveillance practice for measles, we can improve early detection and increase situational awareness during outbreaks.Visit CDC's website Transmission of Measles and Measles and the Vaccine (Shot) to Prevent It.
Pertussis (also known as whooping cough) is a highly contagious respiratory disease caused by the bacterium Bordetella pertussis. Babies are at greatest risk for getting pertussis and then having serious complications from it, including death.1
A pertussis syndrome definition is now available in NSSP–ESSENCE for use by analysts, epidemiologists, and other public health practitioners. Being mindful of those who work in maternal and child health, the NSSP team made sure the syndrome would pull from Chief Complaint and Discharge Diagnosis fields to bin pertussis-related visits, including patients tested for pertussis. The syndrome excludes vaccine-related visits, terms, and codes (prophylaxis, immunization, vaccine, etc.).
1CDC. Pertussis (Whooping Cough): Pertussis Frequently Asked Questions [Internet]. Atlanta (GA): CDC; 2017 Aug 7 [cited 2019 Feb 25]. Available from: https://www.cdc.gov/pertussis/index.html
CDC Resources for Public Health Professionals
Case definition, reporting trends, surveillance reports, and more
Experts Collaborate to Develop Syndrome Definition for Cold-related Illness
In 2017, the Council of State and Territorial Epidemiologists (CSTE) Climate, Health, and Equity Subcommittee convened a workgroup to develop a standardized syndromic surveillance query for cold-related illness (CRI) and draft guidance that public health professionals can use to implement CRI syndromic surveillance.
Workgroup members compiled known CRI syndromes from health departments around the country and consulted International Classification of Diseases, Ninth Revision, Clinical Modification diagnostic codes available through CDC’s Environmental Public Health Tracking (EPHT) program. They designed inclusion and exclusion criteria based on the submitted syndromes and EPHT guidance. Then they applied the definition to local data to validate the query. The workgroup collaborated with staff from CDC’s National Syndromic Surveillance Program (NSSP) to code the final query and add it to NSSP–ESSENCE.
An overview is provided on the NSSP Success Stories Web page. Look for the CRI syndrome definition in NSSP–ESSENCE, to be followed by the guidance document that details how the query was created and validated and should be implemented. As with all syndrome queries, please tailor the query to your unique circumstances.
Spotlight on Syndromic Surveillance Practice
Suicide is the 10th leading cause of death in the United States.1 This large and growing public health problem affects all ages but disproportionately affects some populations. In the article summarized below, the authors examine the usefulness of syndromic surveillance Chief Complaint data to detect suicide-related emergency department (ED) visits among young adults and whether discharge diagnoses data add value. The article was part of a special supplement on syndromic surveillance published by Public Health Reports in 2017. Since then, the NSSP team has formed new collaborations with other CDC programs, and these collaborations provide more depth in syndrome development, understanding, and public health action.
Detecting Suicide-related Emergency Department Visits Among Adults Using the District of Columbia Syndromic Surveillance System2
EDs are settings in which people contemplating or attempting suicide can be identified. The authors cite two studies: The first study found that about a third of the people who died from suicide visited an ED one or more times before death.3 Findings from the second study showed about 10% of those who died from suicide had visited an ED within 6 weeks of death.4 If health practitioners can better characterize suicide attempts and ideation, they are better prepared to intervene and prevent future attempts.
The authors describe how the near real-time nature of syndromic surveillance (SyS) has been useful in characterizing affected populations, guiding intervention, and identifying hospitals and geographic areas that can benefit from additional resources. They looked at different SyS systems that relied on Chief Complaint data (free-text, drop-down lists) to capture why people went to the ED and then examined the value added by discharge diagnoses data.
They studied data from eight hospital EDs captured by the District of Columbia SyS system (DC–ESSENCE), searching Chief Complaints (CC) and Discharge Diagnoses (DD) for suicide-related terms across 248,939 ED visits (October 1, 2015–September 30, 2016). Then they looked at whether suicide-related visits detected by CC, DD, or both showed variation by hospital or by patient sex and age.
The authors found that the use of CC data alone underestimates suicide-related ED visits. Findings from their study showed that DD data identified another 38% of suicide-related ED visits not captured by using just CC data.2 Consequently, queries should use both CC and DD data. SyS is a tool that can provide surveillance in near real-time for disclosed thoughts of suicide or attempts and prompt intervention or other public health response.
1CDC. Web-based Injury Statistics Query and Reporting System (WISQARS). (2018) Atlanta, GA: National Center for Injury Prevention and Control. Available from: https://www.cdc.gov/injury/wisqars/index.html
2Kuramoto-Crawford SJ, Spies EL, Davies-Cole J. Detecting Suicide-related Emergency Department Visits Among Adults Using the District of Columbia Syndromic Surveillance System. Public Health Reports [Internet]. 2017 July/August [cited 2019 Feb 2];132(1 Suppl):88S–94S. Available from: https://journals.sagepub.com/doi/full/10.1177/0033354917706933
3Gairin I, House A, Owens D. Attendance at the Accident and Emergency Department in the Year before Suicide: Retrospective Study. British Journal of Psychiatry. 2003;183:28–33.
4Cerel J, Singleton MD, Brown MM, et al. Emergency Department Visits Prior to Suicide and Homicide: Linking Statewide Surveillance Systems. Crisis. 2016;37(1):5–12.
NSSP’s policy to deactivate facilities that fail to send data for 90 or more days goes into effect this month (March 2019). An operational review of the Master Facility Table conducted in January and February revealed that some production facilities are not sending data to the BioSense Platform despite being set to “Active.” The NSSP Team alerted the site administrators for these facilities and offered support.
Of the 843 facilities proposed for deactivation, 264 will be moved to “Onboarding” status while they resolve interfaces or data quality issues that resulted from changes to their electronic medical records systems. Another 134 are restarting data submission, and 140 are being deactivated.
The Access & Management Center (AMC) will be updated mid-April to meet federal data security requirements. Contractors or foreign nationals (neither a citizen nor permanent U.S. resident) who use the BioSense Platform must be identified as such on their user profiles. Site administrators will be required to update user accounts for these two status indicators.
AMC passwords will also be affected. Platform users will be required to follow new federal guidelines such as ensuring passwords are 12 characters long, making sure passwords are not reused for 24 cycles, and setting up new passwords where 75 percent of the characters are different from those in the previous password.
|March 6||Data Validation Conference Call, 3:00–4:00 PM ET|
|March 19||NSSP CoP Call; 3:00–4:30 PM ET; Topic: Spring Health Hazards; register here|
|March 19||Scheduled vendor patches in staging environment: 6:00–10:00 AM ET|
|March 21||Scheduled vendor patches in production environment: 6:00–10:00 AM ET|
|February 6||Held Data Validation Conference Call|
|February 19||Applied vendor patches in staging environment|
|February 21||Applied vendor patches in production environment|
A total of 57 sites from 47 states, including the District of Columbia, participate in NSSP. Currently, there are 4,141 facilities, including 2,766 emergency departments (ED), actively contributing data to the NSSP BioSense Platform. Data from these EDs cover about 65% of all ED visits in the country.
NSSP publishes data for ED visit coverage each quarter. These data and the coverage map shown below were updated January 2019.
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.
The community and NSSP team have put considerable effort into streamlining new-site onboarding and improving data collection, management, and reporting. NSSP now has timely, high-quality data that can be used to estimate ED visit coverage.
If you missed the article that describes the new calculation method, check out the December 2018 issue of NSSP Update.