HL7 v2 DG1 Explained: Structure, Fields, and Common Mistakes
DG1 looks like a throwaway segment until a claims team calls asking why a patient shows three "final" diagnoses with no admitting diagnosis anywhere in the chart. The segment carries the clinical story that billing, quality reporting, and clinical decision support all lean on, and most of the damage happens in fields nobody bothers to validate.
DG1 (Diagnosis) is the repeating HL7 v2 segment that carries a patient's diagnosis codes, descriptions, and classification within ADT and other trigger events. A message can carry many DG1 segments — one admitting diagnosis, several working diagnoses, and a final diagnosis are common in a single encounter — so testing has to cover ordering, the DG1-6 type code, and whether the ICD code component actually resolves to a real code.
The fields that actually matter in practice
Example
A final diagnosis of type 2 diabetes, ranked as the patient's primary diagnosis. Every value here is synthetic.
Where this trips people up
Teams building test messages usually populate one DG1 with a tidy ICD-10 code and move on, then discover in production that real encounters send four or five DG1 repetitions with mixed admitting, working, and final types arriving out of order over the course of a stay. If your test data never exercises multiple DG1 repetitions with different DG1-6 values, you won't catch the bug where a receiving system overwrites the admitting diagnosis instead of appending a new one. It's also worth checking whether DG1-4 and the text component inside DG1-3 are allowed to disagree — some source systems populate them independently, and a naive parser that only reads one of the two will silently drop information the other field carried correctly.