NSSP Update: A Community Newsletter
COMMUNITY OF PRACTICE UPDATES
Looking for more information about laced and synthetic marijuana? View the recording of the April NSSP Community of Practice Call to learn about an outbreak in Illinois, and click here to view the syndrome definition created by the Illinois Department of Public Health. In case you missed it, the April issue of NSSP Update included a new Marijuana Chief Complaint/Discharge Diagnosis category for ESSENCE and linked to a couple CDC investigations related to synthetic marijuana. You can also see what members of the community are saying on our Syndromic Surveillance Forum. Come join our conversations!
Are you looking for more information about the NSSP Community of Practice (CoP)? Are you already a member of an NSSP CoP committee or workgroup and want more involvement in projects? Or, do you want to learn of other happenings in the community? Join the NSSP Community of Practice Group on healthsurveillance.org. Membership to the NSSP CoP as a guest is free. On the Group Page, you can find information about monthly NSSP CoP calls, connect with NSSP CoP members through the Group Directory, and get the latest news and updates via the Group Feed.
If you are already a member, please log in and complete your Organization and Location Information in your Profile so that we can create a Member Map to recognize your contribution to the community. View your profile by logging in and clicking on “My Profile” in the top right corner. Also, make sure the “Areas of Expertise” section is correct because a few new categories were added.
To learn about other CoP chapters, committees, and workgroups, check out the groups here. Registration is required to log in.
Please join the monthly NSSP Community of Practice (CoP) Call. This call engages stakeholders and sparks collaborative efforts to share guidance, resources, and technical assistance.
The next call will be held May 15, 2018, 3:00–4:30 PM ET on Emergency Preparedness and Surveillance Updates. Click here to register. You must register for each call individually. To access slides and recordings from previous calls, visit the NSSP Community of Practice Group Page.
The Message Guide Workgroup finalized the HL7 2.5.1 Implementation Guide for Syndromic Surveillance, Release 1, and it was available for comment through the HL7 May 2018 ballot. Balloting began on April 6, 2018, and continued through May 7, 2018. If you are interested in joining the workgroup, visit the Message Guide Workgroup page to access working documents and call-in information.
|2015||Version 2.0 Final RELEASE*|
|2016||Erratum and Clarification Documents Released for Version 2.0|
|2017 Summer||Version 2.2 Working Draft Released for Community Comment and Consensus|
|2017 Winter||Version 2.3 to be Released for Review and Community Comment|
|2018 March||Version .09|
|2018 Spring||HL7 Balloting; Guide Balloted is Implementation Guide for Syndromic Surveillance Release 1.0 Standard for Trial Use (STU) HL7 Version 2.5.1**|
|2018 Fall||Anticipated Completion of HL7 Balloting and Release of HL7 2.5.1 Implementation Guide for Syndromic Surveillance for Trial Use Version 1|
*Version 2.0 is currently being used; subsequent versions are working drafts only.
** Added April 2, 2018.
CDC FUNDING RECIPIENTS AND PARTNERSHIP UPDATES
The 31 recipients of the CDC-RFA-OE15-1502 cooperative agreement, The National Syndromic Surveillance Program: Enhancing Syndromic Surveillance Capacity and Practice, submitted their Annual Performance Reports (APRs) on April 6, 2018.
In addition to providing a detailed assessment of progress toward current goals, the APRs serve as noncompeting continuation applications for plans and funding anticipated in budget year four, fiscal year 2019. During the next few weeks, the NSSP project officers will be reviewing the APRs and submitting their recommendations into the Grants Management Module, which is part of GrantSolutions. The project officers will contact applicants in July about their Notices of Award for year four, which is the final year of funding under this cooperative agreement.
Kansas Local Health Department Uses Syndromic Surveillance Data to Direct Public Education on Rabies
We thank the Lawrence–Douglas County Health Department in Kansas for describing this use of ESSENCE* data. For more information, please email KDHE.Syndromic@ks.gov. To see the rabies query used, visit the NSSP Community of Practice Knowledge Repository.
The rabies virus infects the central nervous system, ultimately causing disease in the brain and then, later, death.1 This fatal, viral zoonotic disease is found in the saliva of a rabid animal and usually spread through a bite, although it also can be spread when infected saliva comes in direct contact with open wounds or mucous membranes. The incubation period in humans may last for weeks to months. However, rabies in people can be prevented with timely and appropriate administration of rabies postexposure prophylaxis (RPEP) before onset of clinical illness. People who have never been vaccinated will require human rabies immune globulin (HRIG) and four or five doses of rabies vaccine.
In Kansas, skunks are the primary reservoir for terrestrial rabies, with spill over into other wildlife and domestic animals. Separate rabies virus variants also are found in bats in Kansas. In the United States, bat-related rabies is the most common virus variant responsible for human cases of rabies.2 Evaluating potential exposure to bats and the need for RPEP can be complicated. The Advisory Committee on Immunizations Practices on Human Rabies Prevention states that “consultation with state and local health departments should always be sought” by healthcare providers when evaluating the need for RPEP.3
In Kansas, all suspected or confirmed rabies cases in humans or animals are required to be reported to the Kansas Department of Health and Environment. Cases are then assigned to the local health department in the county in which the human or animal resides. In Kansas, neither animal bites nor administration of RPEP is reportable. Often, RPEP is available only at the hospital emergency department (ED). Because RPEP administration is not a reportable condition, the Lawrence-Douglas County Health Department (LDCHD) had difficulty tracking the use of RPEP, which can be an indicator of public concern.
ESSENCE obtains near real-time ED data, which changed this scenario. Syndromic data are ideal for tracking RPEP that has been dispensed. In August 2017, the LDCHD communicable disease staff noticed an increase in calls and emails to the LDCHD about rabies and exposure to bats. In response, the Kansas Syndromic Surveillance Program developed ESSENCE rabies queries. Evaluation of the Chief Complaint provided supporting data to show more cases of RPEP were dispensed than anticipated—and most complaints involved bat exposure.
LDCHD used these and other data to develop an education campaign comprised of radio and social media outreach to the public and outreach to healthcare providers. The LDCHD wanted the public to know that although rabies treatment is available, it might not always be necessary. The LDCHD subject matter experts can assist healthcare providers in the decision to treat their patients.
1 Centers for Disease Control and Prevention (CDC). Rabies [online]. 2017. [cited 2018 Apr 4]. Available from: https://www.cdc.gov/rabies/
2 CDC. Notes from the Field: Assessing Rabies Risk After a Mass Bat Exposure at a Research Facility in a National Park—Wyoming, 2017. MMWR 2018;67(10);313–14. Available from: https://www.cdc.gov/mmwr/volumes/67/wr/mm6710a7.htm
3 CDC. Human Rabies Prevention—United States, 2008. Recommendations of the Advisory Committee on Immunization Practices. MMWR 2008;57(RR03);1–26, 28. Available from: https://www.cdc.gov/mmwr/preview/mmwrhtml/rr5703a1.htm
* Electronic Surveillance System for the Early Notification of Community-based Epidemics
The findings and conclusions in this report are those of the authors and do not necessarily represent the official position of the Centers for Disease Control and Prevention.
The Infectious Path of the Rabies Virus
CDC. Rabies: The Path of the Rabies Virus [online]. 2017. [cited 2018 May 1].
|May 2||Data Validation Support Call: 3:00–4:00 PM ET|
|May 15||Scheduled vendor patches in staging environment: 6:00–10:00 AM ET|
|May 15||NSSP Community of Practice Call: 3:00–4:30 PM ET. Topic: Emergency Preparedness and Surveillance Updates. Click here to register.|
|May 17||Scheduled vendor patches in production environment: 6:00–10:00 AM ET|
|June 10–14||2018 CSTE Annual Conference, “Let the Sun Shine: Using Data to Weather the Storms”; West Palm Beach, Florida|
|April 4||Data Validation Support Call|
|April 17||Scheduled vendor patches in staging environment|
|April 19||Scheduled vendor patches in production environment|
Q: What are “Special Rule” fields in NSSP–ESSENCE?
A: During the transition from ESSENCE ER_Import_Staging_Table to ER_Base, ESSENCE collapses all messages tied to a visit into one ESSENCE ID (or record). For most fields in the ER_Base table, ESSENCE processing selects the field’s value from the last message tied to that visit.
Some fields, however, follow “special rules” when processing data from ER_Import_Staging_Table to ER_Base. For these special fields, ESSENCE searches all messages tied to that visit and selects either the first non-null value (e.g., chief complaint) or the last non-null value (e.g., patient class, diagnosis, discharge disposition) for the field.
So, what does this mean?
Fields can be treated differently when a visit is collapsed. Fields that normally support each other may display competing information. One common example of this is DischargeDisposition—a “special rule” field. When the disposition code in DischargeDisposition is mapped to Disposition Category “Death” (using the Disposition Category Mapping table), you might see values different than expected. This is because other death-related fields are processing the value from the last message tied to that visit, not from the last non-null value (as DischargeDisposition does).
Here’s an example where two messages are tied to one visit:
|NSSP Archive Processed Table|
|-738456734||2/24/18 6:33 AM||20||Yes||Y||Indicator||2/22/18 12:53 PM|
|-749819758||2/27/18 3:18 AM||NULL||No||NULL||NULL||NULL|
When calculating C_Death, processing first looks at Patient_Death_Indicator for a “yes value”; if it finds none there, it looks next to Death_Date_Time for a non-null value. If processing finds no valid value in Death_Date_Time, it looks last toward Discharge_Disposition for a death-related disposition code.
If any step in the search returns positive, C_Death is set to “Yes,” and C_Death_Source is set accordingly. In the first message, you can see that C_Death_Source is set to “Indicator,” which means Patient_Death_Indicator is used as the confirming source of patient’s death.
When moving from ER_Import_Staging_Table to ER_Base, ESSENCE collapses the two messages into one record (see following table). Note: Patient_Death_Indicator is not ingested into ESSENCE. Although there is a column in ESSENCE named DeathIndicator, it is not used by NSSP ESSENCE.
In the preceding example, you can see that processing selected the last non-null value for DischargeDisposition from the first message but used the second, or last, message to populate all other death-related fields. Even though non-null values exist for C_Death_Source and Death_Date_Time, ESSENCE processes these values as null because they are null in the last message. This discrepancy in how death-related fields are populated can cause confusion when viewing records with a death mapping.
NSSP has marked these fields, and others with similar issues, for a potential change in data processing. We would appreciate input and will work with the community to determine if processing changes should be made.
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.
After receiving recommendations from the community, we created two new tabs: <Site>_Cells and <Site>_Cells_Red. Both tabs are located in the Data Quality Completeness Report to conveniently filter data by feed or facility and view Red cells only (cells with <90% completeness).
The <Site>_Cells tab includes everything in one report—from Overall ($All) and specific feed to facility-level data completeness. Use the Feed_Name column to filter on $All Feeds or on a specific feed.
Create feed-specific reports for vendors by simply filtering and copying data into a separate worksheet or new Excel file. You can also use the Priority field to filter on priority 1 fields and then filter on %visits to display cells highlighted in Red, which leads us to the next new tab.
The <Site>_Cells_Red tab opens a worksheet containing all Red highlighted cells found throughout the report. This tab is a one-stop shop for locating completeness issues at a glance. The worksheet includes Overall, specific feed, and specific facility-level information for all columns with <90% completeness. Use this new worksheet to identify potential problematic cells.
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.
Version 32 Now Available
The NSSP Data Dictionary has a new look and new information to go along with it. What changes can you expect to see?
With your help and eye for detail, the NSSP team identified several data quality issues. We investigated and resolved each. Then we updated the Data Dictionary processing description for data elements. A small sample of data elements with updated processing logic follows:
- ESSENCE Initial_Temp and Initial_Temp_Calc
- All combo fields
We also resolved discrepancies in the datatype/length specified in the Data Dictionary and updated content to align with the current data structure. To provide additional insight into data processing and make you aware of processing changes, we added three new tabs to the Data Dictionary:
Data Flow Enhancements Tab
Issues and resolution over time can be difficult to track because there are so many aspects to data processing and so many teams involved. To simplify the process, we compiled an audit table that details processing updates made to data elements. Within this table, you can find a description of the issue, the affected data elements, and the steps taken (or planned) to resolve the issue. We also included the logic and data changes for both NSSP and ESSENCE. The audit table will help you monitor the status of processing changes and patches to retrospective data (if applicable).
Shown above is an excerpt from the audit table.
Core Calculated Variables Tab
An NSSP calculated variable is defined as a variable computed via a formula during the processing from the Raw Table into the Processed Table; a calculated variable is not included in the raw message. On the Core Calculated Variables tab, you will find flow diagrams clarifying information on eight commonly-referenced NSSP calculated variables, including visual diagrams detailing how each variable is calculated.
Disposition Category Mapping Tab
In the past, there’s been some confusion about how ESSENCE determines Disposition Category. For those unfamiliar with how NSSP processes data to ESSENCE, the DischargeDisposition is mapped to a corresponding DispositionCategory in an ESSENCE reference table. The underlying data are stored in the format initially received in DischargeDisposition (usually disposition codes), and the mapped/formatted data are displayed in the DispositionCategory. The ESSENCE reference table is based on an original ESSENCE discharge disposition mapping table that NSSP expanded to include standard discharge disposition codes. To provide even more insight, we added a tab to the Data Dictionary that contains the reference table ESSENCE uses to do mapping.
Concatenated Facility Type (NSSP Processing Issue)
Thanks to the watchful eyes of a community member, the NSSP team has identified a defect in how Facility Type is processed. Per our Data Dictionary, NSSP is supposed to pull data from OBX-5.1 for facility-type observation messages and store the standard facility type code in facility_type_code. Similarly, for facility_type_description, NSSP is supposed to pull data from OBX-5.2 and store the standard facility type description in facility_type_description. However, the NSSP process is actually storing both the standard value and local value, concatenated, with a semicolon separator.
Unfortunately, this results in a nonstandard facility_type_code value (due to local code OBX-5.4 being concatenated), even though the message may have had a valid standard value in OBX-5.1. A similar issue applies to the facility_type_description. Further, because facility_type_code is nonstandard, the NSSP process cannot set the calculated patient class associated with the facility type (c_factype_patient_class).
Let’s look at an example. In the raw message shown below, you can see two pairs of coded elements for Facility Type:
Current processing logic concatenates the values in OBX-5.1 and OBX-5.4 with a semicolon to populate facility_type_code; similarly, the values in OBX-5.2, OBX-5.5, and OBX-5.9 are concatenated to populate facility_type_description. The raw message in this example would be processed as follows:
|261QE0002X;AQ.EROB||Emergency Care;ER UNSCHEDULED OB PATIENT;ER UNSCHEDULED OB PATIENT|
This current processing logic is incorrect. Only one value should exist for facility type code and facility type description. The repercussion from this defect is low (<1% of all records), but the NSSP team is working to correct this defect so that Facility Type is based on the standard value only. (Note. This defect has been documented in the Data Flow Enhancements tab of the Data Dictionary V32.)
Multiple OBXs Being Sent by the Facility
While investigating the defect in concatenated Facility Type, we discovered that a “concatenated facility type code” can also be attributed to messages that contain multiple OBX facility type segments. While this rarely occurs (<.01% of all records), we did want to bring it to your attention.
Per the Public Health Information Network (PHIN) Messaging Guide, Facility Type has a cardinality of 1..1, such that only one OBX segment is expected for Facility Type. If more than one OBX facility type segment is sent, the NSSP process will concatenate values “across the separate OBX segments,” as done with, for example, OBX chief complaint segments.
Therefore, if you have multiple OBX facility type segments that report only standard facility type, you may see values in facility_type_code that reflect <standard>;<standard>. Even though each OBX had a standard value, the resulting value in facility_type_code will be deemed non-standard.
Let’s look at another example:
The preceding raw message would be processed and stored in the Processed Table like so:
|261QM2500X;1021-5||Medical Specialty;Inpatient Care Setting|
PHIN standards do not allow multiple OBX facility type segments to be sent; therefore, NSSP has no plans now to correct the processing.
This article will give you ideas for using syndromic surveillance to improve reporting compliance and, perhaps, for curtailing cost and burden to patients receiving treatment for potential rabies exposure.
Using an Emergency Department Syndromic Surveillance System to Evaluate Reporting of Potential Rabies Exposures, Illinois, 2013–2015
The rabies virus is almost always fatal. Healthcare providers must follow clinical guidelines and quickly begin treating potential exposure with a regimen of rabies postexposure prophylaxis (PEP). If the regimen is not followed, illness, or even death, can occur.
Healthcare providers in Illinois are required to report potential rabies exposures and initiation of PEP. Despite this requirement, “errors in administration are common.”1 Errors, for example, can occur in the timing of vaccination series, the injection location, and even the need for PEP. Errors are costly for the healthcare system and patients alike. Treatment can exceed $3,000, and the regimen is inconvenient for patients.
This is an excellent article if you want a better understanding of reporting compliance for potential exposure to rabies. The authors turned to syndromic surveillance (SyS) because of its almost real-time nature and sought to identify errors in administering PEP before a patient completes the regimen, thus allowing time to make corrections.
This study queries emergency department (ED) records for 45 acute care hospitals in Cook County, Illinois, and nearby areas from January 1, 2013, through June 30, 2015. The authors examined chief complaints or discharge diagnoses for rabies, contact with specific mammals, and administration of postexposure prophylaxis. They looked at how many patients had more than one visit for potential exposure and compared these data to reported exposures and what appeared to be unreported exposures. They began active surveillance in July 2015 and ran an education campaign in August and September 2015 that used SyS data to inform multiple-component interventions. They reassessed reporting completeness from July 2015 through February 2016.
The authors’ findings before and after the intervention show underreporting of both potential rabies exposures and initiation of PEP—but, intervention increased reporting, which underscores the value of SyS data for estimating reporting compliance. The authors conclude that intervention that combines syndromic surveillance with hospital outreach shows promise for increasing reporting compliance. By using SyS to monitor the process for errors, local health officials can intervene when exposures are not being reported or make corrections before patients complete the regimen.
1Bemis K, Frias M, Toth Patel M, Christiansen D. Using an Emergency Department Syndromic Surveillance System to Evaluate Reporting of Potential Rabies Exposures, Illinois, 2013–2015. Public Health Reports [Internet]. 2017 July/August [cited 2018 Apr 9];132(1 Suppl). Available from: http://journals.sagepub.com/doi/full/10.1177/0033354917708355
The NSSP team continues to move the final few sites’ data from the legacy system to the NSSP BioSense Platform. There are no significant change to report since NSSP’s conversion of legacy data into production for 95% of the 43 remaining sites that had requested legacy migration.
Thank you for your continued patience throughout the legacy transition. If you have questions, please contact the NSSP Service Desk.
We are updating the Access & Management Center (AMC) to meet IT security requirements. The update is scheduled for May 2018 and will require that RStudio and Adminer users refresh their bookmarks for these applications.
We continue to work on the AMC Master Facility Tool and plan to deliver the first release this summer.
In March 2018, the NSSP team conducted a two-week SAS Studio Pilot with six sites. The purpose of the pilot was to evaluate SAS Studio before launching it to the BioSense Platform user community. The pilot evaluated the following:
- The functions of SAS Studio in the cloud environment
- Users’ comfort level with SAS Studio
- Performance of SAS Studio and DataMart servers
- Usefulness of BioSense Platform Quick Start Guide to Using SAS Studio
The six participants ran an NSSP-supplied set of SAS code on their data to test SAS Studio functions. They conducted two separate stress tests to evaluate the capacity of the SAS and DataMart. The code included different ways to access the SQL DataMart including SQL pass-through, SAS Proc SQL, and SAS Data Step. Participants gave feedback through an online survey and during conference calls.
The NSSP team monitored system performance throughout the stress tests. As a result, the pilot identified that most participants could set up SAS fairly easily and connect to the DataMart to explore their data. The SAS Studio server only reached 40% memory capacity, and the CPU usage was minimal. However, the SQL DataMart was challenged to perform due to jobs being performed internally. Additionally, the NSSP team observed performance issues with the file server that stored programs and output data.
Participants suggested ways to improve the organization of the Quick Start Guide by updating graphics to better delineate between home folders and global folders that are read only. They also asked that the NSSP team consider adding a SAS Studio redirect page for continuity across NSSP Platform tools and ease of access.
Next steps—In the coming weeks, the NSSP team will adjust the SQL settings on the DataMart to allocate more resources to ad-hoc queries and jobs, update the Quick Start Guide, purchase servers to increase capacity in the summer of 2018, and conduct another stress test with the pilot participants. The NSSP team continues to work to ensure that the tools on the platform will provide users with the best experience to conduct their analytic needs. For more information, please contact the NSSP Service Desk.
The NSSP is refining its definition of participation. Meanwhile, 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.
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.
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.
- Page last reviewed: May 9, 2018
- Page last updated: May 9, 2018
- Content source: