Discharge report in FHIR

Discharge report is a priority category of the European Health Data Space (Article 14(1) point (f) of Regulation (EU) 2025/327). It applies from March 26, 2031. HL7 Europe covers it with hdr 1.0.0.

Regulation: Regulation (EU) 2025/327, Article 14(1)(f), Annex I
Applies from: March 26, 2031
HL7 Europe guides: hl7.fhir.eu.hdr 1.0.0, published
Xt-EHR logical models: EHDSDischargeReport
Document type: LOINC 18842-5 Discharge summaryLOINC 100719-4 Surgical oncology Discharge summary
Validator: Open the EHDS profile validator

What the Regulation says

Annex I of the Regulation describes the main characteristics of this category. The text is the English original.

Discharge reports
Electronic health data related to a healthcare encounter or episode of care and including essential information about admission, treatment and discharge of a natural person.

FHIR profiles 33

Profiles defined by the guides above. The rules column counts the elements where the profile goes beyond base FHIR (required, forbidden or limited), which the validator checks; of the slices, only the required ones that a fixed value or the resource type identifies are checked.

Profile	Resource	HL7 Europe guide	Rules checked	Slices checked / defined
AllergyIntolerance: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/allergyIntolerance-obl-eu-hdr`	`AllergyIntolerance`	hdr	1	0 / 7
Bundle (HDR)`http://hl7.eu/fhir/hdr/StructureDefinition/bundle-eu-hdr`	`Bundle`	hdr	10	3 / 31
Bundle: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/bundle-obl-eu-hdr`	`Bundle`	hdr	10	3 / 31
CarePlan (HDR)`http://hl7.eu/fhir/hdr/StructureDefinition/carePlan-eu-hdr`	`CarePlan`	hdr	0	0 / 0
CarePlan: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/carePlan-obl-eu-hdr`	`CarePlan`	hdr	0	0 / 0
Composition (HDR)`http://hl7.eu/fhir/hdr/StructureDefinition/composition-eu-hdr`	`Composition`	hdr	6	0 / 61
Composition: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/composition-obl-eu-hdr`	`Composition`	hdr	6	0 / 61
Condition: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/condition-obl-eu-hdr`	`Condition`	hdr	1	0 / 5
Device (HDR)`http://hl7.eu/fhir/hdr/StructureDefinition/device-eu-hdr`	`Device`	hdr	0	0 / 0
Device: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/device-obl-eu-hdr`	`Device`	hdr	0	0 / 0
DeviceUseStatement (HDR)`http://hl7.eu/fhir/hdr/StructureDefinition/deviceUseStatement-eu-hdr`	`DeviceUseStatement`	hdr	0	0 / 4
DeviceUseStatement: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/deviceUseStatement-obl-eu-hdr`	`DeviceUseStatement`	hdr	0	0 / 4
Encounter (HDR)`http://hl7.eu/fhir/hdr/StructureDefinition/encounter-eu-hdr`	`Encounter`	hdr	1	0 / 7
Encounter: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/encounter-obl-eu-hdr`	`Encounter`	hdr	1	0 / 7
Flag: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/flag-obl-eu-hdr`	`Flag`	hdr	0	0 / 3
Goal (HDR)`http://hl7.eu/fhir/hdr/StructureDefinition/goal-eu-hdr`	`Goal`	hdr	0	0 / 2
Immunization: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/immunization-obl-eu-hdr`	`Immunization`	hdr	0	0 / 12
Medication: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/medication-obl-eu-hdr`	`Medication`	hdr	0	0 / 12
MedicationAdministration (HDR)`http://hl7.eu/fhir/hdr/StructureDefinition/medicationAdministration-eu-hdr`	`MedicationAdministration`	hdr	0	0 / 0
MedicationAdministration: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/medicationAdministration-obl-eu-hdr`	`MedicationAdministration`	hdr	0	0 / 0
MedicationDispense (HDR)`http://hl7.eu/fhir/hdr/StructureDefinition/medicationDispense-eu-hdr`	`MedicationDispense`	hdr	2	0 / 0
MedicationDispense: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/medicationDispense-obl-eu-hdr`	`MedicationDispense`	hdr	2	0 / 0
MedicationRequest: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/medicationRequest-obl-eu-hdr`	`MedicationRequest`	hdr	0	0 / 6
MedicationStatement: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/medicationStatement-obl-eu-hdr`	`MedicationStatement`	hdr	0	0 / 5
Observation (laboratory): obligations`http://hl7.eu/fhir/hdr/StructureDefinition/laboratoryObservation-obl-eu-hdr`	`Observation`	hdr	3	0 / 34
Observation: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/observation-obl-eu-hdr`	`Observation`	hdr	0	0 / 26
Organization: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/organization-obl-eu-hdr`	`Organization`	hdr	1	0 / 0
Patient: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/patient-obl-eu-hdr`	`Patient`	hdr	2	0 / 7
Practitioner: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/practitioner-obl-eu-hdr`	`Practitioner`	hdr	1	0 / 0
PractitionerRole: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/practitionerRole-obl-eu-hdr`	`PractitionerRole`	hdr	0	0 / 0
Procedure: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/procedure-obl-eu-hdr`	`Procedure`	hdr	2	0 / 2
RelatedPerson: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/relatedPerson-obl-eu-hdr`	`RelatedPerson`	hdr	0	0 / 0
Specimen: obligations`http://hl7.eu/fhir/hdr/StructureDefinition/specimen-obl-eu-hdr`	`Specimen`	hdr	0	0 / 0

