NSSP Update – October 2019

People

People

Community of Practice

Introducing NSSP’s New CoP Partner

We are pleased to announce that the Council of State and Territorial Epidemiologists (CSTE) has been selected as our new partner to facilitate the National Syndromic Surveillance Program Community of Practice (NSSP CoP) through the Center for State, Tribal, Local, and Territorial Support National Partnership Cooperative Agreement (CDC OT18-1802). CSTE was selected through a competitive process among the 39 national partners who are recipients of CDC OT18-1802.

We will meet with CSTE in the next few weeks to begin transitioning CoP activities. During this time, we ask for your patience. Until the transition is completed, the NSSP team will continue to support the CoP workgroup and committee calls.

NSSP will use several channels to keep you and others in the community up-to-date about the transition, including communications from the NSSP CoP group chairs and co-chairs, monthly NSSP Update newsletter, and CDC’s NSSP Portal (https://www.syndromicsurveillance.org/).

Questions? Suggestions? Please send correspondence to the NSSP mailbox: nssp@cdc.gov.

Monthly NSSP CoP Call

NSSP Community of Practice Portal

Please join your colleagues for the monthly NSSP Community of Practice (NSSP CoP) call. The next call will be held October 22, 3:00–4:30 PM ET. The topic is Lung Injury Response.

New member? Syndrome? Success? Email NSSP!

Become a part of the NSSP CoP. To participate, simply email nssp@cdc.gov and provide your name, contact information, and request to be part of the NSSP CoP.

If you have a syndrome to share, success story to showcase, or resources to post on the Knowledge Repository, please email nssp@cdc.gov. We will forward your request to the appropriate NSSP CoP committee or workgroup to review before posting.


Implementation Guide for Syndromic Surveillance

Final edits to the Implementation Guide for Syndromic Surveillance Release 1.0 were completed in June 2019, thanks to Community of Practice participation. In July 2019, the guide was posted on the HL7 website, and the National Institute of Standards and Technology Implementation Authoring Tool (NIST IGAMT) released the message validation tool for testing. NIST IGAMT is open access, and anyone can enter the site as a guest user and validate messages for this specification.

Currently, the Implementation Guide is in its 90-day review period and has been posted as a WIKI page for collaborative editing at http://www.hl7.org/implement/standards/product_brief.cfm?product_id=503. If you aren’t an HL7 member, you can make suggestions by submitting a ticket to the NSSP Service Desk (an account is required), where NSSP has set up an Implementation Guide queue to triage comments.

HL7 2.5.1 Implementation Guide Milestones
HL7 2.5.1 Implementation Guide Milestones*
Time Frame Activity
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
2018 Fall
(October–December)
  • Submitted to HL7 for Review in November 2018
  • Integrated and Began Resolution of 221 HL7 and Public-provided Comments
  • Resolved and Closed 135 Comments from Fall Ballot (approved by HL7 December 2018)
2018 November–
2019 March
  • Reconciled Comments and Obtained Final Approval from HL7 Public Health Workgroup
  • Two-week Reposting of Dispositions (Final Voting)
2019 January Provided Final Resolution for 33 Comments (Pending)
2019 February
  • Further Integrated Approved Changes
  • Provided Final Resolution for 30 Comments (Anticipated)
2019 March–May
  • Further Integrated Approved Changes
  • Continued to Provide Final Resolution for Comments
  • Continued to Provide HL7 International with Block Group Review (4 remaining)
  • Imported Manual Changes into IGAMT (NIST)
  • Exported Final Manual for Review and Edit (ISDS Message Mapping Guide Workgroup and CDC Internal Review)
  • Resubmitted Updated Implementation Guide for Final HL7 Ballot Voting (including 2-week review by ballot participants)
  • Began Next Round of HL7 Block Review (23 items out of 320 outstanding)
  • Conducted Another IGAMT Export
  • Established Submission Date for HL7 Public Health Workgroup
2019 June 20–27 Hand-off to HL7 Public Health Workgroup for 2-week Review
2019 July
  • Resolve Comments from HL7 Public Health Workgroup Review
  • Hand-off to HL7 Technical Steering Committee for Approval
  • Begin Work with HL7 Editor to Format Distribution-ready Version of Implementation Guide (in accord with HL7 guidelines)
  • Begin 90-member HL7 Review (released on HL7 member-only WIKI July 28, 2019)
2019 August–October
  • Submit Request to HL7 for Publication as a Standard for Trial Use
  • NSSP will Work with NSSP Community of Practice on a Strategy to Pilot Test Implementation Guide
  • Begin Recruitment Process for Pilot Participation in Hospitals and Public Health Departments and across Electronic Health Record (EHR) Vendors
  • Confirm Pilot Site Participation
  • Develop Strategy for Testing NSSP Receipt of Data Using New Public Health Authority Standard
October 26, 2019 Release to Public: HL7 2.5.1 Implementation Guide for Syndromic Surveillance Version 1 as a Standard for Trial Use for the General Public
Fall 2019 Plan for Pilot Testing of Implementation Guide
2020 Initiate Pilot Tests of Implementation Guide
2019 September–2022 September Publish Standard for Trial Use for Period of 1 to 3 years (during which time additional comments may be submitted and dispositioned and additional releases of the guide published)

* Milestones revised October 1, 2019.
** Version 2.0 is currently being used; subsequent versions are working drafts only.
Shaded activities have been completed.

Fall 2019 Pilot Testing of Implementation Guide

Volunteers Needed

Let’s kick the tires and take the Implementation Guide for a spin. In the next few months, NSSP will lead pilot tests for electronic health record (EHR) vendors, hospitals, and health departments. About 30 variables were revised or created, and the pilot will assess whether business processes across these organizations can support the new guidance with reasonable effort.

This document will guide the community’s efforts for years to come. If you would like to volunteer, we’re beginning the planning process and scoping out the evaluative measures for the pilots. We anticipate the pilots to begin in the fall. We could use your help making sure messages are complete, processed seamlessly, and received intact. More details will be shared soon. If interested, please email nssp@cdc.gov.

CDC Funding Recipients and Partnership Updates

NSSP Infographic Promotes Early Warning Disease Detection

The Centers for Disease Control and Prevention (CDC) is promoting a new infographic that provides a high-level overview of NSSP and syndromic surveillance for use by appropriators and other decision makers. It explains in plain language both how and why we do syndromic surveillance.

The infographic conveys the importance of collaboration across local and state health departments, federal partners, and private sector partners. It demonstrates the versatility of syndromic data and how these data are already being integrated into state and local surveillance programs to protect the public’s health. It also promotes the ability of syndromic surveillance to improve situational awareness by serving as an early warning in disease detection.

Here’s a panel from the infographic that acknowledges the NSSP CoP’s collaborative role in using syndromic data to monitor public health:

How We Conduct Syndromic Surveillance graphic

ESSENCE QUERIES

ESSENCE Queries; August 2019

Query Terms from August 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 August 2019. We created it by using the Wordcloud2 package in RStudio. The relative size of the terms suggests the frequency of use in a query. NSSP super administrators can query ESSENCE usage logs to learn what queries are run nationwide and how long they take to complete.

Practice

NSSP Development of Queries to Support Lung Injury Response

In mid-August 2019, NSSP staff began working with members of the NSSP CoP and CDC’s National Center for Injury Prevention and Control (the Injury Center) to develop queries that could support CDC’s ongoing multistate lung injury response. The NSSP and Injury Center teams collaborated with community partners to draft and refine two definitions.

One query was designed to capture records that mention e-cigarette usage, and the other query searches for instances of severe respiratory injuries. The latter query includes respiratory distress and unexplained pneumonia and excludes infectious disease (e.g., influenza, pertussis, Legionella, bacterial pneumonia, and upper respiratory infection), asthma, sickle cell disease, cystic fibrosis, suicide, dialysis, diabetes, epilepsy, pregnancy, cancers, vehicle crashes, firearm injuries, heat-related illness, opioid and stimulant use, and other potential etiologies.

The NSSP team implemented a vaping query into NSSP–ESSENCE as a preset category. However, the severe respiratory injury query has not been added to the NSSP–ESSENCE application as a pre-built search option because lessons learned from health departments indicate that it is most useful when adapted to available local data. For example, jurisdictions with access to triage notes or other fields, such as pulse oximetry, may incorporate these into the search to reduce noise. The query can also be limited to patients who were hospitalized using discharge codes in the Advanced Query Tool. Jurisdictions that do not use ESSENCE can adapt the text of the query for use in their own local syndromic surveillance system.

Both queries may identify emergency department visits and hospitalizations that are unrelated to the current outbreak.

Next Steps
  • CDC continues to work closely with state and local health departments by providing tools to help them investigate a cluster of lung injuries linked to e-cigarettes, particularly among adolescents and young adults.
  • CDC and NSSP CoP partners are collaborating to apply these queries to bolster state-led case finding and explore the use of syndromic data to understand epidemiologic features of the outbreak.
CDC Resource:

Outbreak of Lung Illness Associated with Using E-cigarette Products: Investigation Notice

NSSP and NCIRD Assess ILINet Collaboration

States routinely use syndromic surveillance to monitor influenza-like illness (ILI) and detect novel influenza virus activity. Last year, the NSSP team collaborated with the Domestic Surveillance Team in CDC’s National Center for Immunization and Respiratory Diseases (NCIRD) to help states use ESSENCE to report in ILINet for the upcoming influenza season. ILINet is the U.S. Outpatient Influenza-like Illness Surveillance Network and serves as the syndromic surveillance component of influenza surveillance in the United States. ILINet collects information on outpatient visits to health care providers for influenza-like illness. Since influenza season is rapidly approaching, the NSSP team met with ILINet analysts to assess their experience thus far.

Slightly more than 50% of ILINet patient visits are from emergency medicine. Although most hospitals now use some form of electronic syndrome definition, ILINet was founded in the era of traditional syndromic surveillance when physicians would manually go through medical records and count the number of patients meeting a specific syndrome definition. To this day, ILINet reflects a combination of providers that do traditional and electronic reporting.

There are a couple of options for entering data from NSSP–ESSENCE into ILINet. Analysts and epidemiologists in health jurisdictions can pull NSSP–ESSENCE data from their own system and then upload to the ILINet database using a spreadsheet. Or, the NCIRD team can assist by extracting the data from NSSP–ESSENCE and uploading the data into ILINet. Far more practitioners choose to pull data themselves.

NCIRD’s flu team uses historic data to generate a baseline for each provider, the health jurisdiction, the U.S. Department of Health and Human Services (HHS) regions, and the nation. They look at how far above or below baseline influenza activity is each year. To ensure data are comparable to the calculated baselines, they also ask state contacts to identify the facilities from whatever syndromic systems are being used to collect aggregate data. Data from facilities that see, on average, more than 500 patients per week will undergo a data validation process.

Most reporting facilities use the chief complaint (CC) field only. Some use chief complaint and discharge diagnosis (CCDD). Nationally, the two strategies present the same overall picture, but more information is available using CCDD.

Benefits of Integrating Syndromic Data with ILINet

The use of electronic syndromic surveillance generates a wealth of data—and with much less effort. The advantages of using syndromic surveillance are reduced reporting burden, more timely and complete information, consistently applied criteria, and year-round monitoring. Everyone benefits from having comparable data to analyze across health jurisdictions. During influenza season, the NCIRD’s flu team conducts monthly meetings with states, and having timely data has improved communication.

Challenges

The NCIRD and NSSP teams have worked through some challenges. Initially, NCIRD had to set up data sharing rules with the interested health jurisdictions. This proved challenging as there wasn’t a solution that would accommodate the concerns of each individual health jurisdiction. Having a rule-sharing template would have been helpful. On the basis of lessons learned through recent data-sharing workshops, the NSSP team has some ideas to implement this fall that should make data sharing easier. For example, NSSP is planning an update that will enable sites to share specific syndromes without granting full data access.

Keeping up with site changes is also challenging—staff move on, facility names change, and physicians’ hospital affiliations may change. Such changes made matching facilities in NSSP–ESSENCE to the appropriate ID in ILINet difficult. Even more challenging, however, is keeping up with the technical aspects of using a different system and tools.

Next Steps

The NCIRD and NSSP teams will continue to evaluate the process and share what works or needs improvement. In preparation for an emergency event, such as a pandemic, NCIRD would like to learn how to interpret daily ILI data. Both teams also want broader coverage. Getting data from 10 hospitals in the same metro area is useful, but getting data from rural areas is needed to better characterize the extent of a health problem. The NCIRD team also has an interest in diversifying their participating provider types to mimic the care-seeking behaviors of the U.S. population.

The NSSP team will continue to work closely with NCIRD and with other programs that are learning to use syndromic data. Those who routinely work with syndromic data understand its complexities. But educating others on how to interpret these data and what actions to take in response to findings is one of the more challenging aspects of integrating system data.

The NSSP team thanks the analysts at NCIRD for describing how they use syndromic data to validate ILINet results.

Collaborations Accelerate SyS Practice

Collaborations initiated by the NSSP CoP Steering Committee (and its workgroups and committees) and health departments partnering with CDC programs are improving how syndromic surveillance gets done. The list of collaborations that follows, while not exhaustive, summarizes ongoing efforts to develop and improve syndrome definitions, conduct pilot tests and exercises, and improve processes to achieve public health goals more efficiently.

Here are the collaborations rapidly moving us into 2020:

Three-month Outlook:

  • Develop syndrome definition for diabetic ketoacidiosis (a life-threatening but avoidable complication of diabetes when high levels of blood acids, ketones, are produced), specifically searching the discharge diagnosis field for ICD-9/10 codes.
    • Collaborator: Division of Diabetes Translation with their Surveillance Team
    • JUST RELEASED! Check out the syndrome in ESSENCE.
  • Develop a sexual violence v3 definition.
    • Collaborator: CDC’s Division of Violence Prevention
    • Scheduled for early fall 2019
  • Develop syndrome definition for pregnancy, delivery, and miscarriage.
    • Collaborator: CDC’s Maternal and Infant Health/Maternal and Infant Health Branch (MIHB)
    • Scheduled for early fall 2019
  • Develop syndrome definition for alcohol-involved emergency department visits.
    • Collaborator: Opioid and Overdose Team
    • Scheduled for early fall 2019
  • Develop syndrome definition for injecting drug users (IDUs) and endocarditis (infection of inner lining of heart chamber and valves).
    • Collaborator: CDC’s National Center for Emerging and Zoonotic Infectious Diseases, Epidemiology Research and Innovations Branch
    • Scheduled for fall 2019
  • Develop syndrome definition for e-scooter-related injuries. NSSP is part of the Transportation Safety Team’s e-scooter working group.
    • Collaborator: CDC’s Division of Unintentional Injury Prevention and the Transportation Safety Team
    • Scheduled for fall 2019
Want help meeting surveillance goals?
Collaborate.
Engage NSSP, CDC programs, or health jurisdictions about special projects by emailing
  • Develop syndrome definition for motor vehicle collision syndrome.
    • Collaborator: CDC’s Division of Unintentional Injury Prevention and the Transportation Safety Team
    • Scheduled for fall 2019
  • Develop syndrome definition for child abuse and neglect.
    • Collaborator: CDC’s Division of Violence Prevention
  • Develop syndrome definition for child sexual abuse.
    • Collaborator: CDC’s Division of Violence Prevention
  • Develop syndrome definition for sex trafficking.
    • Collaborator: CDC’s Division of Violence Prevention
  • Develop syndrome definition for teen dating violence.
    • Collaborator: CDC’s Division of Violence Prevention
  • Develop syndrome definition for homeless populations.
    • Collaborator: CDC’s Division of Violence Prevention
  • Develop syndrome definition for animal bite.
  • Develop syndrome definition for marijuana v3.
    • Collaborator: CDC’s Opioid and Overdose Team
  • Develop syndrome definition for synthetic marijuana.
    • Collaborator: CDC’s Opioid and Overdose Team
  • Update syndrome definition for Influenza-like Illness (ILI) CCDD category.
    • Collaborator: CDC’s Influenza Division

2019–2020:

  • NSSP is evaluating the detector methods for CC, DD, and CCDD fields to identify whether field choice affects how signals or alerts are created. NSSP will test multiple baselines in accord with detector methods. Afterwards, NSSP will develop best practices for using detector methods.
  • NSSP is working with CDC’s National Center for Environmental Health to capture radiation exposures following a radiation disaster. They are examining how syndromic data can be used to supplement existing radiation exposure surveillance using poison control center data.
  • NSSP is participating in a functional exercise to gauge how well the community shares information and data during a public health event. This exercise will evaluate response speed; technical needs and delivery options; potential local, state, and federal collaborations; and integration of emergency preparedness and management personnel.
    • Collaborator: NSSP CoP syndromic Surveillance and Public Health Emergency Preparedness Response and Recovery (SPHERR) Committee
  • NSSP is working with CDC’s National Center for Chronic Disease Prevention and Health Promotion, Division of Cancer Prevention and Control, on a special-interest project though the Prevention Research Centers Program: “Improving Cancer Survivor Treatment and Outcomes by Ensuring Appropriate Emergency/Acute Care Treatment.” Work will begin fall 2019 and extend through 2020.

The dates listed are approximations and can change. Our thanks to Health Scientist Nimi Idaikkadar (Center for Surveillance, Epidemiology, and Laboratory Services; Division of Health Informatics and Surveillance) for this update.

Free-text Coding in NSSP–ESSENCE

 

Part 6: Wrapping Things Up

This is the final article in the series about how to write ESSENCE free-text queries. We thank Senior Data Analyst Zachary Stein for developing this series.

Part 1. Wildcards
Part 2. Underscores_and Brackets [ ]
Part 3. Inclusionary Terms
Part 4. Exclusion Terms and Parentheses
Part 5. A “Starter” Fall-related Injury Query and Examples of Complex Queries

Introduction

The search criteria for ESSENCE free-text queries are built around Boolean logical operators and regular expressions. Free-text queries are not case-sensitive and may contain “^” for wildcards; “,” for multiple entries; “ISBLANK” to look for blanks; “ISNULL” to look for nulls; “[COMMA]” to look for commas; and operators “and,” “or,”, “andnot,” and parentheses “()” to define order and grouping. This series covers all these topics in-depth.

Free-text queries are what makes syndromic surveillance practice, particularly practice using NSSP–ESSENCE, adaptable to different data sources and types. By using free-text queries, analysts and epidemiologists can exercise a high level of customization. They can quickly code free-text queries and rapidly respond to outbreaks, disasters, and events that unfold. Such capabilities empower users to customize queries to fit their level of data, ensuring accurate results.

Free-text coding in ESSENCE, which is accessible to all users, follows distinct patterns. Learning to read these patterns allows users to take queries from many places and repurpose them to suit their unique needs. Syndromic surveillance depends heavily on sharing methods, and practitioners must understand the language.

Part 6. Wrapping Things Up

Building off last month’s article, we start with the query:

(,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out with^,),OR,^Fell^,),OR,(,^[;/ ]W[01][0-9]^,)

