Wypis ze szpitala w FHIR

Wypis ze szpitala to priorytetowa kategoria Europejskiej Przestrzeni Danych dotyczących Zdrowia (art. 14 ust. 1 lit. (f) rozporządzenia (UE) 2025/327). Stosuje się ją od 26 marca 2031. HL7 Europe obejmuje ją przewodnikami: hdr 1.0.0.

Rozporządzenie: Regulation (EU) 2025/327, Article 14(1)(f), Annex I
Stosuje się od: 26 marca 2031
Przewodniki HL7 Europe: hl7.fhir.eu.hdr 1.0.0, opublikowany
Modele logiczne Xt-EHR: EHDSDischargeReport
Typ dokumentu: LOINC 18842-5 Discharge summaryLOINC 100719-4 Surgical oncology Discharge summary
Walidator: Otwórz walidator profili EHDS

Co mówi rozporządzenie

Załącznik I do rozporządzenia opisuje główne cechy tej kategorii. Tekst jest angielskim oryginałem.

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.

Profile FHIR 33

Profile zdefiniowane przez powyższe przewodniki. Kolumna reguł liczy elementy, w których profil wykracza poza bazowy FHIR (wymagane, zakazane lub ograniczone) i które sprawdza walidator; spośród slice’ów sprawdzane są tylko wymagane, które odróżnia stała wartość lub typ zasobu.

Profil	Zasób	Przewodnik HL7 Europe	Sprawdzane reguły	Slice’y sprawdzane / zdefiniowane
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

Struktura dokumentu

Profile dokumentów tej kategorii: sekcje, które może zawierać Composition, i wpisy, które może zawierać Bundle, tak jak określają je profile. Nazwy to nazwy slice’ów; kod sekcji to kod LOINC ustalony przez profil.

Bundle (HDR): wpisy Bundle 31

Wpis	Licz.	Zasób FHIR	Profil
`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): sekcje 23

Sekcja	Licz.	Kod sekcji	Opis
`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

Powiązania terminologiczne 2

Value sets, z którymi profile tej kategorii wiążą elementy powiązaniem required lub extensible. Powiązanie required dopuszcza tylko kody z value set; extensible oczekuje ich, chyba że żaden nie pasuje. Value sets definiowane w pakietach HL7 Europe są wypisane z kodami w wykazie value sets.

Profile określają też powiązania: preferred – 4, example – 1.

Value set	Powiązanie	Używany przez	Kody
Encounter Status Value Set`http://hl7.eu/fhir/hdr/ValueSet/encounter-status-eu-hdr`	`required`	EncounterEuHdr `status`	kody: 5
Encounter Class Value Set`http://hl7.eu/fhir/hdr/ValueSet/encounter-class-eu-hdr`	`extensible`	EncounterEuHdr `class`	kody: 5

Rozszerzenia 2

Rozszerzenia HL7 Europe, które zawierają profile tej kategorii, z elementem, który je przechowuje.

Rozszerzenie	Kontekst	Wartość	Użyte w
Encounter: Legal Status`http://hl7.eu/fhir/StructureDefinition/encounter-legalStatus`	`Encounter`	złożone	EncounterEuHdr `extension:legalStatus` 0..*
Composition: Information recipient`http://hl7.eu/fhir/StructureDefinition/information-recipient`	`Composition`	`Reference`	CompositionEuHdr `extension:informationRecipient` 0..*

Model logiczny EHDSDischargeReport 65

Elementy modelu logicznego Xt-EHR z licznością i obowiązkami. Obowiązki mówią producentom i odbiorcom danych, co system MUSI lub POWINIEN robić z każdym elementem.

Obowiązki według uczestnika

Ile elementów EHDSDischargeReport niesie dany obowiązek dla danego uczestnika.

Obowiązek	Uczestnik	Elementy
`SHALL:able-to-populate`	producent	28
`SHALL:display`	odbiorca	6
`SHALL:process`	odbiorca	43
`SHOULD:able-to-populate`	producent	32
`SHOULD:display`	odbiorca	2
`SHOULD:process`	odbiorca	1

Elementy 65

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

Odwzorowanie EHDSDischargeReport na FHIR 50

Jak każdy element logiczny trafia do FHIR, według przewodnika HL7 Europe. Odwzorowane na: BundleEuHdr, CompositionEuHdr.

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

Dokumenty CDA (eHDSI)

Tę samą kategorię niosą w CDA te szablony dokumentów eHDSI. Ich struktura, zbiory wartości i walidator dokumentów CDA są w przewodniku CDA.

eHDSI OrCD Hospital Discharge Report

Źródła

Rozporządzenie (UE) 2025/327, Dziennik Urzędowy Unii Europejskiej; przewodniki wdrożeniowe FHIR HL7 Europe; modele logiczne Xt-EHR (xtehr.eu.ehds.models). Przewodniki w ballocie mogą się jeszcze zmienić. Ten przewodnik ma charakter informacyjny: nie jest poradą prawną ani certyfikacją zgodności.