Document structure

The document profiles of this category: the sections a Composition can carry and the entries a Bundle can hold, as the profiles state them. Names are slice names; the section code is the LOINC code the profile fixes.

Bundle (HDR): Bundle entries 31

Entry	Card.	FHIR resource	Profile
`composition`	`1..1`	`Composition`	`CompositionEuHdr`
`patient`	`1..*`	`Patient`	`PatientEuCore`
`encounter`	`1..*`	`Encounter`	`EncounterEuHdr`
`allergyIntolerance`	`0..*`	`AllergyIntolerance`	`AllergyIntoleranceEuCore`
`bodyStructure`	`0..*`	`BodyStructure`	`BodyStructureEuCore`
`condition`	`0..*`	`Condition`	`ConditionEuCore`
`device`	`0..*`	`Device`	`DeviceEuHdr`
`deviceUseStatement`	`0..*`	`DeviceUseStatement`	`DeviceUseStatementEuHdr`
`diagnosticReport`	`0..*`	`DiagnosticReport`	`DiagnosticReportEuCore`
`imagingStudy`	`0..*`	`ImagingStudy`
`immunization`	`0..*`	`Immunization`	`ImmunizationEuCore`
`media`	`0..*`	`Media`
`medication`	`0..*`	`Medication`	`MedicationEuCore`
`medicationRequest`	`0..*`	`MedicationRequest`	`MedicationRequestEuCore`
`medicationStatement`	`0..*`	`MedicationStatement`	`MedicationStatementEuCore`
`medicationDispense`	`0..*`	`MedicationDispense`	`MedicationDispenseEuHdr`
`medicationAdministration`	`0..*`	`MedicationAdministration`	`MedicationAdministrationEuHdr`
`practitioner`	`0..*`	`Practitioner`	`PractitionerEuCore`
`practitionerRole`	`0..*`	`PractitionerRole`	`PractitionerRoleEuCore`
`procedure`	`0..*`	`Procedure`	`ProcedureEuCore`
`organization`	`0..*`	`Organization`	`OrganizationEuCore`
`observation`	`0..*`	`Observation`
`specimen`	`0..*`	`Specimen`
`documentReference`	`0..*`	`DocumentReference`
`flag`	`0..*`	`Flag`	`FlagPatientEuCore`
`location`	`0..*`	`Location`	`LocationEuCore`
`careplan`	`0..*`	`CarePlan`	`CarePlanEuHdr`
`goal`	`0..*`	`Goal`	`GoalEuHdr`
`relatedPerson`	`0..*`	`RelatedPerson`
`binary`	`0..*`	`Binary`
`serviceRequest`	`0..*`	`ServiceRequest`

Composition (HDR): sections 23