In that same article, we noted negations needed for things falling on patients, medical devices “falling out,” and other items like mentions of “fallopian tubes.”

We can incorporate these changes to make the following query:

(,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,),ANDNOT,^[;/ ]W20^,OR,(,^[;/ ]W[01][0-9]^,)

Notice how these changes shorten the term ^Falling out with^ to broaden negated Chief Complaints (CCs) and to include medical devices that fall out; add a CC negation for ^Fallop^; and add a negation to ICD10 codes for W20 – Struck by thrown, projected, or falling object. The placement of the W20 ICD10 code negation is important. For example, if the negation is placed at the end, it will negate visits regardless of other criteria met. If we place it after the CC terms as shown above, it will not negate visits containing a positive W10-19 ICD10 code or indicate a visit of interest.

Try it out!

Note the difference in W20 negations on these two queries. Run each query in the CCDD field of ESSENCE. Why do they give different results? Why are certain cases negated by one and not the other? If the queries don’t show different results for your data, try running these in the CCQV data.

(,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,),ANDNOT,^[;/ ]W20^,OR,(,^[;/ ]W[01][0-9]^,)

(,(,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,),OR,(,^[;/ ]W[01][0-9]^,),),ANDNOT,^[;/ ]W20^

Reviewing our Query

Now that we have a well-performing query, we can review all cases to assess performance (possible false positives and true positives), but that doesn’t enable us to review negated cases (possible false negatives and true negatives). Likewise, how do we isolate performance in DD fields versus CC fields? We do this by breaking our query apart and reassembling it in different ways. Let’s leverage ESSENCE to answer some of these questions.

