Informe de alta en FHIR

Informe de alta es una categoría prioritaria del Espacio Europeo de Datos de Salud (artículo 14(1), letra (f) del Reglamento (UE) 2025/327). Se aplica desde el 26 de marzo de 2031. HL7 Europe la cubre con hdr 1.0.0.

Reglamento: Regulation (EU) 2025/327, Article 14(1)(f), Annex I
Se aplica desde: 26 de marzo de 2031
Guías HL7 Europe: hl7.fhir.eu.hdr 1.0.0, publicada
Modelos lógicos Xt-EHR: EHDSDischargeReport
Tipo de documento: LOINC 18842-5 Discharge summaryLOINC 100719-4 Surgical oncology Discharge summary
Validador: Abrir el validador de perfiles EHDS

Qué dice el Reglamento

El anexo I del Reglamento describe las características principales de esta categoría. El texto es el original en inglés.

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.

Perfiles FHIR 33

Perfiles definidos por las guías anteriores. La columna de reglas cuenta los elementos en los que el perfil va más allá de FHIR base (obligatorios, prohibidos o limitados), que el validador comprueba; de los slices solo se comprueban los obligatorios que un valor fijo o el tipo de recurso permiten identificar.

Perfil	Recurso	Guía HL7 Europe	Reglas comprobadas	Slices comprobados / definidos
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

Estructura del documento

Los perfiles de documento de esta categoría: las secciones que puede llevar una Composition y las entradas que puede contener un Bundle, tal como los perfiles las establecen. Los nombres son nombres de slice; el código de sección es el código LOINC que fija el perfil.

Bundle (HDR): entradas del Bundle 31

Entrada	Card.	Recurso FHIR	Perfil
`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): secciones 23

Sección	Card.	Código de sección	Descripción
`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

Bindings de terminología 2

Value sets a los que los perfiles de esta categoría enlazan elementos con un binding required o extensible. Un binding required solo admite códigos del value set; uno extensible los espera salvo que ninguno encaje. Los value sets que definen los paquetes de HL7 Europe se listan con sus códigos en la referencia de value sets.

Los perfiles también declaran 4 bindings preferred y 1 example.

Value set	Binding	Usado por	Códigos
Encounter Status Value Set`http://hl7.eu/fhir/hdr/ValueSet/encounter-status-eu-hdr`	`required`	EncounterEuHdr `status`	5 códigos
Encounter Class Value Set`http://hl7.eu/fhir/hdr/ValueSet/encounter-class-eu-hdr`	`extensible`	EncounterEuHdr `class`	5 códigos

Extensiones 2

Extensiones de HL7 Europe que llevan los perfiles de esta categoría, con el elemento que contiene cada una.

Extensión	Contexto	Valor	Usada en
Encounter: Legal Status`http://hl7.eu/fhir/StructureDefinition/encounter-legalStatus`	`Encounter`	compleja	EncounterEuHdr `extension:legalStatus` 0..*
Composition: Information recipient`http://hl7.eu/fhir/StructureDefinition/information-recipient`	`Composition`	`Reference`	CompositionEuHdr `extension:informationRecipient` 0..*

Modelo lógico EHDSDischargeReport 65

Elementos del modelo lógico Xt-EHR con su cardinalidad y obligaciones. Las obligaciones indican a productores y consumidores de los datos qué DEBE o DEBERÍA hacer un sistema con cada elemento.

Obligaciones por actor

Cuántos elementos de EHDSDischargeReport llevan cada obligación para cada actor.

Obligación	Actor	Elementos
`SHALL:able-to-populate`	productor	28
`SHALL:display`	consumidor	6
`SHALL:process`	consumidor	43
`SHOULD:able-to-populate`	productor	32
`SHOULD:display`	consumidor	2
`SHOULD:process`	consumidor	1

Elementos 65

