The Case of the Disappearing Diagnosis
Updated February 26, 2024
Event #1: Camille arrived to work on Monday after a busy previous week. An outdoor music festival drawing large crowds had taken place just outside downtown. Her job last week was to inform emergency preparedness colleagues of trends in local emergency department (ED) visits. Luckily, the event was tame—no excessive health events due to weather, substance use, or injury.
Details Camille noticed: The only unusual trend was a minor increase in ICD-10-CM Discharge Diagnosis codes for R50: Fever. With the event over, Camille planned to feature these visits for fever in her after-action report. She wanted to include updated Diagnosis codes with more details, but when she re-ran her query looking for codes starting with “R50,” she noticed that her interesting trends to spotlight had disappeared! The query she’d used last week returned at least 35 ED visits with fever; but now, that same query only showed 23 ED visits. Even more surprising, she noticed counts for the Alcohol- and Heat-related Illness categories had decreased. Why the disconnect? Did hospital staff change their input? Did she inadvertently change her query? How can she investigate where these missing visits went?
Event #2: Malik is working on an article for CDC’s Morbidity and Mortality Weekly Report. To complete the final submittal, all he needs to do is update the syndromic surveillance data tables with current data. He has been running the same query for what seems like months now, and he is very familiar with what the results should be.
Details Malik noticed: After running his query to update the data, Malik is met with a BIG surprise—one facility shows ZERO on his table summarizing weekly Pneumonia CCDD Category returns. Malik is confident that the facility should have a count of at least 30. To make matters more confusing, the facility counts for the previous week have DECREASED! But why? Why did the counts change since his previous data pull 2 weeks ago? Malik pores over the facility’s messages to examine the updates. Hopefully, he can use earlier messages to correct the counts for now; later, he will call the facility to resolve the issue and move forward.
Discharge Diagnosis: Examine the Process to Identify the Origin
During a patient visit, the medical provider captures the patient’s Admitting, Working, and Final Diagnosis in an electronic health record (EHR) and sends it to CDC’s National Syndromic Surveillance Program (NSSP). These HL7® ADT messages are sent with Diagnosis Code and Diagnosis Description (DG1.3.1 and DG1.3.2), written to the Processed table, and stored as distinct fields. Each full HL7® DG1.3 segment is also captured as a Diagnosis_Segment.
Examples:
- Diagnosis_Code (DG1.3.1): ;Z02.89;
- Diagnosis_Description (DG1.3.2): Encounter for other administrative examinations
- Diagnosis_Segment (DG1.3): Z02.89^Encounter for other administrative examinations^I10
NSSP business rules are set up to receive multiple diagnoses. Many data providers will only send the Final diagnosis, often including comorbid conditions in the diagnosis segment. A few data providers will send comorbid conditions in the Problem List (OBX.5) instead of the diagnosis segment.
From this, Diagnosis Code and Description are ingested into ESSENCE as DischargeDiagnosis. DischargeDiagnosis is populated from the most recent message containing a non-NULL value for the patient visit.
Note: If NSSP receives DischargeDiagnosis containing non-informative values, it is kept in the DischargeDiagnosis field but ignored as the last non-NULL. A non-informative value will never overwrite an informative value.
If a data provider submits a second DischargeDiagnosis for the same visit that is not one of the Non-informative Discharge Diagnosis (NIDD)* terms, it is updated in the DischargeDiagnosis field. If a third DischargeDiagnosis is submitted for the same ESSENCE ID and is one of the NIDD terms, then the DischargeDiagnosis field is not updated, and the second DischargeDiagnosis is kept.
Examples:
- Message 1 value: Unknown –> Unknown – DischargeDiagnosis
- Message 2 value: R06.02 –> R06.02 – DischargeDiagnosis
- Message 3 value: R06.02;J18.9 –> R06.02;J18.9 – DischargeDiagnosis
- Message 4 value: Unknown –> 02;J18.9 – DischargeDiagnosis
- NIDD terms* approved by the NSSP Community of Practice Technical Subcommittee: “”, null, unknown, unk, n/a, na, Chief complaint not present, ed visit, ed, er, Advice only, Other, xxx, Evaluation, Follow up, medical, illness, General, General symptom, EMS, AMR, Medic, Ambulance, EMS/Arrived by, EMS/Ambulance, ;, ;;, Triage, Triage peds, Triage-, Triage peds-, See chief complaint quote, See CC quote, Sick, Injury, ill, Eval, squad, Referral, Code 1, Code 3, follow-up
Last Non-Null Gone Wrong
As new messages for a visit are received and Discharge Diagnosis is updated from the new messages, sometimes the diagnosis segment (DG1) no longer includes all diagnoses from a visit and may only contain the most recent or most pertinent results. Provided these results are considered informative, the DischargeDiagnosis field in ESSENCE will be updated to include only the most recent non-null diagnosis. Over time, the ESSENCE query results may change. Here’s an approach you can use to investigate the issue:
- Check the Processed Table:
- Pull all messages for the visit in question and put in order by Message_Date_Time (MSH.7.1).
- Look at all messages for the visit with the last non-null diagnosis and confirm they match the DischargeDiagnosis in ESSENCE. Have some diagnosis codes been removed when compared to previously received messages?
- Check ESSENCE:
- For this visit, review the Discharge Diagnosis History (DischargeDiagnosisUpdates). Did a previously received DischargeDiagnosis as recorded in the Diagnosis History contain more diagnosis codes than the most recent DischargeDiagnosis?
- Discuss with the data provider:
- Is Admit, Working, and Final diagnosis being sent and updating the field as each is applied?
- When Final diagnosis is coded and sent, is the diagnosis updated? Or, has the previously sent diagnosis information been dropped, leaving only the Final diagnosis?
- Other questions or concerns that could shed light on the current logic used by the data sender.
The Resolution
Once you identify why DischargeDiagnosis changed, you’ll need to determine if all old and current diagnoses are accurate. If accurate, include them as part of the latest diagnosis update message. Often the quickest way to do this is by contacting the data sender and sharing examples from an impacted query. Be sure to include the Message_Control_ID for each example message, and ONLY include patient identifiers when sending the information securely. Although email may be preferred for initial discussions and notification, don’t hesitate to call the data sender and screen share!
* The term “NIDD” refers to Non-Informative Discharge Diagnosis. A non-informative term may have a non-null value, but the value itself may add negligible, if any, value to syndromic surveillance. For example, if a Discharge Diagnosis value is “unknown,” it is not informative. The list of non-informative terms for both Discharge Diagnosis and Chief Complaint are identical (see the NSSP Data Dictionary).
We thank Senior Data Analyst Sophia Crossen (CDC) for developing this series of whodunits. Crossen has considerable experience working with state data and often guides public health staff in troubleshooting and resolving technical issues.
