The model is a structured document designed to provide an overview of a patient’s most important health information. The model aims to be compatible with the ISO International Patient Summary standard.

Logical model for medication dispensation (based on a request and dispensed in a pharmacy). Implementers should take into account, if allowed and needed, the calculation of remaining dispensable product based on this information.

Logical model for medication prescription. A prescription contains one or more prescription items (medications).

Model for observation performed by laboratory

Laboratory result report model.

Imaging report reflects the observations and interpretations of one or more imaging studies, contains elements such as the reason why the study is requested, relevant contextual medical information, the modality used to acquire images and its settings, procedures and body localisations that were used, a description of the observations and findings, exposure information, conclusion and advice.

Imaging study model includes the key information about the content of an imaging study. It does not include image pixels but includes location pointers to its image content and organises this information according to the well-established model of an imaging study made of one or more series and each series made of instances or images. Composed of a set of data (DICOM KOS) that facilitates the location of all available images.

A generic, flexible model for any kind of discharge report. Different types of encounters may require adding relevant sections and elements, or omitting irrelevant ones, depending on their data needs.

Obligations for the logical model for allergy intolerance.

Obligations for the logical model for dosage.

Obligations for the logical model for immunisation.

Obligations for the logical model for medication.

Obligations for the logical model for medication dispense for dispensing/pharmacy systems.

Obligations for the logical model for medication prescription body for prescribing systems.

Obligations for the logical model for medication administration.

Obligations for the logical model for medication use.

Obligations for the logical model for observation.

Obligations for the logical model for procedure.

EHDS refined base model for Address structure

Model contains elements needed for registering an individual medication administration. It is derived from the full dosage regimen model in order to keep the consistency between the shared elements.

Healthcare directives concerning life or after life wishes of the patient

A statement higlighting a fact about the patient that requires clinical attention to ensure safety and prevent adverse outcomes. Example 1: intolerance to aspirin due to gastrointestinal bleeding. Example 2: intolerance to captopril because of cough (the patient is not allergic but can't tolerate it because of persistent cough) Example 3: the patient has a rare disease that requires special treatment Example 4: Airway Alert / Difficult Intubation Example 5: Diagnoses such as malignant hyperthermia, porphyria, and bleeding disorders; special treatments like anticoagulants or immunosuppressants; implanted devices. Example 6: transplanted organs illustrate other information that has to be taken into account in a healthcare contact. Example 7: participation in a clinical trial that has to be taken into account in a healthcare contact.

Model for allergy or intolerance.

This model is for containing or referencing attachments - additional data content defined in other formats. The most common use of this type is to include images or reports in some report format such as PDF. However, it can be used for any data that has a MIME type.

Model for body structure

Simplified model for care plan. The model includes minimal information and is not designed to cover the full functionality of care plans. The model is applicable to different domains.

Model for a clinical condition, problem, diagnosis, or other event, situation, or issue that has risen to a level of concern.

Current pregnancy status

Common elements (including header) for all documents and their independently functioning parts, e.g FHIR resources.

Model for device information

Model for information about the use of a device in the care of patient.

Model for common document data elements, including the common header. Data relevant to document type and its content for administrative and searching purposes.

The model covers usage instructions for administering a medicinal product, focusing on the most frequently used data elements. More complex dosage schemes may require additional elements, which should be communicated as part of the rendered dosage instructions element.

The model provides a structured way to capture information about a patient’s interaction with a healthcare service. It enables recording details related to individual encounters and supports linking closely related encounters when needed. Tracking broader or longer episodes of care that extend beyond individual encounters is outside the scope of this model.

Model covers technical details of an endpoint that can be used for electronic services

Model for information about a health professional.

Model for human name

Model describes the administration of immunisation products, including vaccines and immunoglobulins, covering active and passive immunisations. It focuses on immunisation as a clinical procedure rather than the resulting immunity. The model supports routine immunisations at standard doses and may overlap with medication summaries or prescription lists. Natural immunity, immunisation outcomes, refusals, and administration or planning details are out of scope.

Model for details and position information for a place where services are provided and resources and participants may be stored, found, contained, or accommodated.

The model covers details about single medication administrations within the scope of imaging and laboratory procedures.

Logical model for prescribed/dispensed medication. The model is shared by statements, requests, dispensations, and administrations. Each of those may have different restrictions in a FHIR profile. The model is suitable for generic/virtual medications as well as branded/real products. The model aims to have basic alignment with ISO IDMP but it does not cover the full complexity needed for medication registries.

Statement about a single medication as part of a medication summary.

Model for information about an oservation and its results.

Model for information about an organisation

Model for information about a patient (subject of care).

Pregnancy history for one pregnancy

The model provides basic information about a procedure performed on or for a patient. This includes surgical, therapeutic, and diagnostic procedures, as well as specimen collection. The model does not cover procedures in the planning stage.

Model for information about a guardian or other person related to the subject of care

The model covers details about a requested service or services. One order may include several requests.

Model for a specimen to be used for analysis

Model for communication contact information.

Relevant information about the patient's recent travel history, for one visit

A system that receives electronic health data originating from another system and processes or displays that data. In this role, the system is responsible for ingesting and validating the received data and for preserving the meaning, structure, and associated metadata of the information in accordance with the applicable Consumer obligations, ensuring correct interpretation and presentation to end users or other systems.

A system that generates or makes available structured electronic health data for exchange. In this role, the system is responsible for being technically capable of populating the relevant data elements in accordance with the applicable “able-to-populate” obligations and for associating the required metadata, such as authorship, provenance, status, and temporal information, before the data are made available to downstream systems.