Fall-related Query Assessment
Fall-related Query Assessment
Code Description
(,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,),ANDNOT,^[;/ ]W20^,OR,(,^[;/ ]W[01][0-9]^,)
Beginning Query
(,^Fall^,AND,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),),OR,(,^Fall^,OR,^Fell^,),AND,^[;/ ]W20^
Isolating Negations: By reorganizing our query and replacing the “ANDNOTs” with “ANDs,” we can assess just those visits we chose to negate.
(,^[;/ ]W[01][0-9]^,)
Field Isolation, Any DD Codes: How heavily does our query rely on the ICD10 codes within it? This query returns the visits that were picked based on the DD criteria.
(,^[;/ ]W[01][0-9]^,),ANDNOT,(,(,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,),ANDNOT,^[;/ ]W20^,)
Field Isolation, DD Codes ONLY: How many of our visits were picked based on the DD criteria ONLY? This query negates all CC portions.
(,^[;/ ]W[01][0-9]^,),AND,(,(,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,),ANDNOT,^[;/ ]W20^,)
Field Isolation, DD AND CC: How many of our visits were picked based on BOTH DD and CC criteria? This query shows the overlap—or, those patients that have a fall-related CC and received a fall-related ICD10 code.
(,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,),
Field Isolation, Any CC Terms: How heavily does our query rely on the CC terms within it? This query returns the visits that were picked based on those criteria.
(,(,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,),ANDNOT,^[;/ ]W20^,),ANDNOT,(,^[;/ ]W[01][0-9]^,)
Field Isolation, CC Terms ONLY: How many of our visits were picked based on fall-related CC terms but did NOT receive a fall-related ICD10 code?

 

