HL7 DRG Diagnosis Related Group
HL7 field reference DRG 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 |
|---|---|---|---|---|---|
| DRG.1 | Diagnostic Related Group | No | No | CE | 0055 |
| DRG.2 | DRG Assigned Date/Time | No | No | TS | |
| DRG.3 | DRG Approval Indicator | No | No | ID | 0136 |
| DRG.4 | DRG Grouper Review Code | No | No | IS | 0056 |
| DRG.5 | Outlier Type | No | No | CE | 0083 |
| DRG.6 | Outlier Days | No | No | NM | |
| DRG.7 | Outlier Cost | No | No | CP | |
| DRG.8 | DRG Payor | No | No | IS | 0229 |
| DRG.9 | Outlier Reimbursement | No | No | CP | |
| DRG.10 | Confidential Indicator | No | No | ID | 0136 |
| DRG.11 | DRG Transfer Type | No | No | IS | 0415 |
DRG carries diagnosis-related grouping information used by billing, reimbursement, and patient-administration systems.
The standard describes DRG this way: The DRG segment contains diagnoses-related grouping information of various types. The DRG segment is used to send the DRG information, for example, for billing and medical records encoding.
Patient-administration segments add detail around the person, visit, account, diagnosis, procedure, insurance, merge, death, disability, and grouping state carried by the message.
These fields often drive matching, billing, encounter routing, reporting, and front-desk workflow. Separate patient identity, visit identity, account identity, and clinical facts carefully.
The v2.5.1 structures show DRG in ADR_A19 - Patient query, ADT_A01 - Admit/visit notification, ADT_A03 - Discharge/end visit, and ADT_A05 - Pre-admit a patient, and 14 other message structures. That tells you where it can appear, but the implementation guide still decides which optional fields are meaningful.
For practical interface work, read the generated field panel for datatype, required, repeatable, and table details, then use the notes below to decide what the field should mean in the receiving workflow.
DRG-1 carries Diagnostic Related Group for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0055; many real interfaces narrow that list further, so follow the receiver's implementation guide.
DRG-2 is a timing field. Send the real source-system precision, do not pad unknown dates or times, and agree how timezone offsets are handled when time of day matters.
DRG-3 tells the receiver the state of this patient-administration workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
DRG-4 identifies the DRG Grouper Review Code for this patient-administration workflow. Send the identifier that the receiving system actually keys on, and keep the assigning authority or coding system visible when the datatype supports it.
The generated panel links this to HL7 table 0056; many real interfaces narrow that list further, so follow the receiver's implementation guide.
DRG-5 qualifies the patient-administration workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0083. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
DRG-6 carries Outlier Days for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
DRG-7 carries a measured, counted, priced, or dosed value. A number without the expected unit, currency, or companion qualifier is much easier to misread than an empty field.
DRG-8 carries DRG Payor for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
The generated panel links this to HL7 table 0229; many real interfaces narrow that list further, so follow the receiver's implementation guide.
DRG-9 carries Outlier Reimbursement for this patient-administration workflow. Populate it only when the receiver has a clear use for it, and keep the value in the datatype shape shown in the generated field panel.
DRG-10 tells the receiver the state of this patient-administration workflow. Status fields often drive workflow branches, so use the agreed code and do not infer a status just because another field looks complete.
The coded value should follow HL7 table 0136 or the narrower table in the local profile.
DRG-11 qualifies the patient-administration workflow rather than identifying it. This is the sort of field receivers often use for branching, filtering, or display grouping.
Use the agreed value set, starting from HL7 table 0415. A local code without an agreed coding system is a small ambiguity that becomes a mapping problem later.
Related links
- PID - Patient Identification
- PD1 - Patient Additional Demographic
- PV1 - Patient Visit
- PV2 - Patient Visit - Additional Information
- DG1 - Diagnosis
- PR1 - Procedures
- IN1 - Insurance
- IN2 - Insurance Additional Information
- IN3 - Insurance Additional Information, Certification
- MRG - Merge Patient Information