Generated Narrative: StructureDefinition EHDSDischargeReportObligations Language: en Name Flags Card. Type Description & Constraints EHDSDischargeReport 0..* EHDSDischargeReport Discharge Report model #xD; header O 1..1 Base Document header Obligations Actor SHALL:able-to-populate Producer SHALL:process Consumer #xD; subject O 1..1 EHDSPatient Patient/subject information Obligations Actor SHALL:able-to-populate Producer SHALL:display Consumer SHALL:process Consumer #xD; identifier O 1..* Identifier Unique identifier of the document Obligations Actor SHALL:able-to-populate Producer SHOULD:display Consumer SHALL:process Consumer #xD; author[x] O 1..* EHDSHealthProfessional, EHDSOrganisation, EHDSDevice The author of the report. Obligations Actor SHALL:able-to-populate Producer SHALL:display Consumer #xD; date O 1..1 dateTime Date of finalising/issuing the document Obligations Actor SHALL:able-to-populate Producer SHALL:display Consumer #xD; status O 1..1 CodeableConcept Status of the document Obligations Actor SHALL:able-to-populate Producer SHALL:display Consumer #xD; language O 0..1 CodeableConcept Language in which the resource is written. Language is expressed by the IETF language tag. Obligations Actor SHALL:able-to-populate Producer #xD; documentType O 1..1 CodeableConcept Type of the document (e.g. '34105-7 Hospital discharge summary) Obligations Actor SHALL:able-to-populate Producer #xD; documentTitle O 1..1 string Title of the document, possibly autogenerated from the structured fields (e.g. 'Hospital discharge report. Jane Green. 07.10.2025-10.10.2025') Obligations Actor SHALL:able-to-populate Producer #xD; period O 0..1 Period Time of service that is being documented (typically the same as the time/period of encounter) Obligations Actor SHALL:able-to-populate Producer #xD; attestation O 0..* Base Document attestation details Obligations Actor SHALL:able-to-populate Producer SHALL:display Consumer #xD; attester[x] O 1..1 EHDSHealthProfessional, EHDSDevice Attester who validated the document Obligations Actor SHALL:able-to-populate Producer SHALL:display Consumer #xD; datetime O 1..1 dateTime Date and time of the approval of the document by Attester Obligations Actor SHALL:able-to-populate Producer #xD; legalAuthentication O 0..* Base Document legal authentication details Obligations Actor SHALL:able-to-populate Producer #xD; legalAuthenticator[x] O 1..1 EHDSHealthProfessional, EHDSOrganisation The person or organisation taking responsibility for the content of the document. Obligations Actor SHALL:able-to-populate Producer #xD; datetime O 1..1 dateTime Date and time when the document was authorised Obligations Actor SHALL:able-to-populate Producer #xD; eventType O 0..* CodeableConcept Categorisation of the event covered by the document (e.g. laboratory study types, imaging study types including modality, etc.). Selection of such tags or labels depends on the use case and agreement between data sharing parties. This meta-data element serves primarily for searching and filtering purposes. Obligations Actor SHALL:able-to-populate Producer #xD; serviceSpecialty O 0..* CodeableConcept Additional details about where the content was created (e.g. clinical specialty) Obligations Actor SHALL:able-to-populate Producer SHOULD:display Consumer #xD; custodian O 0..1 EHDSOrganisation Organisation that is in charge of maintaining the document/report. Obligations Actor SHALL:able-to-populate Producer #xD; presentedForm O 0..* EHDSAttachment A narrative easy-to-read representation of the full data set, e.g. PDF-version of a document Obligations Actor SHALL:able-to-populate Producer SHALL:process Consumer #xD; body O 0..1 Base Structured body of the discharge report document Obligations Actor SHALL:able-to-populate Producer SHALL:process Consumer #xD; alerts O 0..1 Base Section: Alerts. Obligations Actor SHOULD:able-to-populate Producer SHOULD:process Consumer #xD; generatedNarrative O 0..1 string Narrative, potentially formatted, content of the whole section. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; medicalAlert O 0..* EHDSAlert Description of medical alerts in textual format: any clinical information that is imperative to know so that the life or health of the patient does not come under threat. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; encounterInformation O 1..1 Base Section: Encounter information. Obligations Actor SHALL:able-to-populate Producer SHALL:process Consumer #xD; generatedNarrative O 0..1 string Narrative, potentially formatted, content of the whole section. Obligations Actor SHALL:able-to-populate Producer SHALL:process Consumer #xD; encounter O 0..1 EHDSEncounter Encounter information Obligations Actor SHALL:able-to-populate Producer SHALL:process Consumer #xD; note O 0..1 string Free text notes by the health professional Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; admissionEvaluation O 0..1 Base Section: Admission evaluation. Admission evaluation section should be reported only if it is relevant to ensure continuity of care. Obligations Actor SHALL:able-to-populate Producer SHALL:process Consumer #xD; generatedNarrative O 0..1 string Narrative, potentially formatted, content of the whole section. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; objectiveFindings O 0..* EHDSObservation Objective findings, such as anthropometric measurements, vital signs, or objective anatomical findings of physical examination Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; functionalStatus[x] O 0..* EHDSCondition, EHDSObservation An individual's ability to perform normal daily activities required to meet basic needs, fulfil usual roles and maintain health and well-being Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; note O 0..1 string Free text notes by the evaluation performer Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; patientHistory O 0..1 Base Section: Patient health history (anamnesis) containing only information that is highly relevant for this specific episode of care. The model is designed with the expectation that patient summary is available. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; generatedNarrative O 0..1 string Narrative, potentially formatted, content of the whole section. In case the section includes structured information, it should also be included in generatedNarrative. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; pastProblems O 0..* EHDSCondition A list of conditions of a patient that the patient suffered in the past or still suffers. Unlike diagnostic summary, medical history is not only a list of problems, but could contain broader description of the condition and its progress, details about treatment including medication and patient response to treatment. Past problem section (unlike the same section of the patient summary) should include only conditions that are important for continuity of care. This section, if provided, complements the diagnostic summary section of the discharge report. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; devicesAndImplants O 0..* EHDSDeviceUse Devices and implants in patient anamnesis. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; procedures O 0..* EHDSProcedure Procedures in patient anamnesis. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; note O 0..1 string Free text notes by the health professional Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; courseOfEncounter O 1..1 Base Course of inpatient or outpatient encounter. Obligations Actor SHALL:able-to-populate Producer SHALL:process Consumer #xD; generatedNarrative O 0..1 string Narrative, potentially formatted, content of the whole section. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; diagnosticSummary O 0..* EHDSCondition Problems that were treated or affected provisioning of care (diagnostics, therapy, nursing, monitoring) during the encounter. At least one treated problem should be marked. Other problems are recorded only if they are important for continuity of care (after discharge). Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; procedures O 0..* EHDSProcedure Procedures performed during encounter which are significant for continuity of care, e.g. surgeries and other instrumental interventions (endoscopic, intravascular), chemotherapy, radiotherapy, purification methods (dialysis, hemoperfusion), circulation support methods (counterpulsation, etc.), administration of blood derivatives or others. Diagnostic procedures are typically captured as observation results and not repeated here. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; medicalDevicesAndImplants O 0..* EHDSDeviceUse Medical devices (including implants) whose use was started, stopped, or otherwise modified during the encounter. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; pharmacotherapy O 0..* EHDSMedicationUse Significant medication treatments during encounter. The content of this section may be repeated in the medication summary for full overview of patient's medications. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; testResults[x] O 0..* EHDSObservation, EHDSLaboratoryObservation Significant medical test results of functional, diagnostic (including laboratory), and imaging examinations performed during encounter. This may include orders for which the results have not yet arrived. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; note O 0..1 string Free text notes by the health professional Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; dischargeDetails O 0..1 Base Discharge details Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; generatedNarrative O 0..1 string Narrative, potentially formatted, content of the whole section. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; objectiveFindings O 0..* EHDSObservation Objective findings, such as anthropometric measurements, vital signs, or objective anatomical findings of physical examination Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; functionalStatus[x] O 0..* EHDSCondition, EHDSObservation An individual's ability to perform normal daily activities required to meet basic needs, fulfil usual roles and maintain health and well-being Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; note O 0..1 string Free text notes by the health professional Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; medicationSummary O 0..1 Base Summary information on the medication recommended for the period after discharge, indicating whether the medication is changed or newly started. Compared to previous practices, the overview is supplemented with medication that has been discontinued. Obligations Actor SHALL:able-to-populate Producer SHALL:process Consumer #xD; generatedNarrative O 0..1 string Narrative, potentially formatted, content of the whole section. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; medicationUse O 0..* EHDSMedicationUse Details about medication and dosage Obligations Actor SHALL:able-to-populate Producer SHALL:process Consumer #xD; note O 0..1 string Free text notes by the health professional Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; carePlan O 0..1 Base Care plan and other recommendations after discharge. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; generatedNarrative O 0..1 string Narrative, potentially formatted, content of the whole section. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; otherRecommendations O 0..1 string Other recommendations (advice) after discharge. E.g., recommendation to suggest hip replacement, reduce number of cigarettes, stop smoking, increase physical exercises, etc. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; synthesis O 0..1 string Clinical synthesis (e.g. description of reasons and course of encounter) clustered by managed conditions. Clinical synthesis may include clinical reasoning (differential diagnostics, explanation of clinical context) in clinically complex conditions. Obligations Actor SHOULD:able-to-populate Producer SHALL:process Consumer #xD; Documentation for this format
Obligations for the logical model of discharge report.
A generic, flexible model for any kind of discharge report. Different types of encounters may require adding relevant sections and elements, or omitting irrelevant ones, depending on their data needs.
A common document header is necessary to ensure that the document can be unambiguously identified, associated with a patient, and processed in an exchange context. Systems claiming conformance must be capable of populating this metadata for every document instance.
EHR systems that consume discharge report SHALL process document header information.
EHR systems SHALL provide information about the subject of care.
EHR system SHALL render information about the subject of care in such a way that unambiguous assignment to the care subject is preserved.
Information about the subject of care SHALL be processed by the EHR system in such a way that the identity of the subject of care cannot be confused.
Business identifier for the object, unique within its system. Supporting disambiguation between different contexts (systems/countries).
Date and optionally time of authoring/issuing
Source of information (e.g. patient, patient's proxy). Used in case the patient has authored the information or the author has submitted patient-stated information.
Language in which the resource is written. Language is expressed by the IETF language tag.
Type of the document (e.g. '34105-7 Hospital discharge summary)
Title of the document, possibly autogenerated from the structured fields (e.g. 'Hospital discharge report. Jane Green. 07.10.2025-10.10.2025')
Time of service that is being documented (typically the same as the time/period of encounter)
Time of service that is being documented
Business version of the document. The exact algorithm for versioning is decided by the producer/custodian
Date and time of the approval of the document by Attester
The person or organisation taking responsibility for the content of the document.
Date and time when the document was authorised
Categorisation of the event covered by the document (e.g. laboratory study types, imaging study types including modality, etc.). Selection of such tags or labels depends on the use case and agreement between data sharing parties. This meta-data element serves primarily for searching and filtering purposes.
Additional details about where the content was created (e.g. clinical specialty)
Organisation that is in charge of maintaining the document/report.
Systems claiming DR conformance shall demonstrate the capability to generate a human-readable representation of the document when required by the exchange context. This obligation applies to capability, not to population in every instance.
EHR systems that consume DR report SHALL be able to process the human readable version of the report.
A narrative easy-to-read representation of the full data set, e.g. PDF-version of a document
Intended recipient(s) of the information, i.e. a person or organisation that should be notified or be aware of the content. This element is used to indicate explicit communication intent and does not represent routine storage or passive availability of information (e.g. in portals). Listing an intended recipient does not create an assignment or responsibility.
Each EHR system that is a producer of a discharge report SHALL be able to provide structured information about the report body. This obligation applies to capability, not to population in every instance.
EHR systems that consume discharge report SHALL process structured body information.
Structured body of the discharge report document
Alerts may not be present in all encounters, but the document structure must support their representation. Systems must be capable of populating and processing this section when alerts are present; omission is acceptable where permanently out of scope and justified during conformance testing.
EHR systems that consume discharge report SHALL process the alerts section when it is present in the document.
Information about substantial alerts or warnings (including allergies) that health professionals should be aware of.
Narrative representation supports immediate clinical understanding of alerts. Systems must be capable of populating this narrative; omission is acceptable where permanently out of scope and justified during conformance testing.
EHR systems that consume discharge report SHALL process the generatedNarrative element of the alerts section when it is present in the document.
Narrative, potentially formatted, content of the whole section.
Structured or textual alert entries represent clinically critical information when present. Systems must be capable of populating these entries; omission is acceptable where permanently out of scope and justified during conformance testing.
EHR systems that consume discharge report SHALL process the medicalAlert element of the alerts section when it is present in the document.
Description of medical alerts in textual format: any clinical information that is imperative to know so that the life or health of the patient does not come under threat.
Encounter context is essential for interpreting all clinical content in the document. Systems claiming conformance must be capable of populating this section for every document instance.
EHR systems that consume discharge report SHALL process structured information about the encounter.
A narrative description of the encounter context is necessary to ensure human interpretability. Systems must be capable of populating this narrative in every document instance.
EHR systems that consume discharge report SHALL process the generatedNarrative element of the encounterInformation section.
A structured encounter reference supports linkage and reuse where available. Systems must be capable of populating this reference; omission is acceptable where permanently out of scope and justified during conformance testing.
EHR systems that consume discharge report SHALL process the encounter element of the encounterInformation section.
Free text notes by the health professional
Admission evaluation does not occur in all encounters but must be representable where applicable. Systems must be capable of populating this section; omission is acceptable where permanently out of scope and justified during conformance testing.
EHR systems that consume discharge report SHALL process structured information about the admission evaluation.
Section: Admission evaluation. Admission evaluation section should be reported only if it is relevant to ensure continuity of care.
Narrative summarisation supports clinical understanding of admission findings. Systems must be capable of populating this narrative; omission is acceptable where permanently out of scope and justified during conformance testing.
EHR systems that consume discharge report SHALL process the generatedNarrative element of the admissionEvaluation section.
Objective findings are part of structured clinical assessment when performed. Systems must be capable of populating this container; omission is acceptable where permanently out of scope and justified during conformance testing.
EHR systems that consume discharge report SHALL process the objectiveFindings element of the admissionEvaluation section when it is present in the document.
Objective findings, such as anthropometric measurements, vital signs, or objective anatomical findings of physical examination
Functional status assessment is context-dependent but relevant for continuity of care. Systems must be capable of populating this section; omission is acceptable where permanently out of scope and justified during conformance testing.
EHR systems that consume discharge report SHALL process the functionalStatus element of the admissionEvaluation section when it is present in the document.
An individual's ability to perform normal daily activities required to meet basic needs, fulfil usual roles and maintain health and well-being
Free text notes by the evaluation performer
Patient history may not be available or relevant in all care contexts, but systems must be capable of representing this section when such information exists. Omission is acceptable where the capability is permanently out of scope and justified during conformance testing.
EHR systems that consume discharge report SHALL process structured information about patient history.
Section: Patient health history (anamnesis) containing only information that is highly relevant for this specific episode of care. The model is designed with the expectation that patient summary is available.
A narrative overview supports human understanding of the patient’s history when structured data is incomplete or heterogeneous. Systems must be capable of populating and processing narrative content; omission is acceptable where justified during conformance testing.
EHR systems that consume discharge report SHALL process the generatedNarrative element of the patientHistory section.
Narrative, potentially formatted, content of the whole section. In case the section includes structured information, it should also be included in generatedNarrative.
Past problems relevant to the current episode of care should be representable in a structured format. Systems must be capable of populating this section when such information is available; omission is acceptable where permanently out of scope and justified during conformance testing.
EHR systems that consume discharge report SHALL process the pastProblems element of the patientHistory section when it is present in the document.
A list of conditions of a patient that the patient suffered in the past or still suffers. Unlike diagnostic summary, medical history is not only a list of problems, but could contain broader description of the condition and its progress, details about treatment including medication and patient response to treatment. Past problem section (unlike the same section of the patient summary) should include only conditions that are important for continuity of care. This section, if provided, complements the diagnostic summary section of the discharge report.
Information about devices and implants in patient history may be relevant for continuity of care. Systems must be capable of populating this section when such information is available; omission is acceptable where permanently out of scope and justified during conformance testing.
EHR systems that consume discharge report SHALL process the devicesAndImplants element of the patientHistory section when it is present in the document.
Devices and implants in patient anamnesis.
Historical procedures relevant to the current episode of care should be representable in a structured format. Systems must be capable of populating this section when such information is available; omission is acceptable where permanently out of scope and justified during conformance testing.
EHR systems that consume discharge report SHALL process the procedures element of the patientHistory section when it is present in the document.
Historical procedures performed on or for a patient, relevant for the current encounter. Examples include surgical procedures, diagnostic procedures, endoscopic procedures, biopsies, counselling, physiotherapy, personal support services, adult day care services, etc.
Course of encounter is a core component of the discharge report. Systems claiming conformance must be capable of populating this section for every document instance.
EHR systems that consume discharge report SHALL process structured information about the course of encounter.
Course of inpatient or outpatient encounter.
A narrative summary of the course of encounter supports human understanding of the clinical course. Systems must be capable of populating this narrative when such information is available.
EHR systems that consume discharge report SHALL process the generatedNarrative element of the courseOfEncounter section.
A diagnostic summary is essential for continuity of care. Systems claiming conformance must be capable of populating this section when such information is available.
EHR systems that consume discharge report SHALL process the diagnosticSummary element of the courseOfEncounter section.
Problems that were treated or affected provisioning of care (diagnostics, therapy, nursing, monitoring) during the encounter. At least one treated problem should be marked. Other problems are recorded only if they are important for continuity of care (after discharge).
Procedures performed during the encounter are important for continuity of care. Systems must be capable of populating this section when such information is available.
EHR systems that consume discharge report SHALL process the procedures element of the courseOfEncounter section when it is present in the document.
Procedures performed during encounter which are significant for continuity of care, e.g. surgeries and other instrumental interventions (endoscopic, intravascular), chemotherapy, radiotherapy, purification methods (dialysis, hemoperfusion), circulation support methods (counterpulsation, etc.), administration of blood derivatives or others. Diagnostic procedures are typically captured as observation results and not repeated here.
Devices and implants are clinically significant historical data and must be representable when medical history is present. Systems must be capable of populating and processing these entries.
EHR systems that consume discharge report SHALL process the medicalDevicesAndImplants element of the courseOfEncounter section when it is present in the document.
Medical devices (including implants) whose use was started, stopped, or otherwise modified during the encounter.
Medication treatments during the encounter are important for continuity of care. Systems must be capable of populating this section when such information is available.
EHR systems that consume discharge report SHALL process the medications element of the courseOfEncounter section when it is present in the document.
Significant medication treatments during encounter. The content of this section may be repeated in the medication summary for full overview of patient's medications.
Test results of functional, diagnostic, and imaging examinations are important for continuity of care. Systems must be capable of populating this section when such information is available.
EHR systems that consume discharge report SHALL process the testResults element of the courseOfEncounter section when it is present in the document.
Significant medical test results of functional, diagnostic (including laboratory), and imaging examinations performed during encounter. This may include orders for which the results have not yet arrived.
Discharge details are essential to ensure safe transition of care and continuity after discharge. Systems claiming conformance must be capable of populating this section.
EHR systems that consume discharge report SHALL process structured information about discharge details.
Structured information should be provided, however if not available, at least a section narrative should be present.
Narrative discharge summaries support human understanding of discharge context. Systems must be capable of populating this narrative; omission is acceptable where justified during conformance testing.
EHR systems that consume discharge report SHALL process the generatedNarrative element of the dischargeDetails section.
Objective findings at discharge may not always be collected but must be representable when available. Systems must be capable of populating this section; omission is acceptable where justified during conformance testing.
EHR systems that consume discharge report SHALL process the objectiveFindings element of the dischargeDetails section when it is present in the document.
Functional status at discharge may influence care planning but is context-dependent. Systems must be capable of representing this section; omission is acceptable where justified during conformance testing.
EHR systems that consume discharge report SHALL process the functionalStatus element of the dischargeDetails section when it is present in the document.
Medication summary at discharge may vary by encounter but must be representable when applicable. Systems must be capable of populating this section; omission is acceptable where justified during conformance testing.
EHR systems that consume discharge report SHALL process structured information about medication summary.
Summary information on the medication recommended for the period after discharge, indicating whether the medication is changed or newly started. Compared to previous practices, the overview is supplemented with medication that has been discontinued.
Narrative summarisation supports understanding of medication changes after discharge. Systems must be capable of populating this narrative; omission is acceptable where justified during conformance testing.
EHR systems that consume discharge report SHALL process the generatedNarrative element of the medicationSummary section.
Medication and dosing details are essential for safe post-discharge therapy. Systems must be capable of populating this information whenever a medication entry is present.
EHR systems that consume discharge report SHALL process the medicationUse element of the medicationSummary section when it is present in the document.
Post-discharge care plans and recommendations may vary by encounter. Systems must be capable of representing this section; omission is acceptable where justified during conformance testing.
EHR systems that consume discharge report SHALL process structured information about care plan and recommendations after discharge.
Care plan and other recommendations after discharge.
Narrative recommendations support human interpretation of post-discharge care. Systems must be capable of populating this narrative; omission is acceptable where justified during conformance testing.
EHR systems that consume discharge report SHALL process the generatedNarrative element of the carePlan section.
Structured care plan after discharge. Multiple care plans could be provided.
Additional advice may be clinically relevant but is context-dependent. Systems must be capable of representing this information; omission is acceptable where justified during conformance testing.
EHR systems that consume discharge report SHALL process the otherRecommendations element of the carePlan section when it is present in the document.
Other recommendations (advice) after discharge. E.g., recommendation to suggest hip replacement, reduce number of cigarettes, stop smoking, increase physical exercises, etc.
Clinical synthesis (e.g. description of reasons and course of encounter) clustered by managed conditions. Clinical synthesis may include clinical reasoning (differential diagnostics, explanation of clinical context) in clinically complex conditions.
Report attachments. Implementations may define what kind of attachments are allowed and may ignore unexpected attachments for security reasons.