The results (counts) from the queries in the preceding table should add up as follows:

Beginning Query = CC Terms ONLY + DD Codes ONLY + DD and CC Overlap
Any CC Terms = CC Terms ONLY + DD and CC Overlap
Any DD Codes = DD Codes ONLY + DD and CC Overlap

This can be a useful way to understand how the different parts of your query work together.

Reminder—To view the ESSENCE Fall Subsyndrome details, log in to NSSP–ESSENCE, hover over the “More” tab, and click “Syndrome Definitions.” After the page loads, click the “Subsyndrome” link, and then scroll through the alphabetical list and click “Fall.”

Let’s Take This a Step Further . . .

ESSENCE has a Fall Subsyndrome that already does a great job capturing fall-related Chief Complaints. Did we really improve fall-related ED surveillance by making a new syndrome? Could we have leveraged the existing query in our new query? Here are some steps to leverage ESSENCE in answering these questions.

To see how our query performs compared with the Fall Subsyndrome, we can run the following queries:

 

Subsyndrome versus New Query Assessment
Subsyndrome versus New Query Assessment
Code Description
CCDD: (,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,),ANDNOT,^[;/ ]W20^,OR,(,^[;/ ]W[01][0-9]^,)

SubSyndrome Free Text: ^Fall^
New query and subsyndrome overlap: By running our new query in the CCDD field and the subsyndrome in the “Subsyndrome Free Text” field, ESSENCE will automatically apply an “AND” between these two criteria and return the overlap.
CCDD: (,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,),ANDNOT,^[;/ ]W20^,OR,(,^[;/ ]W[01][0-9]^,)

