Skip to content

Discharge Diagnosis Section

Template ID: 2.16.840.1.113883.10.20.22.2.24 Version: R2.1 (2015-08-01) / R2.0 (2014-06-09) Badge: Hospital Section

Overview

The Discharge Diagnosis Section represents problems or diagnoses present at the time of discharge that occurred during the hospitalization. This section documents the final clinical assessment of the patient's condition at discharge and includes diagnoses that require ongoing tracking or management after the patient leaves the hospital.

Clinical Purpose and Context

Discharge diagnoses documented in this section represent: - The primary and secondary diagnoses established during hospitalization - Conditions that occurred or were discovered during the hospital stay - Problems requiring ongoing management or follow-up after discharge - Final clinical assessment replacing or confirming admission diagnoses

Problems documented here should also be included in the Problems Section if they require ongoing tracking in the patient's longitudinal health record.

When to Include

The Discharge Diagnosis Section is a key component of: - Discharge Summaries (primary use case) - Transfer Summaries - Hospital Episode Documentation

This section is essential for continuity of care, helping receiving providers understand what conditions were addressed during hospitalization and what requires ongoing attention.

Template Details

Official OID

  • Root: 2.16.840.1.113883.10.20.22.2.24
  • Extension: 2015-08-01 (R2.1) or 2014-06-09 (R2.0)

Conformance Level

  • Conformance: SHALL (Required in Discharge Summary documents)
  • Section Code: 11535-2 (LOINC - "Hospital Discharge Diagnosis")
  • Translation Code: 78375-3 (LOINC - "Discharge Diagnosis")

Cardinality

  • Section: 0..1 (Optional but recommended)
  • Entries: 0..* (Hospital Discharge Diagnosis entries)
  • Hospital Discharge Diagnosis (V3): 2.16.840.1.113883.10.20.22.4.33:2015-08-01
  • Problem Observation (V4): 2.16.840.1.113883.10.20.22.4.4:2015-08-01

Protocol Requirements

The DischargeDiagnosisProtocol defines the data contract for discharge diagnosis entries. Each diagnosis must provide:

Required Properties

Property Type Description
name str Human-readable diagnosis name
code str SNOMED CT or ICD-10 diagnosis code
code_system str Code system: 'SNOMED' or 'ICD-10'
status str Diagnosis status: 'active', 'inactive', 'resolved'

Optional Properties

Property Type Description
diagnosis_date Optional[date] Date diagnosis was identified
resolved_date Optional[date] Date diagnosis was resolved
discharge_disposition Optional[str] Patient's discharge disposition
priority Optional[int] Priority ranking (1=primary diagnosis)

Data Types and Constraints

  • name: Clear, clinical description of the discharge diagnosis
  • code: Must be a valid SNOMED CT or ICD-10 code
  • code_system: 'SNOMED' (preferred) or 'ICD-10'
  • status: Most discharge diagnoses are 'active' (ongoing)
  • diagnosis_date: Date diagnosis was identified during hospitalization
  • priority: Lower numbers = higher priority (1 is primary diagnosis)

Code Example

Here's a complete working example using ccdakit to create a Discharge Diagnosis Section:

from datetime import date
from ccdakit.builders.sections.discharge_diagnosis import DischargeDiagnosisSection
from ccdakit.core.base import CDAVersion

# Define discharge diagnoses using a class that implements DischargeDiagnosisProtocol
class DischargeDiagnosis:
    def __init__(self, name, code, code_system, status, diagnosis_date=None,
                 resolved_date=None, priority=None):
        self._name = name
        self._code = code
        self._code_system = code_system
        self._status = status
        self._diagnosis_date = diagnosis_date
        self._resolved_date = resolved_date
        self._discharge_disposition = None
        self._priority = priority

    @property
    def name(self):
        return self._name

    @property
    def code(self):
        return self._code

    @property
    def code_system(self):
        return self._code_system

    @property
    def status(self):
        return self._status

    @property
    def diagnosis_date(self):
        return self._diagnosis_date

    @property
    def resolved_date(self):
        return self._resolved_date

    @property
    def discharge_disposition(self):
        return self._discharge_disposition

    @property
    def priority(self):
        return self._priority

# Create discharge diagnosis instances
diagnoses = [
    DischargeDiagnosis(
        name="ST Elevation Myocardial Infarction",
        code="401314000",
        code_system="SNOMED",
        status="active",
        diagnosis_date=date(2024, 10, 15),
        priority=1  # Primary diagnosis
    ),
    DischargeDiagnosis(
        name="Acute systolic heart failure",
        code="441481004",
        code_system="SNOMED",
        status="active",
        diagnosis_date=date(2024, 10, 16),
        priority=2  # Secondary diagnosis
    ),
    DischargeDiagnosis(
        name="Community acquired pneumonia",
        code="385093006",
        code_system="SNOMED",
        status="resolved",
        diagnosis_date=date(2024, 10, 15),
        resolved_date=date(2024, 10, 20),
        priority=3
    )
]

# Build the Discharge Diagnosis Section
section_builder = DischargeDiagnosisSection(
    diagnoses=diagnoses,
    title="Discharge Diagnosis",
    version=CDAVersion.R2_1
)

# Generate XML element
section_element = section_builder.build()

# Convert to XML string (for demonstration)
from lxml import etree
xml_string = etree.tostring(section_element, pretty_print=True, encoding='unicode')
print(xml_string)

Official Reference

