HL7 DG1 Diagnosis
HL7 field reference DG1 fields from HL7 v2.5.1 Show fields
These are the generated fields for the version selected at the top of the page. The document stays the same, but the reference panel follows that version.
Fields
| Field | Name | Required | Repeatable | Type | Table |
|---|---|---|---|---|---|
| DG1.1 | Set ID - DG1 | Yes | No | SI | |
| DG1.2 | Diagnosis Coding Method | No | No | ID | 0053 |
| DG1.3 | Diagnosis Code - DG1 | No | No | CE | 0051 |
| DG1.4 | Diagnosis Description | No | No | ST | |
| DG1.5 | Diagnosis Date/Time | No | No | TS | |
| DG1.6 | Diagnosis Type | Yes | No | IS | 0052 |
| DG1.7 | Major Diagnostic Category | No | No | CE | 0118 |
| DG1.8 | Diagnostic Related Group | No | No | CE | 0055 |
| DG1.9 | DRG Approval Indicator | No | No | ID | 0136 |
| DG1.10 | DRG Grouper Review Code | No | No | IS | 0056 |
| DG1.11 | Outlier Type | No | No | CE | 0083 |
| DG1.12 | Outlier Days | No | No | NM | |
| DG1.13 | Outlier Cost | No | No | CP | |
| DG1.14 | Grouper Version And Type | No | No | ST | |
| DG1.15 | Diagnosis Priority | No | No | ID | 0359 |
| DG1.16 | Diagnosing Clinician | No | Yes | XCN | |
| DG1.17 | Diagnosis Classification | No | No | IS | 0228 |
| DG1.18 | Confidential Indicator | No | No | ID | 0136 |
| DG1.19 | Attestation Date/Time | No | No | TS | |
| DG1.20 | Diagnosis Identifier | No | No | EI | |
| DG1.21 | Diagnosis Action Code | No | No | ID | 0206 |
DG1 is the diagnosis segment. It carries diagnosis information around a patient, visit, order, account, charge, or update event. You will see it in ADT messages when a patient is admitted, updated, or discharged. You will see it in order messages when the order needs a diagnosis or reason attached to it. You will see it in billing and account messages when the receiving system needs more diagnosis detail than an FT1 charge line can comfortably hold.
The important thing is that DG1 is coded diagnosis context. It is not the whole clinical problem list, and it is not the same thing as every note a clinician has ever written about the patient. HL7 even calls out that DG1 diagnosis coding should be distinguished from the clinical problem segment used by caregivers. In plain English: DG1 is usually the administrative, order, billing, or encounter-facing diagnosis view, not a rich longitudinal problem-management model.
The fields that really matter are a small handful: DG1-3 for the diagnosis code, DG1-4 for description or legacy text, DG1-5 for when the diagnosis was determined, DG1-6 for whether it is admitting, working, or final, DG1-15 for the priority or ranking, and DG1-16 for the clinician responsible for the diagnosis. If you are dealing with update-style diagnosis messages, DG1-20 and DG1-21 suddenly become very important as well.
First, think in diagnosis workflows
The ADT pattern is the one most people meet first. A patient arrives with an admitting diagnosis, maybe something broad like chest pain, abdominal pain, fever, or injury. During the stay there may be a working diagnosis as the clinical picture changes. At discharge, the final diagnosis is sent and that final coded diagnosis may feed records, quality reporting, billing, and downstream care summaries. DG1-6 is what tells you which stage you are looking at.
The billing pattern is more exacting. Diagnosis codes support claims, reimbursement, medical necessity, DRG grouping, and sometimes charge routing. In that world, DG1-15 matters because one diagnosis is primary or principal and the rest are ranked secondary diagnoses. A wrong primary diagnosis can change the whole downstream billing story, even if every code is technically valid. In Integration Soup, this is the sort of mapping I like to make explicit and logged: local diagnosis code in, agreed billing or reporting code out, with the original value still visible for audit.
Order and referral messages use DG1 a little differently. A lab order might include the ICD-10 diagnosis that justifies the test. A radiology order might carry the diagnosis or clinical indication associated with the study, although some profiles prefer OBR-31 Reason for Study for that job. The practical rule is simple: follow the receiver's implementation guide, because "reason for order" and "coded diagnosis" are close cousins, not identical twins.
Then there is the DRG and update-message side of DG1. DG1-7 to DG1-14 are older DRG and outlier fields that later HL7 material deprecates or moves into the DRG segment, but v2.5.1 systems can still carry them. DG1-20 and DG1-21 are the opposite: quiet in ordinary snapshot messages, but essential when a BAR P12-style update says "add this diagnosis", "update this diagnosis", or "delete this diagnosis".
So let's go through each of the DG1 fields and talk about how they tend to behave in real interfaces.
This is the sequence number for the DG1 segment. If a message sends three diagnoses, you normally see 1, 2, and 3. It helps preserve the order in the message and makes the repeated segments easier for humans to read.
It is not the diagnosis identifier. Do not use it to decide that this is the same diagnosis as the second DG1 from yesterday's message. If the sender is giving you a full replacement list, sequence is fine as a display aid. If the sender is giving you updates, use DG1-20 for the diagnosis instance and DG1-21 for the action.
This field comes from an older way of thinking about the coding system. In the local v2.5.1 table it only lists I9 for ICD-9, which tells you a lot about the age of the field. Modern real-world messages are more likely to put the coding system directly in DG1-3.3, such as I10 for ICD-10, SCT for SNOMED CT, or L for a local code.
If a legacy receiver expects DG1-2, populate it according to that receiver's guide. Otherwise I would not make it the source of truth. The cleaner pattern is to send a proper coded element in DG1-3 with code, display text, and coding system all together. That way each diagnosis repeat explains itself.
This is the main event. DG1-3 is where the coded diagnosis goes: J18.9^Pneumonia, unspecified organism^I10, R50.9^Fever, unspecified^I10, or 16932000^Nausea and vomiting^SCT. The first component is the code, the second is the human-readable description, and the third tells the receiver which code system that code belongs to.
ICD-10-CM is the workhorse in a lot of billing, ADT, laboratory order, and public-health-adjacent feeds. SNOMED CT turns up when the diagnosis is closer to a clinical finding or when a guide supports SNOMED disease/disorder values. Local codes are fine when both systems have agreed the table, but they are much harder to reuse outside that trading partner. If you send a local code, send the local coding system identifier and do not pretend it is ICD-10 just because that makes a validation error go away.
Be careful with formatting. Some systems include ICD-10 decimal points, some strip them, and some guides are strict about one style. Preserve leading zeros and punctuation unless your implementation guide says otherwise. Also avoid using one vague code for everything and putting the real meaning in DG1-4. A receiver can map, rank, bill, and report a coded diagnosis far more safely than a free-text sentence.
This is a text diagnosis description. It is useful in older interfaces and in feeds where the sender genuinely cannot supply a coded diagnosis. You will also see it as a display fallback next to DG1-3. The catch is that later HL7 material deprecates this field, and many modern guides either exclude it or expect the description to live in DG1-3.2 instead.
If DG1-3 is populated, keep DG1-4 consistent with it or leave it empty. Do not send J18.9^Pneumonia... in DG1-3 and then put "asthma review" in DG1-4. The receiver will not know which one to trust. If all you have is free text, DG1-4 may be the best you can do, but document that it is uncoded.
This is when the diagnosis was determined. It is not the message time, not the admission time, not necessarily the onset date, and not automatically the discharge time. For a final diagnosis, some guides treat it as desirable because it tells the receiver when the diagnosis became established.
In ADT updates, this can help tell the story of a diagnosis evolving from admitting to working to final. In order messages, it may simply be the date the order diagnosis was recorded. If you only know the date, send the date precision you actually know. Do not invent a midnight timestamp just to make the field look complete.
This required field tells the receiver what kind of diagnosis is being sent. In v2.5.1 the usual values are A for admitting, W for working, and F for final. That tiny one-letter value changes the meaning of the whole segment.
An admitting diagnosis is the reason or suspected diagnosis at the start of the encounter. A working diagnosis is the current clinical thinking while the encounter is still underway. A final diagnosis is the confirmed or coded diagnosis after the workup or at discharge. A patient can arrive with chest pain, move through a working diagnosis of myocardial infarction, and leave with a very specific final diagnosis. Treating all three as interchangeable is how you end up with messy history, wrong billing, and confusing clinical displays.
Do not use this field to mean DRG. HL7's later notes are clear that DG1-6 should not be used to indicate DRG because the DRG-specific information belongs elsewhere. If you see old local values, map them carefully and write down what they mean.
This block is all about diagnosis grouping and reimbursement: major diagnostic category, diagnostic related group, DRG approval, grouper review, outlier type, outlier days, outlier cost, and the grouper version. In older inpatient billing workflows, those values may help explain how an encounter was grouped and paid.
For modern integrations, be cautious. Later HL7 material deprecates these DG1 DRG fields and moves the detail toward the DRG segment. Some v2.5.1 feeds still use them because the receiving billing system expects them, and that is a perfectly practical reason. But do not populate this block just because it is sitting there in the segment definition. DRG and outlier data should come from the grouper or billing system that actually owns it.
If you do use the outlier fields, keep the pairings straight. DG1-11 tells you whether the outlier is cost or days, DG1-12 carries outlier days, and DG1-13 carries outlier cost. DG1-14 should identify the grouper version/type well enough that someone can understand how the classification was produced later.
This is the ranking field. 1 means the primary or principal diagnosis. 2 and higher are ranked secondary diagnoses. 0 means the diagnosis is not included in the ranking. In practice, if the message has diagnosis ranking, this field is much more meaningful than the order of the DG1 segments.
Only one diagnosis should be primary in a normal ranked set. In billing and DRG workflows, the primary diagnosis can drive reimbursement and medical necessity. In order messages, it may identify the main reason the test or referral is being requested. Either way, do not casually assign every DG1 a priority of 1 because each one feels important. That turns ranking into noise.
This field names the clinician responsible for generating the diagnosis information. It uses XCN, so send a proper identifier, name, assigning authority, and identifier type when you have them. A value like 277^Allen^Katrina^^^^^^^NPI is much more useful than a plain-text display name.
Do not assume this is the same as the attending doctor in PV1-7, the ordering provider in OBR-16, or the person who typed the message. Sometimes it is the same person, sometimes it is a coder, consultant, discharging doctor, or system account. If the sender does not actually know who diagnosed the condition, be honest about that rather than filling this with the nearest doctor-shaped value.
This classifies what sort of code or diagnosis information is being sent. The v2.5.1 values include diagnosis, sign and symptom, consultation, medication, tissue diagnosis, radiological scheduling, invasive procedure not elsewhere classified, and other.
You mostly see this when DG1 is being stretched beyond a neat final ICD diagnosis. For example, an order might carry a symptom or radiology scheduling reason rather than a confirmed diagnosis. If the receiver uses DG1-17, it can avoid treating every code as the same kind of clinical statement. If the receiver does not use it, keep the main diagnosis code and type as clear as possible.
This yes/no flag says whether the diagnosis is confidential. It can matter for mental health, substance use, sexual health, reproductive care, HIV, family violence, celebrity/privacy cases, and plenty of local policy situations where a diagnosis should not be visible to every downstream user.
Do not drop it just because most messages leave it empty. At the same time, do not pretend this one field is a complete privacy system. It is a signal that the receiver must understand and enforce. If the receiving application cannot restrict diagnosis visibility, that needs to be known before the feed goes live.
Attestation date/time is when the diagnosis was signed or attested. That is different from DG1-5, which is when the diagnosis was determined. In coding, discharge, and medical-record workflows, the distinction can matter because a diagnosis may be known clinically before it is formally attested.
This field is often empty in ordinary ADT and order feeds. When it is populated, preserve it with the diagnosis rather than replacing it with the message timestamp. It is part of the audit trail around who stood behind the diagnosis and when.
This is the stable identifier for a single diagnosis instance in an encounter. It is not the ICD code. Two different diagnosis instances can have the same ICD code, and one diagnosis instance can be corrected or updated over time. DG1-20 is the handle that lets a receiver know which specific diagnosis record is being discussed.
It becomes essential in update diagnosis/procedure messages such as BAR P12, where the sender is not merely resending a complete list but telling the receiver to apply a change. Use an EI value with a meaningful namespace or assigning authority where you can, such as DX-7788^CITYHOSP. Without a stable identifier, "update the pneumonia diagnosis" becomes guesswork.
The action code says what should be done with this diagnosis: A add or insert, U update, D delete, and X no change. In P12-style update messages, this is required because the whole point of the message is to apply diagnosis and procedure changes.
Be careful using action codes in ordinary ADT snapshot feeds. If the message is intended as a full current list, the receiver may not want to treat every diagnosis as an add. If the message is intended as a patch, DG1-20 and DG1-21 need to be populated together. Deletes are especially important to agree on: does D remove the record, mark it entered in error, retire it from the encounter, or suppress it from display? That is not a field-level question. That is an interface contract question.