SubSyndrome Free Text: ISNULL,or,^,ANDNOT,^Fall^
New query ONLY: If we run our new query normally and then add negations in the “Subsyndrome Free Text” field, we can ensure that Fall Subsyndrome visits are NOT returned.
CCDD: ^,ANDNOT,(,(,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,),ANDNOT,^[;/ ]W20^,OR,(,^[;/ ]W[01][0-9]^,),)

SubSyndrome Free Text: ^Fall^
Subsyndrome ONLY: By following the same pattern as the “New query ONLY” example above, we can return only those visits that meet the existing subsyndrome criteria, while not meeting our new syndrome definition.
CCDD: (,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,)

SubSyndrome Free Text: ISNULL,or,^,ANDNOT,^Fall^
New query CC portion ONLY: It isn’t fair to pit the Fall Subsyndrome against our query because ours leverages the DD field. To even the comparison, we can check how well our query fares by pitting just the CC portion against the Fall Subsyndrome. We can do this by removing the DD criteria and running it in the CCDD field.

 

There is a concept in the preceding table that was not previously covered in this series. We can illustrate this new concept by examining a hypothetical situation.

Let’s say you’re an analyst and have been asked to provide a timeseries graph of syndromic surveillance data for all visits EXCLUDING visits labeled with the ESSENCE “Occupational” or “ToolsOrMachinery” subsyndromes. What is the quickest way to exclude only these visits from your ESSENCE query?

By executing the following query in the Subsyndrome free-text field, you are asking “Give me Nulls or Non-Nulls, so long as the Non-Nulls do NOT contain the text ‘Occupational’ or ‘ToolsOrMachinery.’ “

ISNULL,or,^,ANDNOT,(,^Occupational^,OR,^ToolsOrMachinery^,)

The string “ISNULL,or,^,” will return all visits when run in a free-text field because, logically, a field is either null or has contents (^ also captures blanks). When using this format, the negation string should never apply to the ISNULL criteria. That’s because the three-valued logic of SQL results in the ANDNOT statement being interpreted as “Not Null,” and thus, the query is interpreted as (NULL) ANDNOT NULL. If ANDNOT statements are applied to the “ISNULL,” you will get unexpected results.