For complete specification details, refer to the official HL7 C-CDA R2.1 documentation: - HL7 C-CDA R2.1 Implementation Guide - Section: Discharge Diagnosis Section (V3) - Conformance IDs: CONF:1198-7979 through CONF:1198-32836

Best Practices

Common Patterns

  1. Use Standard Vocabularies
  2. Prefer SNOMED CT for clinical interoperability
  3. ICD-10-CM codes are commonly used for billing purposes
  4. Consider including both if your system supports it

  5. Prioritize Diagnoses

  6. Use the priority field to rank diagnoses by clinical significance
  7. Priority 1 = Primary discharge diagnosis (most significant)
  8. Secondary diagnoses help tell the complete clinical story

  9. Track Diagnosis Status

  10. Most discharge diagnoses are 'active' (ongoing management needed)
  11. Mark diagnoses as 'resolved' if they were treated and resolved during hospitalization
  12. Include resolved_date for resolved diagnoses

  13. Coordinate with Problems Section

  14. Active discharge diagnoses should also appear in the Problems Section
  15. This ensures continuity in the patient's longitudinal health record
  16. Problems Section tracks ongoing conditions; this section documents the episode

Validation Tips

  1. Section Code Validation
  2. Ensure section code is 11535-2 (LOINC "Hospital Discharge Diagnosis")
  3. Must include translation code 78375-3 (LOINC "Discharge Diagnosis")
  4. Both codes are automatically set by the builder

  5. Template ID Validation

  6. Verify template ID includes appropriate extension for version
  7. R2.1: extension="2015-08-01"
  8. R2.0: extension="2014-06-09"

  9. Entry Structure Validation

  10. Entry contains Hospital Discharge Diagnosis Act (classCode="ACT")
  11. Act contains one or more Problem Observations via entryRelationship
  12. Each Problem Observation represents a specific diagnosis

  13. Status Consistency

  14. If status is 'resolved', resolved_date should be present
  15. If status is 'active', resolved_date should be absent
  16. Status drives the Act statusCode in the XML

Common Pitfalls

  1. Confusing with Admission Diagnosis
  2. Admission diagnoses represent initial assessment at admission
  3. Discharge diagnoses represent final assessment at discharge
  4. Both sections may be present in the same document

  5. Missing Status Information

  6. Always provide status field ('active', 'inactive', or 'resolved')
  7. Status is required and affects document interpretation
  8. Default to 'active' if diagnosis requires ongoing management

  9. Inconsistent Date Handling

  10. Diagnosis date should be during the hospitalization period
  11. Don't use future dates for diagnosis_date
  12. Resolved date must be after or equal to diagnosis date

  13. Empty Diagnosis List

  14. While technically optional, discharge diagnoses are expected
  15. If truly no diagnoses, include narrative explaining why
  16. Consider whether the document type requires diagnoses

  17. Priority Numbering Issues

  18. Lower numbers = higher priority (1 is most important)
  19. Don't skip numbers or use zero
  20. Priority is optional but recommended for clarity

  21. Not Synchronizing with Problems

  22. Active discharge diagnoses should appear in Problems Section
  23. This ensures they're tracked longitudinally
  24. Resolved diagnoses may not need to be in Problems Section
  • Admission Diagnosis Section: Documents diagnoses at admission
  • Problems Section: Tracks ongoing problems longitudinally
  • Hospital Course Section: Narrative describing the hospitalization
  • Procedures Section: Documents procedures performed during stay

Code Systems and Terminologies

Diagnosis Codes

  • SNOMED CT (Preferred): OID 2.16.840.1.113883.6.96
  • Provides detailed clinical semantics
  • Better for clinical decision support and interoperability

  • ICD-10-CM: OID 2.16.840.1.113883.6.90

  • Required for billing and administrative purposes
  • May be used alone or in addition to SNOMED CT

Section Codes

  • Primary: 11535-2 - "Hospital Discharge Diagnosis" (LOINC)
  • Translation: 78375-3 - "Discharge Diagnosis" (LOINC)

Status Value Set

  • Problem Status: 2.16.840.1.113883.3.88.12.80.68
  • active: Condition is ongoing
  • inactive: Condition is not currently active
  • resolved: Condition has been resolved

Implementation Notes

Narrative Generation

The builder automatically generates an HTML table with: - Diagnosis name (with content ID for referencing) - Code and code system - Status - Diagnosis date

Hospital Discharge Diagnosis Act

The section uses a special Act wrapper: - Acts as a container for related Problem Observations - Allows grouping multiple diagnoses from the same encounter - Typically one Act contains all discharge diagnoses

Diagnosis Priority

While not explicitly encoded in standard C-CDA templates, priority can be: - Documented in the narrative - Implied by order in the entry list - Captured in local extensions if needed

Integration with Problems Section

Best practice workflow: 1. Document discharge diagnoses in this section 2. Add active discharge diagnoses to Problems Section 3. Ensure consistent coding between sections 4. Use persistent IDs to link related observations

Discharge Disposition

The discharge_disposition property can capture: - "Home" - Patient discharged to home - "Skilled Nursing Facility" - Transferred to SNF - "Acute Care Hospital" - Transferred to another hospital - "Hospice" - Discharged to hospice care - This is optional but provides valuable context

Clinical Decision Support

Discharge diagnoses are critical for: - Quality measurement and reporting - Risk stratification - Care coordination - Follow-up care planning - Billing and reimbursement