Section	Card.	Section code	Description
`sectionAlert`	`0..1`	`LOINC 104605-1`	Substantial alerts and warnings
`sectionAdmissionEvaluation`	`0..1`	`LOINC 67851-6`	Patient evaluation at hospital admission
`sectionVitalSigns`	`0..1`	`LOINC 8716-3`	Vital signs during the encounter and at discharge
`sectionPhysicalFindings`	`0..1`	`LOINC 29545-1`	Objective findings from physical examination
`sectionFunctionalStatus`	`0..1`	`LOINC 47420-5`	Ability to perform activities of daily living
`sectionDischargeSummary`	`0..1`	`LOINC 18842-5`	Complete narrative discharge summary
`sectionHospitalCourse`	`0..1`	`LOINC 8648-8`	Significant information about course of hospital stay
`sectionDiagnosticSummary`	`0..1`	`LOINC 11535-2`	Problems and diagnoses of the hospital stay
`sectionSignificantProcedures`	`0..1`	`LOINC 10185-7`	Significant procedures performed during the stay
`sectionMedicalDevices`	`0..1`	`LOINC 46264-8`	Devices used or implanted before this encounter
`sectionProceduresHx`	`0..1`	`LOINC 47519-4`	Past procedures relevant to this encounter
`sectionPharmacotherapy`	`0..1`	`LOINC 87232-5`	Drug treatment discontinued before discharge
`sectionImplantedDevices`	`0..1`	`LOINC 57080-4`	Devices and implants during the hospital stay
`sectionSignificantResults`	`0..1`	`LOINC 30954-2`	Significant medical test results of the stay
`sectionSynthesis`	`0..1`	`LOINC 67781-5`	Clinical synthesis of the hospital stay
`sectionPlanOfCare`	`0..1`	`LOINC 18776-5`	Plan of care and recommendations after discharge
`sectionDischargeMedications`	`0..1`	`LOINC 75311-1`	Medication intended after discharge
`sectionAllergies`	`0..1`	`LOINC 48765-2`	Relevant allergies and intolerances
`sectionPatientHx`	`0..1`	`LOINC 11329-0`	Narrative patient health history (anamnesis)
`sectionProblems`	`0..1`	`LOINC 11450-4`	Problems currently being monitored
`sectionImmunizations`	`0..1`	`LOINC 11369-6`	Immunization status and vaccination history
`sectionDischargeDetails`	`0..1`	`LOINC 8650-4`	Discharge status and disposition of the patient
`sectionAttachments`	`0..1`	`LOINC 77599-9`	Library of attachments

Terminology bindings 2

Value sets that the profiles of this category bind elements to with a required or extensible binding. A required binding only allows codes of the value set; an extensible one expects them unless none fits. Value sets that the HL7 Europe packages define are listed with their codes in the value set reference.

The profiles also state 4 preferred and 1 example bindings.

Value set	Binding	Used by	Codes
Encounter Status Value Set`http://hl7.eu/fhir/hdr/ValueSet/encounter-status-eu-hdr`	`required`	EncounterEuHdr `status`	5 codes
Encounter Class Value Set`http://hl7.eu/fhir/hdr/ValueSet/encounter-class-eu-hdr`	`extensible`	EncounterEuHdr `class`	5 codes

Extensions 2

HL7 Europe extensions that the profiles of this category carry, with the element that holds each one.

Extension	Context	Value	Used in
Encounter: Legal Status`http://hl7.eu/fhir/StructureDefinition/encounter-legalStatus`	`Encounter`	complex	EncounterEuHdr `extension:legalStatus` 0..*
Composition: Information recipient`http://hl7.eu/fhir/StructureDefinition/information-recipient`	`Composition`	`Reference`	CompositionEuHdr `extension:informationRecipient` 0..*

Logical model EHDSDischargeReport 65

Elements of the Xt-EHR logical model with their cardinality and obligations. Obligations tell producers and consumers of the data what a system SHALL or SHOULD do with each element.

Obligations by actor

How many elements of EHDSDischargeReport carry each obligation for each actor.

Obligation	Actor	Elements
`SHALL:able-to-populate`	producer	28
`SHALL:display`	consumer	6
`SHALL:process`	consumer	43
`SHOULD:able-to-populate`	producer	32
`SHOULD:display`	consumer	2
`SHOULD:process`	consumer	1

Elements 65

