EHDS Logical Information Models
0.1.0 - ci-build

EHDS Logical Information Models, published by Xt-EHR. This guide is not an authorized publication; it is the continuous build for version 0.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/Xt-EHR/xt-ehr-common/tree/stakeholder-consultation-D6-1 and changes regularly. See the Directory of published versions

## Artifacts Summary

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

### EHDS Patient Summary Logical Models

Information Models for implementing EEHRxF Patient Summary under EHDS. Format based on ISO 13972 "Health informatics — Clinical information models — Characteristics, structures and requirements."

Patient summary model | EHDS refined base model for Patient Summary

### Structures: Logical Models

These define data models that represent the domain covered by this implementation guide in more business-friendly terms than the underlying FHIR resources.

Address model | EHDS refined base model for Address structure
Advance directive model | Healthcare directives concerning life or after life wishes of the patient
Alert flag model | Alert flag
Allergy intolerance model | EHDS refined base model for allergy/intolerance
Appointment model | EHDS refined base model for Appointment. This is a simplified model with minimal information - it is not intended to cover the full functionality of booking systems.
Attachment model | EHDS refined base model for This type 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.
Body structure model | EHDS refined base model for Body structure
Care plan model | EHDS simplified model for care plan. The model includes very minimal information and is not designed to cover the full functionality of care plans.
Condition model | Health conditions affecting the health of the patient and are important to be known for a health professional during a health encounter.
Coverage model | EHDS refined base model for Coverage
Current pregnancy status model | Current pregnancy status
DataSet model | Common elements (including header) for all documents and their independently functioning parts, e.g FHIR resources.
Device model | EHDS refined base model for Device information
Device use model | EHDS refined base model for device use information
Document model | EHDS refined base model for common document data elements, including the common header. Data relevant to document type and its content for administrative and searching purposes.
Dosaging model | Logical model for usage instructions for administring the requested product. Based on FHIR Dosage complex data type. When implemented, this model may be reduced significantly according to the specific use case.
Encounter model | C.30 - EHDS refined base model for Encounter
Endpoint model | C.33 - EHDS refined base model for Endpoint
Episode of care model | C.29 - EHDS refined base model for Episode of care
Functional status | EHDS refined base model for Functional status
Health professional model | EHDS refined base model for Health professional (HP)
Human name model | C.27 - EHDS refined base model for Human name
Imaging study model | C.32 - EHDS refined base model for Imaging study
Immunisation model | EHDS refined base model for Immunisation
Laboratory observation model | EHDS refined base model for Observation performed by laboratory
Location model | EHDS refined base model for Details and position information for a place where services are provided and resources and participants may be stored, found, contained, or accommodated.
Medication | Logical model for prescribed/dispensed medication. The model is shared by statements, requests, dispensations, and treatment lines. Each of those may have different restrictions in FHIR profile.
Medication Statement | Statement about a single medication as part of a medication summary.
Medication administration model | EHDS refined base model for medication administration
Medication dispense decline model | Explicit statement about declining the dispense request (prescription), usually recorded in order to communicate the issue back to the prescriber. Reasons for declining a dispense may vary, but typically this statement is only sent when a following action is expected on the prescriber’s side (cancelling or changing the problematic prescription or the whole treatment).
Medication dispense model | Logical model for medication dispensation (based on request or independently)
Medication prescription model | Logical model for medication prescription. A prescription contains one or more prescription items.
Observation model | EHDS refined base model for Observation information
Organisation model | C.3 - EHDS refined base model for Health provider or any other type of organisation
Patient Animal model | C.41 - EHDS refined base model for Patient:Animal
Patient model | C.1 - EHDS refined base model for Patient/subject information
Pregnancy history model | Pregnancy history for one pregnancy
Procedure model | EHDS refined base model for an action that is or was performed on or for a patient
Related person model | EHDS refined base model for Patient/subject guardian and other related person information
Service request model | C.8 - EHDS refined base model for Specification of requested service or services
Social history model | EHDS model for social history observations
Specimen model | C.9 - EHDS refined base model for A sample to be used for Analysis
Substance model | C.28 - EHDS refined base model for Substance
Telecom model | C.6 - EHDS refined base model for Telecommunication contact information structure
Travel history model | Relevant information about the patient's recent travel history, for one visit

### Example: Example Instances

These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.

Summary Consumer | This actor consumes a patient summary.
Summary Provider | This actor provides a patient summary - unsollicited or upon request. It may create the summary or use a previously acquired summary.