Generated Narrative: StructureDefinition MyHealthEuHdrDischargeReport Name Flags Card. Type Description & Constraints MyHealthEuHdrDischargeReport 0..* EHDSDischargeReport MyHealth@EU Hospital Discharge Report model Elements defined in Ancestors:header, header, presentedForm, body, attachments #xD; header #xD; subject O 1..1 MyHealthEuPatient Patient/subject information Obligations Actor SHALL:handle HDR Handler #xD; identifier O 1..* Identifier Unique identifier of the document Obligations Actor SHALL:handle HDR Handler #xD; author[x] O 1..* The author of the report. Obligations Actor SHALL:handle HDR Handler #xD; authorMyHealthEuHealthProfessional MyHealthEuHealthProfessional #xD; authorMyHealthEuOrganisation MyHealthEuOrganisation #xD; authorMyHealthEuDevice MyHealthEuDevice #xD; date O 1..1 dateTime Date of finalising/issuing the document Obligations Actor SHOULD:handle HDR Handler #xD; status O 1..1 CodeableConcept Status of the document Obligations Actor SHALL:handle HDR Handler #xD; language O 0..1 CodeableConcept Language in which the resource is written. Language is expressed by the IETF language tag. Obligations Actor SHALL:handle HDR Handler #xD; documentType O 1..1 CodeableConcept Type of the document (e.g. '34105-7 Hospital discharge summary) Obligations Actor SHALL:handle HDR Handler #xD; documentTitle O 1..1 string Title of the document, possibly autogenerated from the structured fields (e.g. 'Hospital discharge report. Jane Green. 07.10.2025-10.10.2025') Obligations Actor SHALL:handle HDR Handler #xD; version O 0..1 string Business version of the document. The exact algorithm for versioning is decided by the producer/custodian Obligations Actor SHOULD:handle HDR Handler #xD; attestation O 0..* Base Document attestation details Obligations Actor MAY:able-to-populate HDR Handler #xD; attester[x] O 1..1 Attester who validated the document Obligations Actor SHOULD:handle HDR Handler #xD; attesterMyHealthEuHealthProfessional MyHealthEuHealthProfessional #xD; attesterMyHealthEuDevice MyHealthEuDevice #xD; datetime O 1..1 dateTime Date and time of the approval of the document by Attester Obligations Actor SHOULD:handle HDR Handler #xD; legalAuthentication O 0..* Base Document legal authentication details Obligations Actor SHALL:handle HDR Handler #xD; legalAuthenticator[x] O 1..1 The person or organisation taking responsibility for the medical content of the document (typically the person who signs it) Obligations Actor SHOULD:handle HDR Handler #xD; legalAuthenticatorMyHealthEuHealthProfessional MyHealthEuHealthProfessional #xD; legalAuthenticatorMyHealthEuOrganisation MyHealthEuOrganisation #xD; datetime O 1..1 dateTime Date and time when the document was authorised Obligations Actor SHOULD:handle HDR Handler #xD; custodian O 0..1 MyHealthEuOrganisation Organisation that is in charge of maintaining the document/report. Obligations Actor SHOULD:handle HDR Handler #xD; intendedRecipient[x] O 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. Obligations Actor MAY:able-to-populate HDR Handler #xD; intendedRecipientMyHealthEuPatient MyHealthEuPatient #xD; intendedRecipientEHDSRelatedPerson EHDSRelatedPerson #xD; intendedRecipientMyHealthEuHealthProfessional MyHealthEuHealthProfessional #xD; intendedRecipientMyHealthEuOrganisation MyHealthEuOrganisation #xD; body O 0..1 Base Structured body of the discharge report document Obligations Actor SHALL:handle HDR Handler #xD; alerts O 0..1 Base Section: Alerts. Obligations Actor MAY:able-to-populate HDR Handler #xD; medicalAlert O 0..* MyHealthEuHdrAlert Description of medical alerts in textual format: any clinical information that is imperative to know so that the life or health of the patient does not come under threat. Obligations Actor MAY:able-to-populate HDR Handler #xD; encounterInformation O 1..1 Base Section: Encounter information. Obligations Actor SHALL:handle HDR Handler #xD; encounter O 0..1 MyHealthEuHdrEncounter Encounter information Obligations Actor SHALL:handle HDR Handler #xD; admissionEvaluation O 0..1 Base Section: Admission evaluation. Admission evaluation section should be reported only if it is relevant to ensure continuity of care. Obligations Actor MAY:able-to-populate HDR Handler #xD; objectiveFindings O 0..* MyHealthEuHdrObservation Objective findings, such as anthropometric measurements, vital signs, or objective anatomical findings of physical examination Obligations Actor MAY:able-to-populate HDR Handler #xD; functionalStatus[x] O 0..* An individual's ability to perform normal daily activities required to meet basic needs, fulfil usual roles and maintain health and well-being Obligations Actor MAY:able-to-populate HDR Handler #xD; functionalStatusMyHealthEuHdrCondition MyHealthEuHdrCondition #xD; functionalStatusMyHealthEuHdrObservation MyHealthEuHdrObservation #xD; patientHistory O 0..1 Base Section: Patient health history (anamnesis) containing only information that is highly relevant for this specific episode of care. The model is designed with the expectation that patient summary is available. Obligations Actor MAY:able-to-populate HDR Handler #xD; courseOfEncounter O 0..1 Base Course of inpatient or outpatient encounter. Obligations Actor SHALL:handle HDR Handler #xD; diagnosticSummary O 0..* MyHealthEuHdrCondition Problems that were treated or affected provisioning of care (diagnostics, therapy, nursing, monitoring) during the encounter. At least one treated problem should be marked. Other problems are recorded only if they are important for continuity of care (after discharge). Obligations Actor SHALL:handle HDR Handler #xD; procedures O 0..* MyHealthEuHdrProcedure Procedures performed during encounter which are significant for continuity of care, e.g. surgeries and other instrumental interventions (endoscopic, intravascular), chemotherapy, radiotherapy, purification methods (dialysis, hemoperfusion), circulation support methods (counterpulsation, etc.), administration of blood derivatives or others. Diagnostic procedures are typically captured as observation results and not repeated here. Obligations Actor MAY:able-to-populate HDR Handler #xD; medicalDevicesAndImplants O 0..* MyHealthEuHdrDeviceUse Medical devices (including implants) whose use was started, stopped, or otherwise modified during the encounter. Obligations Actor MAY:able-to-populate HDR Handler #xD; pharmacotherapy O 0..* MyHealthEuHdrMedicationUse Significant medication treatments during encounter. The content of this section may be repeated in the medication summary for full overview of patient's medications. Obligations Actor MAY:able-to-populate HDR Handler #xD; dischargeDetails O 0..1 Base Discharge details Obligations Actor MAY:able-to-populate HDR Handler #xD; objectiveFindings O 0..* MyHealthEuHdrObservation Objective findings, such as anthropometric measurements, vital signs, or objective anatomical findings of physical examination Obligations Actor MAY:able-to-populate HDR Handler #xD; functionalStatus[x] O 0..* An individual's ability to perform normal daily activities required to meet basic needs, fulfil usual roles and maintain health and well-being Obligations Actor MAY:able-to-populate HDR Handler #xD; functionalStatusMyHealthEuHdrCondition MyHealthEuHdrCondition #xD; functionalStatusMyHealthEuHdrObservation MyHealthEuHdrObservation #xD; medicationSummary O 0..1 Base Summary information on the medication recommended for the period after discharge, indicating whether the medication is changed or newly started. Compared to previous practices, the overview is supplemented with medication that has been discontinued. Obligations Actor MAY:able-to-populate HDR Handler #xD; medicationUse O 1..1 MyHealthEuHdrMedicationUse Details about medication and dosage Obligations Actor MAY:able-to-populate HDR Handler #xD; carePlan O 0..1 Base Care plan and other recommendations after discharge. Obligations Actor MAY:able-to-populate HDR Handler #xD; carePlan O 0..* MyHealthEuHdrCarePlan Structured care plan after discharge. Multiple care plans could be provided. Obligations Actor MAY:able-to-populate HDR Handler #xD; attachments O 0..* EHDSAttachment Report attachments. Implementations may define what kind of attachments are allowed and may ignore unexpected attachments for security reasons. Obligations Actor MAY:able-to-populate HDR Handler #xD; Documentation for this format
MyHealth@EU Hospital Discharge Report model
MyHealthEu refined model for hospital discharge report.
Business identifier for the object, unique within its system. Supporting disambiguation between different contexts (systems/countries).
Date and optionally time of authoring/issuing
Source of information (e.g. patient, patient's proxy). Used in case the patient has authored the information or the author has submitted patient-stated information.
Language in which the resource is written. Language is expressed by the IETF language tag.
Type of the document (e.g. '34105-7 Hospital discharge summary)
Title of the document, possibly autogenerated from the structured fields (e.g. 'Hospital discharge report. Jane Green. 07.10.2025-10.10.2025')
Time of service that is being documented (typically the same as the time/period of encounter)
Time of service that is being documented
Business version of the document. The exact algorithm for versioning is decided by the producer/custodian
Date and time of the approval of the document by Attester
The person or organisation taking responsibility for the medical content of the document (typically the person who signs it)
Date and time when the document was authorised
Categorisation of the event covered by the document (e.g. laboratory study types, imaging study types including modality, etc.). Selection of such tags or labels depends on the use case and agreement between data sharing parties. This meta-data element serves primarily for searching and filtering purposes.
Additional details about where the content was created (e.g. clinical specialty)
Organisation that is in charge of maintaining the document/report.
A narrative easy-to-read representation of the full data set, e.g. PDF-version of a document
Intended recipient(s) of the information, i.e. a person or organisation that should be notified or be aware of the content. This element is used to indicate explicit communication intent and does not represent routine storage or passive availability of information (e.g. in portals). Listing an intended recipient does not create an assignment or responsibility.
Structured body of the discharge report document
Information about substantial alerts or warnings (including allergies) that health professionals should be aware of.
Narrative, potentially formatted, content of the whole section.
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.
Free text notes by the health professional
Section: Admission evaluation. Admission evaluation section should be reported only if it is relevant to ensure continuity of care.
Objective findings, such as anthropometric measurements, vital signs, or objective anatomical findings of physical examination
An individual's ability to perform normal daily activities required to meet basic needs, fulfil usual roles and maintain health and well-being
Free text notes by the evaluation performer
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.
Narrative, potentially formatted, content of the whole section. In case the section includes structured information, it should also be included in generatedNarrative.
Course of inpatient or outpatient encounter.
Problems that were treated or affected provisioning of care (diagnostics, therapy, nursing, monitoring) during the encounter. At least one treated problem should be marked. Other problems are recorded only if they are important for continuity of care (after discharge).
Procedures performed during 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.
Medical devices (including implants) whose use was started, stopped, or otherwise modified during the encounter.
Significant medication treatments during encounter. The content of this section may be repeated in the medication summary for full overview of patient's medications.
Objective findings, such as anthropometric measurements, vital signs, or objective anatomical findings of physical examination. The line between objective findings and test results is not clear and it is up to the implementers to decide how to logically display different measurements.
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.
Structured information should be provided, however if not available, at least a section narrative should be present.
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.
Care plan and other recommendations after discharge.
Structured care plan after discharge. Multiple care plans could be provided.
Other recommendations (advice) after discharge. E.g., recommendation to suggest hip replacement, reduce number of cigarettes, stop smoking, increase physical exercises, etc.
Clinical synthesis (e.g. description of reasons and course of encounter) clustered by managed conditions. Clinical synthesis may include clinical reasoning (differential diagnostics, explanation of clinical context) in clinically complex conditions.
Report attachments. Implementations may define what kind of attachments are allowed and may ignore unexpected attachments for security reasons.