The Case of the Missing Chief Complaint

The event

State epidemiologist Steven looked up from his daily “Lights On” report to see an email notifying him that an automated syndromic alert for “Exposure” had been tripped. This alert was from a large regional hospital, and notes from the hospital’s emergency department visits described chemicals, fumes, and the site of a large construction project. Later, news sources revealed that a large road crew had been overcome by fumes earlier that morning.

Was Steven capturing all the visits within this large regional hospital? Were other smaller hospitals close to the event receiving patients?

Details Steven noticed

The large hospital’s Chief Complaint completeness was poor the day of the event. This hospital often completed some Chief Complaint fields via the Chief_Complaint_Text and others via the Admit_Reason_Description if the Chief_Complaint_Text was blank. But today, apparently due to the influx of new patients, the facility staff had stopped completing the Admit_Reason_Description field.

The smaller hospital, located near the exposure event, historically showed thorough Chief Complaint completeness. Steven was faced with the unexpected task of depending on the smaller hospital’s data. Steven realized most of its Chief Complaints were populated with “Ambulance called ahead.” He would have to manually search Admit_Reason_Description for clues to get a true picture.

Chief Complaint: Identifying the origin

During a patient visit, the medical provider captures the reason for the patient seeking medical care in an electronic health record that is sent to CDC's National Syndromic Surveillance Program (NSSP). These HL7® ADT messages are sent as either an Admit_Reason_Description (PV2-3.[25]) or a Chief_Complaint_Text (OBX-5.1 or OBX-5.[259]). Messages are written to the Processed table and stored as distinct fields. Each full HL7® segment is also captured in Admit_Reason_Segment and Chief_Complaint_Segment.

For each message received, a new calculated field called C_Chief_Complaint is created when the message is written in the Processed table. This calculated field is first populated with the Chief_Complaint_Text, if available in that message, or the Admit_Reason_Description, if Chief_Complaint_Text is blank. If neither the Chief_Complaint_Text nor Admit_Reason_Description is available, then C_Chief_Complaint is left blank. C_Chief_Complaint has a companion field, C_Chief_Complaint_Source, that records which of the two fields was the source of C_Chief_Complaint for that message.

If you see in a visit-level completeness report that C_Chief_Complaint is 77% complete, you may also see Admit_Reason_Description of 55% and Chief_Complaint_Text of 66%. This makes sense because some visits can have Admit Reason and no Chief Complaint, whereas others may have Chief Complaint and no Admit Reason.

During ESSENCE ingestion—as all messages are collapsed into a single record per visit—ESSENCE creates a new field called ChiefComplaintOrig and populates it with the first non-null C_Chief_Complaint received for that visit. If the first non-null C_Chief_Complaint is not considered "informative" by the BioSense Platform business rules (not to be confused with the Non-Informative Chief Complaint [NICC] list), it will be replaced by the first non-null C_Chief_Complaint that is "informative," providing one is received. (The current list of non-informative chief complaints is available in the NSSP Data Dictionary.) ESSENCE will also create another field upon ingestion called CCInformative, which is an indicator value to show if ChiefComplaintOrig is informative based on the NICC terms.

Where completeness can go wrong

When Chief Complaint has low completeness by visit, you can review several areas to look for the root cause. Here are some suggestions:

• Confirm with the data sender that Admit_Reason_Description or Chief_Complaint_Text are being populated. Reviewing with the data sender that the field(s) are being populated as expected is a good way to start.
• If the volume of visits with CCInformative is low, confirm that all C_Chief_Complaints are not Non-Informative by comparing with the current list located in the NSSP Data Dictionary.
• Confirm that the HL7® messages are formatted correctly so that they can be ingested as expected. A properly formatted PV2 and OBX are required for the free-text fields to be ingested.

Formatting examples

Let's look at these examples of good and bad HL7® message formatting.

Admit Reason PV2-3

GOOD:

• PV2|||^Diabetes Mellitus
• PV2|||O24.4^Diabetes Mellitus arising in pregnancy^I10

BAD:

• PV2|||Diabetes Mellitus

Why it doesn't work: This text will be stored as Admit_Reason_Code instead of Admit_Reason_Description. Only text in PV2.3.2 is recorded for Admit_Reason_Description.

• PV2|||O24.4

Why it doesn't work: This text will be stored as Admit_Reason_Code. No text has been provided for Admit_Reason_Description. Only text in PV2.3.2 is recorded for Admit_Reason_Description.

Chief Complaint OBX

GOOD:

• OBX|3|TX|8661-1^CHIEF COMPLAINT – REPORTED^LN||STOMACH ACHE THAT HAS LASTED 2 DAYS; NAUSEA AND VOMITING; MAYBE A FEVER||||||F|||201102171531

BAD:

• OBX|3|CWE|8661-1^CHIEF COMPLAINT – REPORTED^LN||STOMACH ACHE THAT HAS LASTED 2 DAYS; NAUSEA AND VOMITING; MAYBE A FEVER||||||F|||201102171531

Why it doesn't work: If OBX-2 is 'CWE', only OBX.5.[259] will be captured for Chief_Complaint_Text. OBX-2 should be 'TX' to capture free text in the OBX.5.1.

• OBX|3|TX|8661-1^CHIEF COMPLAINT – REPORTED^LN||^^^^^^^^STOMACH ACHE THAT HAS LASTED 2 DAYS; NAUSEA AND VOMITING; MAYBE A FEVER||||||F|||201102171531

Why it doesn't work: If OBX-3 is 'TX', only OBX-5.1 will be captured for Chief_Complaint_Text. EITHER:

1. OBX.2 should be CWE to capture free text in the OBX.5.9, or
2. OBX.5 should have all delimiters (^) removed so that the free text is in OBX-5.1 (This is the preferred solution, especially when the Chief Complaint is not coded.)

Additional tip

A good method for checking message format is to see if Admit_Reason_Segment or Chief_Complaint_Segment is populated in the processed table while Admit_Reason_Description or Chief_Complaint_Text is null.

The Resolution

Once you identify the source of low C_Chief_Complaint completeness, you'll need to fix the issue. Most often, the quickest way to do this is to contact the data sender and share examples1 from recently received data. Be sure to include Message_Control_ID for each example message, and only include patient identifiers if 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!

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.

HL7®, and FHIR® are the registered trademarks of Health Level Seven International and their use of these trademarks does not constitute an endorsement by HL7.