Elemento	Card.	Obligaciones	Descripción
`header`	`1..1`	`SHALL:able-to-populate` productor 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` consumidor EHR systems that consume discharge report SHALL process document header information.	Document header
`subject`	`1..1`	`SHALL:able-to-populate` productor EHR systems SHALL provide information about the subject of care.`SHALL:display` consumidor 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` consumidor 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` productor`SHOULD:display` consumidor`SHALL:process` consumidor	Unique identifier of the document
`author[x]`	`1..*`	`SHALL:able-to-populate` productor`SHALL:display` consumidor	The author of the report.
`date`	`1..1`	`SHALL:able-to-populate` productor`SHALL:display` consumidor	Date of finalising/issuing the document
`status`	`1..1`	`SHALL:able-to-populate` productor`SHALL:display` consumidor	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` productor	Language in which the resource is written. Language is expressed by the IETF language tag.
`documentType`	`1..1`	`SHALL:able-to-populate` productor	Type of the document (e.g. '34105-7 Hospital discharge summary)
`documentTitle`	`1..1`	`SHALL:able-to-populate` productor	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` productor	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` productor`SHALL:display` consumidor	Document attestation details
`attester[x]`	`1..1`	`SHALL:able-to-populate` productor`SHALL:display` consumidor	Attester who validated the document
`datetime`	`1..1`	`SHALL:able-to-populate` productor	Date and time of the approval of the document by Attester
`legalAuthentication`	`0..*`	`SHALL:able-to-populate` productor	Document legal authentication details
`legalAuthenticator[x]`	`1..1`	`SHALL:able-to-populate` productor	The person or organisation taking responsibility for the content of the document.
`datetime`	`1..1`	`SHALL:able-to-populate` productor	Date and time when the document was authorised
`eventType`	`0..*`	`SHALL:able-to-populate` productor	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` productor`SHOULD:display` consumidor	Additional details about where the content was created (e.g. clinical specialty)
`custodian`	`0..1`	`SHALL:able-to-populate` productor	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` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor EHR systems that consume discharge report SHALL process structured information about the encounter.	Section: Encounter information.
`generatedNarrative`	`0..1`	`SHALL:able-to-populate` productor 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` consumidor 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` productor 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` consumidor EHR systems that consume discharge report SHALL process the encounter element of the encounterInformation section.	Encounter information
`note`	`0..1`	`SHOULD:able-to-populate` productor`SHALL:process` consumidor	Free text notes by the health professional
`admissionEvaluation`	`0..1`	`SHALL:able-to-populate` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor`SHALL:process` consumidor	Free text notes by the evaluation performer
`patientHistory`	`0..1`	`SHOULD:able-to-populate` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor`SHALL:process` consumidor	Free text notes by the health professional
`courseOfEncounter`	`1..1`	`SHALL:able-to-populate` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor`SHALL:process` consumidor	Free text notes by the health professional
`dischargeDetails`	`0..1`	`SHOULD:able-to-populate` productor 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` consumidor EHR systems that consume discharge report SHALL process structured information about discharge details.	Discharge details
`generatedNarrative`	`0..1`	`SHOULD:able-to-populate` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor`SHALL:process` consumidor	Free text notes by the health professional
`medicationSummary`	`0..1`	`SHALL:able-to-populate` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor`SHALL:process` consumidor	Free text notes by the health professional
`carePlan`	`0..1`	`SHOULD:able-to-populate` productor 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` consumidor 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` productor 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` consumidor 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` productor 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` consumidor 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` productor`SHALL:process` consumidor	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.

Mapeo de EHDSDischargeReport a FHIR 50

Cómo aterriza cada elemento lógico en FHIR, según lo publicado en la guía de HL7 Europe. Mapeado a: BundleEuHdr, CompositionEuHdr.

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

Documentos CDA (eHDSI)

La misma categoría se transporta en CDA con estas plantillas de documento eHDSI. Su estructura, sus conjuntos de valores y un validador de documentos CDA están en la guía CDA.

eHDSI OrCD Hospital Discharge Report

Fuentes

Reglamento (UE) 2025/327, Diario Oficial de la Unión Europea; guías de implementación FHIR de HL7 Europe; modelos lógicos Xt-EHR (xtehr.eu.ehds.models). Las guías en ballot aún pueden cambiar. Esta guía es informativa: no es asesoramiento jurídico ni una certificación de conformidad.