NNDSS Implementation Spreadsheet Training Videos
These training videos guide public health agencies through the process of using the NNDSS Implementation Spreadsheet (visit specific MMG page to access).
The first part provides an overview on the implementation spreadsheet (IS).
The second part provides guidance on how to leverage the IS when completing the gap analysis.
Links referenced in the video:
NBS Central: NBS Central
Question Submission Form: https://app.smartsheet.com/b/form/b199f9fac3a24b53bfee7314d064417b
Slides:
Transcript:
Implementation Spreadsheet Overview
In this short video, we’ll cover the NNDSS implementation spreadsheet: what it is and how to find it, how to navigate the spreadsheet, and how to use it to complete the gap analysis. We’ll also cover what’s involved in APHL’s review of the gap analysis. Please note that the tools and processes covered in this video are primarily geared toward non-NBS jurisdictions. While NBS jurisdictions may find this information useful, they should follow the link on Confluence to access NBS-specific documents.
The NNDSS Implementation Spreadsheet combines multiple resources needed to construct the HL7 case notification message into a single document. These include the PHIN Messaging Specification for Case Notification, Generic V2 Message Mapping Guide (also known as MMG) data elements, and condition-specific MMG data elements. It also allows jurisdictions to enter information about their local case report forms, surveillance system data elements, and any mappings or translations needed to generate the HL7 message.
The primary use of the implementation spreadsheet is to complete the gap analysis, which we’ll cover later in the video. It can also be used by IT implementers in your jurisdiction, serving as the underlying structure for the integration engine and providing mappings from local to standard data elements and links to defined value sets. Once you’ve implemented an MMG, the implementation spreadsheet can serve as a record for system documentation if you need to go back and reference it later. Similarly, this is a record for the CDC of what your jurisdiction plans to send.
Within the MMG implementation process, the implementation spreadsheet sits between the information in a jurisdiction’s surveillance system and the HL7 message sent to CDC.
Now let’s see how to find the most recent implementation spreadsheets.
All message mapping guides and associated documents can be found on the CDC website in the NNDSS Technical Resource Center. Start by selecting the MMG that you want to implement. We’ll look at the Lyme and Tickborne Rickettsial Diseases (TBRD) MMG.
Each MMG page lists the current guide and related artifacts, including the implementation spreadsheet, test message package, and a link to the PHIN VADS value sets. Any past and historical versions of the guides and artifacts are listed below. Make sure to download the current version of the implementation spreadsheet before starting your gap analysis. Now, let’s take a closer look at the implementation spreadsheet itself.
The first tab is the ReadMe tab, which includes a description of the implementation spreadsheet, how it’s used, and instructions for completing the gap analysis. Each subsequent tab is defined here, as well as column descriptions for the MMG and Datatypes tabs.
The Revision Log tab shows a detailed history of revisions to the implementation spreadsheet. It also lists which versions of the PHIN messaging specification, GenV2, and condition-specific MMGs it corresponds to. Here, for example, we see that this implementation spreadsheet is based on version 3.1 of the PHIN messaging specification, version 2.0.1 of the GenV2 MMG, and version 1.0.2 of the Lyme/TBRD MMG.
The second tab is named for the MMG you’re working with, in this case, Lyme and TBRD. It includes all the data elements and metadata needed to construct an HL7 case notification message. Let’s review some of the columns you’ll want to focus on. Please note that some of the screenshots you’ll see going forward have rows and columns of the spreadsheet hidden to show only the most relevant parts of what we want to cover.
The Condition column tells you which condition the data element is for. All condition-specific MMGs include the GenV2 data elements since they are necessary to build a complete case notification message. If the MMG contains more than one condition with separate data elements, such as the one we see here, this column will specify the condition the data element applies to.
Data Element (DE) Identifier Sent in HL7 Message is either the location of the data element within an HL7 message, such as MSH-21 or PID-10, or the standard code that should be sent in OBX-3.1 of an OBX segment.
For data elements sent as OBX segments, the Data Element (DE) Name is the code description that should be sent in OBX-3.2.
The Repeating Group Element and OBX-5 values MAY repeat columns sound similar but are implemented differently in the HL7 message. If the Repeating Group Element field is populated with YES, PRIMARY/PARENT, or CHILD, then the entire OBX segment may be sent multiple times in the message as part of a group of elements linked together using OBX-4. If the element is labeled as the PRIMARY/PARENT, it must be sent within each repeating group. You can also use the Repeating Block column to see which data elements are grouped in repeating blocks. If the OBX-5 values MAY repeat field is populated with a Y, then for that single OBX segment, multiple values may be sent in OBX-5, separated by a tilde. Let’s look at an example of each.
Take the repeating group we saw on the last slide for Clinical Manifestations. This group contains two data elements, INV929 for the clinical manifestation and INV930 for indicating whether or not the clinical manifestation is present. Remember that OBX-4 must be populated for repeating group segments. This value is used to link different segments of the same instance of the repeating group together. So, in this example, we see that the patient did have Bell’s palsy and did not have encephalitis. The repeating element we saw on the last slide was for Type of Complication. In this example, the patient experienced two complications, both sent in OBX-5: acute respiratory distress syndrome and organ failure.
The Value Set Name (VADS Hyperlink) column links to PHINVADS for all coded data elements. For example, clicking on the Sex link opens the corresponding Sex value set in a web browser.
And finally, the CDC Priority column specifies the CDC surveillance programs’ prioritization of each data element. A small number of data elements are “R,” or strictly required. HL7 messages that do not contain these required data elements will be rejected. Priority 1 are highest priority elements and are critical for national surveillance. Priority 2 data elements are high priority and support national surveillance. Priority 3 data elements are lower priority and should be included in the HL7 message if they’re already being collected in your jurisdiction’s surveillance system.
You may notice that some columns are hidden by default. These grey-shaded columns contain metadata about each data element, such as HL7 implementation notes, the data type, cardinality, and a sample segment. Clicking on the data type in the HL7 Data Type column takes you to the Datatypes tab, which contains detailed information from the PHIN Messaging Specification on each data type. These columns may be helpful for more technical resources in your jurisdiction.
Completing the Gap Analysis
The purpose of the gap analysis is to compare the data elements in your system with those in the MMG to identify and resolve any potential data gaps. Let’s look at the remaining columns in the implementation spreadsheet, which you’ll use to complete the gap analysis.
The gap analysis must be completed before onboarding an MMG. As shown on the screen, Columns AA through AK are the columns used to complete the gap analysis. Column AA must be completed for all data elements using the drop-down provided.
If you select “only certain conditions” for a data element, you must populate column AB with any applicable notes. Columns AC through AJ can be populated if it’s helpful for your jurisdiction to document any mappings or translations that may be needed. Some CDC programs require that these columns be populated, so we recommend that you complete them as much as possible. Column AK needs to be completed for any priority 1 or 2 data elements that the PHA is not collecting and will not be sending to CDC. In other words, if column AA is ‘No’ for a priority 1 or 2 data element, then column AK should be completed. Some examples of responses in this column could include a proposed date on which you plan to add the data element to your system or will re-evaluate adding the data element or comments about not being able to collect the data element due to resource or other constraints.
Let’s look at a fictitious example of a completed implementation spreadsheet. The PHA Collected column has been completed for all data elements. Since the subject’s sex is only collected for certain conditions, an additional note is provided in the PHA Notes on Collection column. The jurisdiction has also noted two data elements that will be added to the system and when they expect them to be added. The mapping columns have been completed for all collected data elements. And justifications have been added for the two priority 2 data elements that are not collected.
The APHL TA team reviews all implementation spreadsheets, whether you’re receiving TA as part of a cohort or if you submitted your onboarding package directly to the CDC. We will confirm that all data elements have a value populated in the required columns. If you include any local data element mappings, we’ll review those to make sure they align with the CDC data element. This review and feedback is often an iterative process, with several back-and-forth submissions between APHL and the jurisdiction. Once the spreadsheet is clean, we’ll send it to the CDC program for their review. We’ll also do a final check of the implementation spreadsheet against your submitted test messages and test case scenario worksheet to ensure all onboarding documents are aligned.
If you have any questions about the implementation spreadsheet or completing the gap analysis, feel free to bring them to a cohort call or complete the Question Submission Form, linked* on this page.