Now let’s examine a real-life example. In the first version of a Severe Respiratory Illness query shared in response to the Vaping-related Illness response, the query included (along with lots of other criteria) the following code in the Subsyndrome free-text field to exclude visits related to Alcohol Use and Altered Mental Status:

(,^,or,ISNULL,),andnot,(,^alteredmental^,or,^Alcohol^,)

ESSENCE interprets this as nothing can be “ISNULL” if it contains ^alteredmental^ or ^Alcohol^. No NULL field can meet these criteria by using these negations. Consequently, the query excluded all NULL fields. This exclusion of NULL fields did not meet the intent of the query, which was designed to exclude only visits NOT labeled with AlteredMentalStatus or Alcohol SubSyndromes. On the other hand, the NULL fields (those not labeled with a subsyndrome) met the intended criteria quite well.

This became a problem for the health jurisdictions running the shared Severe Respiratory Illness query. An updated query was shared shortly afterwards that remedied the problem by formatting these negations so that they would not apply the “ANDNOT” string to the ISNULL criteria, as follows:

ISNULL,or,^,ANDNOT,(,^alteredmental^,or,^Alcohol^,)

After doing this work to compare the Fall Subsyndrome with a new query, we can see that our new query’s Chief Complaint portion does little to improve upon the Fall Subsyndrome until the DD codes are added. Because the Fall Subsyndrome contains diverse processing like fuzzy matching and negative terms, one solution is to try capturing the best of both worlds by using the following query:

(,^Fall^,ANDNOT,(,^Crestfallen^,OR,^Falling out^,OR,^Fallop^,OR,^Fall Out^,),OR,^Fell^,),ANDNOT,^[;/ ]W20^,OR,(,^[;/ ]W[01][0-9]^,),or,^;Fall^

Paste this query into the CCDD free-text field Then select the option for “SubSyndrome Free Text” from the “Also apply the search string to:” box below it (figure 1). Note the added term ^;Fall^ will capture these subsyndrome visits because the subsyndrome list field is separated by semicolons.

Figure 1

Figure 1. Custom Fall and Subsyndrome Query Setup

More Tips for Breaking Down a Query

Syndromic surveillance often depends on the ability to take a shared query or syndrome definition, break it down, and repurpose it. To do this, the user must be able to reliably parse how a definition works. There are multiple ways to do this, but here is a good way to get started:

(arrow)Assess whether the parenthetical statements in a query are working. This can be difficult, especially in long queries. A tool like the free program NotePad++ will highlight the related closed parenthesis when you hover over an open parenthesis and vice versa. Tools that highlight parenthesis pairs are helpful to find where sections of code start and end.

Another tool that will help you understand how parentheses are being used is the “replace” tool in Microsoft Word. Paste the query into Word and try replacing different portions such as open parentheses, closed parentheses, or ANDNOT operators with the string “^p.” The caret and lowercase p will insert a line break wherever the specified criteria are found.

For example, let’s use the CCDD Category for CDC Chronic Hepatitis C v1:

(,^chronic viral Hep[aei]t[ei]t[ei]s C^,or,^chronic Hep[aei]t[ei]t[ei]s C^,andnot,^Hep[aei]t[ei]t[ei]s C[a-z]^,),or,^[;/ ]B1[89].2^,or,^[;/ ]B1[89]2^,or,^[;/ ]831000119103^,or,^[;/ ]128302006^,or,^[;/ ]768127002^,or,^[;/ ]768289009^,or,^[;/ ]768288001^,or,^[;/ ]768125005^,or,^[;/ ]768006009^,or,^[;/ ]768126006^,or,^[;/ ]767810006^,or,^[;/ ]767810006^,or,^[;/ ]767809001^,or,^[;/ ]708198006^,or,^[;/ ]146371000119104^,or,^[;/ ]120241000119100^,or,^[;/ ]347891000119103^,or,^[;/ ]703866000^,or,^[;/ ]128971000119101^

If we paste the query into Word and then use the “Find and Replace” tool to replace the parenthesis with )^p as shown in figure 2…

Figure 2. Simple Code Modification

Figure 2. Simple Code Modification

 

…we get this modification to the code and can clearly see a separation between Chief Complaint terms and Discharge Diagnosis codes.

(,^chronic viral Hep[aei]t[ei]t[ei]s C^,or,^chronic Hep[aei]t[ei]t[ei]s C^,andnot,^Hep[aei]t[ei]t[ei]s C[a-z]^,)

,or,^[;/ ]B1[89].2^,or,^[;/ ]B1[89]2^,or,^[;/ ]831000119103^,or,^[;/ ]128302006^,or,^[;/ ]768127002^,or,^[;/ ]768289009^,or,^[;/ ]768288001^,or,^[;/ ]768125005^,or,^[;/ ]768006009^,or,^[;/ ]768126006^,or,^[;/ ]767810006^,or,^[;/ ]767810006^,or,^[;/ ]767809001^,or,^[;/ ]708198006^,or,^[;/ ]146371000119104^,or,^[;/ ]120241000119100^,or,^[;/ ]347891000119103^,or,^[;/ ]703866000^,or,^[;/ ]128971000119101^