Element	Card.	Obligations	Description
`header`	`1..1`	`SHALL:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process document header information.	Document header
`subject`	`1..1`	`SHALL:able-to-populate` producer EHR systems SHALL provide information about the subject of care.`SHALL:display` consumer EHR system SHALL render information about the subject of care in such a way that unambiguous assignment to the care subject is preserved.`SHALL:process` consumer 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.	Patient/subject information
`identifier`	`1..*`	`SHALL:able-to-populate` producer`SHOULD:display` consumer`SHALL:process` consumer	Unique identifier of the document
`author[x]`	`1..*`	`SHALL:able-to-populate` producer`SHALL:display` consumer	The author of the report.
`date`	`1..1`	`SHALL:able-to-populate` producer`SHALL:display` consumer	Date of finalising/issuing the document
`status`	`1..1`	`SHALL:able-to-populate` producer`SHALL:display` consumer	Status of the document
`source`	`0..0`		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`	`0..1`	`SHALL:able-to-populate` producer	Language in which the resource is written. Language is expressed by the IETF language tag.
`documentType`	`1..1`	`SHALL:able-to-populate` producer	Type of the document (e.g. '34105-7 Hospital discharge summary)
`documentTitle`	`1..1`	`SHALL:able-to-populate` producer	Title of the document, possibly autogenerated from the structured fields (e.g. 'Hospital discharge report. Jane Green. 07.10.2025-10.10.2025')
`period`	`0..1`	`SHALL:able-to-populate` producer	Time of service that is being documented (typically the same as the time/period of encounter)
`version`	`0..1`		Business version of the document. The exact algorithm for versioning is decided by the producer/custodian
`attestation`	`0..*`	`SHALL:able-to-populate` producer`SHALL:display` consumer	Document attestation details
`attester[x]`	`1..1`	`SHALL:able-to-populate` producer`SHALL:display` consumer	Attester who validated the document
`datetime`	`1..1`	`SHALL:able-to-populate` producer	Date and time of the approval of the document by Attester
`legalAuthentication`	`0..*`	`SHALL:able-to-populate` producer	Document legal authentication details
`legalAuthenticator[x]`	`1..1`	`SHALL:able-to-populate` producer	The person or organisation taking responsibility for the content of the document.
`datetime`	`1..1`	`SHALL:able-to-populate` producer	Date and time when the document was authorised
`eventType`	`0..*`	`SHALL:able-to-populate` producer	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.
`serviceSpecialty`	`0..*`	`SHALL:able-to-populate` producer`SHOULD:display` consumer	Additional details about where the content was created (e.g. clinical specialty)
`custodian`	`0..1`	`SHALL:able-to-populate` producer	Organisation that is in charge of maintaining the document/report.
`intendedRecipient[x]`	`0..*`		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.
`presentedForm`	`0..*`	`SHALL:able-to-populate` producer 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.`SHALL:process` consumer 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
`body`	`0..1`	`SHALL:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process structured body information.	Structured body of the discharge report document
`alerts`	`0..1`	`SHOULD:able-to-populate` producer 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.`SHOULD:process` consumer EHR systems that consume discharge report SHALL process the alerts section when it is present in the document.	Section: Alerts.
`generatedNarrative`	`0..1`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer 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.
`medicalAlert`	`0..*`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer 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.
`encounterInformation`	`1..1`	`SHALL:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process structured information about the encounter.	Section: Encounter information.
`generatedNarrative`	`0..1`	`SHALL:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process the generatedNarrative element of the encounterInformation section.	Narrative, potentially formatted, content of the whole section.
`encounter`	`0..1`	`SHALL:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process the encounter element of the encounterInformation section.	Encounter information
`note`	`0..1`	`SHOULD:able-to-populate` producer`SHALL:process` consumer	Free text notes by the health professional
`admissionEvaluation`	`0..1`	`SHALL:able-to-populate` producer 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.`SHALL:process` consumer 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.
`generatedNarrative`	`0..1`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process the generatedNarrative element of the admissionEvaluation section.	Narrative, potentially formatted, content of the whole section.
`objectiveFindings`	`0..*`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer 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
`functionalStatus[x]`	`0..*`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer 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
`note`	`0..1`	`SHOULD:able-to-populate` producer`SHALL:process` consumer	Free text notes by the evaluation performer
`patientHistory`	`0..1`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer 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.
`generatedNarrative`	`0..1`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer 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.
`pastProblems`	`0..*`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer 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.
`devicesAndImplants`	`0..*`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer 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.
`procedures`	`0..*`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process the procedures element of the patientHistory section when it is present in the document.	Procedures in patient anamnesis.
`note`	`0..1`	`SHOULD:able-to-populate` producer`SHALL:process` consumer	Free text notes by the health professional
`courseOfEncounter`	`1..1`	`SHALL:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process structured information about the course of encounter.	Course of inpatient or outpatient encounter.
`generatedNarrative`	`0..1`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process the generatedNarrative element of the courseOfEncounter section.	Narrative, potentially formatted, content of the whole section.
`diagnosticSummary`	`0..*`	`SHOULD:able-to-populate` producer A diagnostic summary is essential for continuity of care. Systems claiming conformance must be capable of populating this section when such information is available.`SHALL:process` consumer 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`	`0..*`	`SHOULD:able-to-populate` producer Procedures performed during the encounter are important for continuity of care. Systems must be capable of populating this section when such information is available.`SHALL:process` consumer 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.
`medicalDevicesAndImplants`	`0..*`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer 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.
`pharmacotherapy`	`0..*`	`SHOULD:able-to-populate` producer Medication treatments during the encounter are important for continuity of care. Systems must be capable of populating this section when such information is available.`SHALL:process` consumer 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.
`testResults[x]`	`0..*`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer 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.
`note`	`0..1`	`SHOULD:able-to-populate` producer`SHALL:process` consumer	Free text notes by the health professional
`dischargeDetails`	`0..1`	`SHOULD:able-to-populate` producer Discharge details are essential to ensure safe transition of care and continuity after discharge. Systems claiming conformance must be capable of populating this section.`SHALL:process` consumer EHR systems that consume discharge report SHALL process structured information about discharge details.	Discharge details
`generatedNarrative`	`0..1`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process the generatedNarrative element of the dischargeDetails section.	Narrative, potentially formatted, content of the whole section.
`objectiveFindings`	`0..*`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process the objectiveFindings element of the dischargeDetails section when it is present in the document.	Objective findings, such as anthropometric measurements, vital signs, or objective anatomical findings of physical examination
`functionalStatus[x]`	`0..*`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process the functionalStatus element of the dischargeDetails 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
`note`	`0..1`	`SHOULD:able-to-populate` producer`SHALL:process` consumer	Free text notes by the health professional
`medicationSummary`	`0..1`	`SHALL:able-to-populate` producer 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.`SHALL:process` consumer 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.
`generatedNarrative`	`0..1`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process the generatedNarrative element of the medicationSummary section.	Narrative, potentially formatted, content of the whole section.
`medicationUse`	`0..*`	`SHALL:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process the medicationUse element of the medicationSummary section when it is present in the document.	Details about medication and dosage
`note`	`0..1`	`SHOULD:able-to-populate` producer`SHALL:process` consumer	Free text notes by the health professional
`carePlan`	`0..1`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process structured information about care plan and recommendations after discharge.	Care plan and other recommendations after discharge.
`generatedNarrative`	`0..1`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer EHR systems that consume discharge report SHALL process the generatedNarrative element of the carePlan section.	Narrative, potentially formatted, content of the whole section.
`carePlan`	`0..*`		Structured care plan after discharge. Multiple care plans could be provided.
`otherRecommendations`	`0..1`	`SHOULD:able-to-populate` producer 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.`SHALL:process` consumer 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.
`synthesis`	`0..1`	`SHOULD:able-to-populate` producer`SHALL:process` consumer	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.
`attachments`	`0..*`		Report attachments. Implementations may define what kind of attachments are allowed and may ignore unexpected attachments for security reasons.

Mapping of EHDSDischargeReport to FHIR 50

How each logical element lands in FHIR, as published in the HL7 Europe guide. Mapped to: BundleEuHdr, CompositionEuHdr.

Element	Relation	FHIR resource	FHIR element	Notes
`header`	related to	`Composition`	`.`	CompositionEuHdr constrains header elements for HDR.
`author[x]`	equivalent	`Composition`	`author`	Reference to Practitioner/PractitionerRole/Organization/Device per profile.
`status`	equivalent	`Composition`	`status`
`documentType`	equivalent	`Composition`	`type`	Fixed to LOINC 34105-7 in CompositionEuHdr.
`documentTitle`	equivalent	`Composition`	`title`
`period`	related to	`Composition`	`event.period`	Map to the primary Composition.event entry.
`intendedRecipient[x]`	related to	`Composition`	`extension:information-recipient`	Uses the information-recipient extension in CompositionEuHdr.
`encounterInformation`	related to	`Composition`	`encounter`	Use EncounterEuHdr.
`generatedNarrative`	related to	`Encounter`	`text`
`encounter`	equivalent	`Composition`	`encounter`
`note`	related to	`Composition`	`extension:note`
`alerts`	equivalent	`Composition`	`section:sectionAlert`	Use LOINC 104605-1.
`generatedNarrative`	equivalent	`Composition`	`section:sectionAlert.text`
`medicalAlert`	equivalent	`Composition`	`section:sectionAlert`	Reference to Flag (EHDSAlert).
`admissionEvaluation`	equivalent	`Composition`	`section:sectionAdmissionEvaluation`	Reported only if relevant.
`generatedNarrative`	equivalent	`Composition`	`section:sectionAdmissionEvaluation.text`
`objectiveFindings`	related to	`Composition`	`section:sectionVitalSigns`	Use Observation where appropriate.
`objectiveFindings`	related to	`Composition`	`section:sectionAnthropometry`	Use Observation where appropriate.
`objectiveFindings`	related to	`Composition`	`section:sectionPhysicalFindings`	Use Observation where appropriate.
`functionalStatus[x]`	related to	`Composition`	`section:sectionFunctionalStatus`	Condition/Observation/ClinicalImpression as allowed.
`note`	related to	`Composition`	`section:sectionAdmissionEvaluation.text`
`patientHistory`	equivalent	`Composition`	`section:sectionPatientHx`
`generatedNarrative`	equivalent	`Composition`	`section:sectionPatientHx.text`
`note`	related to	`Composition`	`section:sectionPatientHx.extension:note`
`courseOfEncounter`	equivalent	`Composition`	`section:sectionHospitalCourse`
`generatedNarrative`	equivalent	`Composition`	`section:sectionHospitalCourse.text`
`diagnosticSummary`	equivalent	`Composition`	`section:sectionDiagnosticSummary`	Reference to ConditionEuCore.
`procedures`	equivalent	`Composition`	`section:sectionSignificantProcedures`	Reference to ProcedureEuCore.
`medicalDevicesAndImplants`	equivalent	`Composition`	`section:sectionMedicalDevices`	Reference to DeviceUseStatementEuHdr.
`pharmacotherapy`	equivalent	`Composition`	`section:sectionPharmacotherapy`	MedicationStatement/Request/Dispense/Administration.
`objectiveFindings`	related to	`Composition`	`section:sectionVitalSigns`	Use Observation where appropriate.
`objectiveFindings`	related to	`Composition`	`section:sectionAnthropometry`	Use Observation where appropriate.
`objectiveFindings`	related to	`Composition`	`section:sectionPhysicalFindings`	Use Observation where appropriate.
`testResults`	equivalent	`Composition`	`section:sectionSignificantResults`	Observation/DiagnosticReport/DocumentReference.
`note`	related to	`Composition`	`section:sectionHospitalCourse.text`
`dischargeDetails`	equivalent	`Composition`	`section:sectionDischargeDetails`
`generatedNarrative`	equivalent	`Composition`	`section:sectionDischargeDetails.text`
`objectiveFindings`	related to	`Composition`	`section:sectionPhysicalFindings / section:sectionVitalSigns`	Use Observation where appropriate.
`functionalStatus[x]`	related to	`Composition`	`section:sectionFunctionalStatus`
`note`	related to	`Composition`	`section:sectionDischargeDetails.text`
`medicationSummary`	related to	`Composition`	`section:sectionDischargeMedications`	Post-discharge medications summary.
`generatedNarrative`	equivalent	`Composition`	`section:sectionDischargeMedications.text`
`medicationUse`	equivalent	`Composition`	`section:sectionDischargeMedications`	MedicationRequest/MedicationDispense/MedicationStatement.
`note`	related to	`Composition`	`section:sectionDischargeMedications.text`
`carePlan`	equivalent	`Composition`	`section:sectionPlanOfCare`
`generatedNarrative`	equivalent	`Composition`	`section:sectionPlanOfCare.text`
`carePlan`	equivalent	`Composition`	`section:sectionPlanOfCare`	Reference to CarePlanEuHdr.
`otherRecommendations`	related to	`Composition`	`section:sectionPlanOfCare.text`	May also be represented in Discharge Instructions narrative.
`synthesis`	equivalent	`Composition`	`section:sectionSynthesis.text`
`attachments`	equivalent	`Composition`	`section:sectionAttachments`	DocumentReference/Binary in CompositionEuHdr.

CDA documents (eHDSI)

The same category is carried in CDA by these eHDSI document templates. Their structure, value sets and a validator for CDA documents are in the CDA guide.

eHDSI OrCD Hospital Discharge Report

Sources

Regulation (EU) 2025/327, Official Journal of the European Union; HL7 Europe FHIR implementation guides; Xt-EHR logical models (xtehr.eu.ehds.models). Ballot guides may still change. This guide is informational: it is not legal advice and not a certification of conformity.