Now we can combine these sections of code and test how our query works. To fully understand a query, you may need to repeat the steps in the first half of this article. Then you should be able to answer the following questions: What proportion of these visits are due to the DD codes? What proportion is due to CC terms? What types of visits receive a positive CC text but don’t get a related DD code?

Another example is the CDC Measles CCDD v1. When we follow the “Word: Find and Replace” process, we can see the two parts of this query break down into “Inclusion Criteria” and “Exclusion Criteria.” That is exactly how the developers intended this query to perform, but it results in measles-positive diagnosis codes being negated by text strings like “Vaccine” or “Rubella,” which a user might consider unintended consequences of the query. Anyone using this query must question whether a diagnosis code-positive visit is a positive regardless of other text terms. Both methods are reasonable, but only the users can decide what works best for their data and health jurisdiction.

(,^measl^,or,^meez^,or,^mesles^,or,^rubeo^,or, ^Measel^,or,^Measul^,or,^[;/ ]b05^,or,^[;/ ]14189004 ^,or,^[;/ ]417145006^,or,^[;/ ]28463004^,or,^[;/ ]195900001^,or^[;/ ]74918002^,or,^[;/ ]38921001^,or,^[;/ ]240484000^,or,^[;/ ]240483006^,or,^[;/ ]60013002^,or,^[;/ ]111872008^,or,^[;/ ]444435003^,or,^[;/ ]186562009^,or,^[;/ ]416154000^,or,^[;/ ]426558008^,or,^[;/ ]191727003^,or,^[;/ ]111873003^,or,^[;/ ]230146001^,or,^[;/ ]186561002^,or,^[;/ ]424306000^,or,^[;/ ]13420004^,or,^[;/ ]406592004^,or,^[;/ ]427290009^,or,^[;/ ]427263000^,or,^[;/ ]426654002^,or,^[;/ ]426424002^,or,^[;/ ] 427706006^,or,^[;/ ]426091009^,or,^[;/ ]425684000^,or,^[;/ ]425970007^,or,^[;/ ]732209005^,or,^[;/ ]426188007^,or,^[;/ ]426640005^,or,^[;/ ]427073007^,or,^[;/ ]732207007^,or,^[;/ ]426535005^,or,^[;/ ]426028006^,or,^[;/ ]427182003^,or,^[;/ ]732210000^,or,^[;/ ]698204007^,or,^[;/ ]425966004^,or,^[;/ ]416435006^,or,^[;/ ]444974003^,),andnot,(,^titer^,or,^measles mumps rubella^,or,^mmr^,or,^vacc^,or,^shot^,or,^immun^,or,^rubel^,or,^proph^,or,^room b05^,or,^german^,or,^homesless^,or,^rule out measles^,or,^[;/ ]47435007^,or,^[;/ ]371085006^,or,^[;/ ]150961000119105^,or,^[;/ ]61153008^,or,^[;/ ]150971000119104^,or,^[;/ ]473166002^,or,^[;/ ]703347005^,or,^[;/ ]170433008^,or,^[;/ ]170431005^,or,^[;/ ]432636005^,or,^[;/ ]571591000119106^,or,^[;/ ]170432003^,or,^[;/ ]433733003^,or,^[;/ ]572511000119105^,or,^[;/ ]440075005 ^,)

This concludes the six-part series on Free-text Coding in ESSENCE. If you have questions or suggestions, identify sections that need clarification, or think of a topic we overlooked, please contact Zachary Stein at oru8@CDC.Gov or the NSSP Service Desk.

Data Quality Corner

NSSP Data Quality (DQ) Dashboard Now Available!

An Interactive DQ Monitoring and Investigation Tool
Data Quality Dashboard

 

DQ Dashboard Link (AMC password required):   https://dashboards.syndromicsurveillance.org/app/dqDashboard

NSSP shares your commitment to improving data quality and advancing the tools used to monitor and investigate potential issues with data processing and data content. We are pleased to announce that the first version of the interactive NSSP DQ Dashboard was released September 16, 2019!

The NSSP DQ Dashboard is one more tool that’s been added to the site administrator’s NSSP Data Quality toolbox. This multifunctional tool is designed to give you an at-a-glance view of the “health” of your data and to identify where you need to dive deeper to resolve data quality issues. This is troubleshooting on the front line. NSSP puts DQ metrics at your fingertips!

NSSP DQ Toolbox for Site Administrators
  • Detailed Excel DQ reports on data completeness, timeliness, and validity—delivered monthly
  • Data-Quality-on-Demand (DQOD) SAS tool provides self-service delivery of detailed Excel DQ reports—you control delivery!
  • Executive-level report highlighting DQ metrics—delivered quarterly
  • Site Summary Processing emails provide alerts about data processing and potential issues with end-to-end data flow—delivered daily
  • Email alerts when active facilities are not sending data (30-, 60-, and 90-day alerts)
Use the NSSP DQ Dashboard to get a pulse read of the general health of your data flow and data content!

The NSSP DQ Dashboard can help you identify and resolve potential issues in data being submitted by vendor or facility partners. If a facility experiences network problems or a vendor updates software that affects the content of the feed, your team needs to know how this affects routine and emergency surveillance activities.

Share reports. Collaborate on solutions.

Information is power! The DQ Dashboard provides download capability that lets you store tables and graphs and create reports. Share reports with your vendor and facility partners to let them know how they are doing. Use the reports to encourage and facilitate collaboration when troubleshooting and correcting issues.

The dashboard was introduced during the September NSSP Community of Practice monthly meeting. To view the webinar, visit the Knowledge Repository. We plan to record a comprehensive demo of the dashboard in the future.

Frequently Asked Questions about the DQ Dashboard

Who should use the DQ Dashboard?

The dashboard is for anyone who monitors and assesses data at the front line—the ground zero of data. This includes site and facility staff who ensure feeds are operational, assess data timeliness, determine if data completeness meet expectations, and identify validity issues associated with vocabulary standards. All site administrators have been granted access to the dashboard.

Can others on my team use the DQ Dashboard?

Yes, other team members can use the dashboard with site administrator approval. Site administrators may delegate data quality responsibility to others by submitting a ticket to the NSSP Service Desk (http://support.syndromicsurveillance.org). Include the usernames and email addresses of the team members who need access. Users who are granted access will see ALL data quality metrics for your site.

How do I log in to the NSSP DQ Dashboard?

To access the DQ Dashboard, go to https://dashboards.syndromicsurveillance.org/app/dqDashboard and enter your Access & Management Center (AMC) username and password to log in. The October 2019 update to the AMC will include a link to the dashboard.

What data are being used in the NSSP DQ Dashboard?

The NSSP DQ Dashboard focuses on data delivered to the BioSense Platform—pre-ESSENCE ingestion—so that you can assess data being provided by your facilities and vendors “as is.” The dashboard is designed to identify potential front-line issues.

How is this dashboard different from the ESSENCE DQ Dashboard?

Each dashboard focuses on different stages of the data flow. The NSSP DQ Dashboard focuses on data before ingestion into ESSENCE—or, what we’re calling the “front line.” The ESSENCE DQ Dashboard focuses on data quality after ingestion into ESSENCE.

Use the ESSENCE DQ Dashboard to see how business rules have been applied. Because the ESSENCE DQ Dashboard focuses on data after ingestion, you can see how data have been adjusted and collapsed for use within the application. Further, the ESSENCE DQ Dashboard can help you and surveillance colleagues assess the quality of data being used for surveillance purposes.

How can I learn more about DQ Dashboard functionality?

For information on dashboard functionality, calculations, and visualizations, some online guidance has been embedded within the dashboard. Use the figure below to map each section of the dashboard page to its description:

  1. Guide: Provides a dashboard overview and explains dashboard navigation and functionality.
  2. Tutorial: Provides high-level guidance on dashboard functionality.
  3. Information: Describes the Web page being viewed, defines terms (i.e., Processed, Exceptions, Filtered, timeliness, completeness, and validity), and describes what data are available (including timeframe and when data are refreshed).
  4. Modal (Explanation Button): Explains the information being conveyed in the visualization and how to isolate or subset data in the graph. A modal is available for each visualization in the upper right corner.
Data Quality Dashboard snapshot
What if I need more help?

We’re here to help! The NSSP team can answer questions about the DQ Dashboard, provide support, and grant access. And, if you want to propose enhancements, we encourage your suggestions. Simply submit a DQ Dashboard Service Desk ticket at http://support.syndromicsurveillance.org.

Will there be opportunities for training?

We’re pleased to arrange training. You may request one-on-one (or team) training by submitting a DQ Dashboard Service Desk ticket at http://support.syndromicsurveillance.org.

Where can I submit suggestions?

We encourage feedback! Please submit a DQ Dashboard Service Desk ticket and share your ideas!  Submit at http://support.syndromicsurveillance.org.

Program

Technical Updates

Data Quality (DQ) Dashboards Now Available

The dashboards for accessing site data are available via WebLink. These dashboards will help site administrators investigate data quality issues through interactive, filterable data visualizations depicting data processing, timeliness, completeness, and validity metrics.

AMC Enhancements to Launch

Improvements to the Access & Management Center (AMC) will launch this month. Look for improved functionality for creating data access rules and downloadable reports for site administrators. The AMC will also include a direct link to the Data Quality Dashboards.

Current Month and Upcoming Events

Current Month and Upcoming Events
October 2 Data Validation Conference Call, 3:00–4:00 PM ET
October 22 NSSP CoP Call; 3:00–4:30 PM ET; The Lung Injury Response
October 15 Scheduled vendor patches in staging environment: 6:00–10:00 AM ET
October 17 Scheduled vendor patches in production environment: 6:00–10:00 AM ET

Top of Page

Last Month’s Technical Assistance

Last Month’s Technical Assistance
September 4 Held Data Validation Conference Call
September 20 Applied vendor patches in staging environment
September 22 Applied vendor patches in production environment

NSSP Participation and Coverage

Participation: The map below shows participation in NSSP as of September 2019, with 59 sites (47 states and the District of Columbia).

NSSP Participation Map

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.

Coverage: NSSP publishes data for ED visit coverage each quarter. As of June 30, 2019, data from EDs covered about 68% of all ED visits in the country. There were 4,478 facilities, including 3,021 emergency departments (EDs), from 58 sites (46 states and the District of Columbia) actively contributing data to the NSSP BioSense Platform. The calculation method is described in the December 2018 issue of NSSP Update.