Page tree
Skip to end of metadata
Go to start of metadata
Document status date

May 26, 2020 15:54

Document author
eHDSI Business Analyst
Source document(s)PS Functional requirementseP Functional requirements

Page History (main updates):

Page VersionDateAuthorShort description of changes


eHDSI Business AnalystDeletion of all references to Waves. This page is applicable to all waves, in production as well as in development.


eHDSI Business AnalystUpdated the page with the business goals for eHDSI and their related business requirements.


eHDSI Business AnalystMoved the in scope/out of scope activities specific to the Business Analysis and Requirements Management service to the Approach page.

eHDSI Business Analyst

First version. Content ready to be reviewed by the eHDSI stakeholders.

Goal of the current page

  • Describe the business goals for eHDSI and classify them by type. One or several business goals can be linked with one or several business requirements.   
  • Describe the scope of eHDSI, with focus on what is out of scope for the current version of eHDSI. In terms of content, the information was taken from the eHDSI Functional Requirements documents. The Business Analysis and Requirements Management scope/out of scope items were added to the Approach page of this service. 

eHDSI Business Goals

The following table presents an overview of the business goals. The business requirements are linked to one or several business goals. 

1Health Professional (HP) IdentityEnsure that the HP identity is certainEnsure Health Professional (HP) Identification, Authentication and Authorization
2Patient IdentityEnsure that the patient's identity is certainEnsure Patient Identification
3TrustEnsure trust between countriesEnsure Health Professional (HP) Identification, Authentication and Authorization
4InteroperabilityEnable the exchange of health data between countries
5Processing of personal data
  • Manifest the legal foundation for a lawful processing of personal data
  • Grant the patient his/her specific rights according to data protection regulations

Ensure lawful processing of personal data
6Patient safety and security of health data
  • Ensure the availability of the PS in Country of affiliation

  • Correctly identify the prescription to be dispensed
  • Avoid problems of different prescription validity periods in Country of affiliation and in Country of treatment

  • Correctly identify the medicinal product that has to be dispensed
  • Ensure access to information from the original prescription
  • Inform the health professional in the Country of affiliation about the dispensed medicine
  • Update the already dispensed prescription with the new status and information about the dispensed medicine, so that the same medicine/prescription cannot be dispensed multiple times

  • Provide the HP with the necessary information to deliver safe care or to safely dispense to the patient

  • Guarantee the safety of the patient through a proper understanding of the received information (by both HP and patient)
  • Ensure safe delivery of care to patients through the exchange of correct meanings between systems and between systems and people

  • Reduce time in searching for necessary information to provide healthcare to the patient
  • Facilitate the later processing of the information to assure its comprehension through semantic tools, systems of codification or of translation according to eHDSI solution
7Service Confidentiality
  • Protect and safeguard the exchanged health data (including secure access to such data)
  • Ensure the involved HP to be fully compliant with their professional code
  • Identify the parties participating to the communication in both countries
  • Ensure secure communication means between National Contact Points
  • Avoid patient withdrawing the same medicine at the exact time from different pharmacies
Ensure confidentiality of the service
8Data Integrity
  • Guarantee the integrity of the exchanged health data by transmission of unaltered clinical documents

  • Enable detection of any damage, reduction or alteration of the exchanged clinical data

Ensure the integrity of the exchanged data
9Service AvailabilityEnsure the availability and avoid degradation of the service.
Ensure Service Availability
10Service Performance
  • Ensure the eHDSI services are performing according to the agreed key performance indicators
Ensure Service Performance
11Data traceability, auditability and non-repudiation
  • The session and the information exchanged must be associated with secured data allowing afterwards verification

  • Enable a transparent and reconstructable ('able to be reconstructed') system operation
  • Document compliance and legitimacy of data accesses
  • Make the eHDSI services auditable
  • Guarantee that the issuer of the information agreed to be exchanged cannot refuse that the issuance has taken place
  • Guarantee the complete delivery of the service (ensure the exchanged health data have been properly received by the other country)

Ensure traceability, auditability and non-repudiation of the exchanged data

eHDSI IN SCOPE description




1.Patient Summary (PS)

At European level, it has to be assumed that the patient may have more than one electronic PS, in one or many countries, made available abroad in a structured way compliant with eHDSI PS specification.

But, in the current version of eHDSI, only one common structured eHDSI PS per country will be provided. The current approach is that only the PS of country A will be shown to the HP of Country B.

2.ePrescription (eP)The prescriptions considered for the eHDSI are medicinal products intended for human use, elaborated from an industrial process, prescribed for out-patients (not to be dispensed in the Hospital), and dispensed in Community Pharmacies. These medicinal products must be produced by a registered pharmaceutical manufacturer and hold a current 'marketing authorization' (licence).ALL

eHDSI OUT OF SCOPE description



1ALLA single (unique) stored European Patient Summary.ALL

Planned healthcare.

  • eHDSI only addresses the unplanned, unscheduled or emergency health care events.

Providing the Health Professional in Country B with all the related health information of the patient, such as for instance: complete electronic patient record, all health encounters, all laboratory tests, all X-rays exams etc).

4ALLManagement of the authentication process of the Health Professionals in their systems.ALL
5ALLManagement of the identification/authentication/authorization process of the patient.ALL

Ensure Consent Management by deciding on whether a certain request for data is legitimated by the consent of the patient.


New item added as out of scope, because each MS needs to analyse their specific legislation as concerns consent management, in accordance with GDPR and the exceptions foreseen by their national laws (where applicable). It is MS decision if they need consent or they have other (legal) basis for processing citizens' personal/health data, as well as how they should manage their responsibilities related to data protection.  

7Patient Summary

Transfer of clinical information from Country B to Country A.

  • Therefore, it is out of scope of eHDSI that Country B sends a record of the Health Care encounter to Country A. No other electronic clinical documents (such as patient health encounters, electronic health records etc.) will be made available through eHDSI, apart from the agreed clinical documents to be exchanged (Patient Summary and ePrescription/eDispensation).
8Patient SummaryThe additional use case ADD_Handle Patient's access to existing Patient Summaries is out of the current eHDSI scope. This use case refers to the possibility for the patient to access his/her Patient Summary, transcoded and translated in the language of the health professional in the country of treatment.ALL
9Patient Summary

Providing several Patient Summaries of the same patient to Country B.

  • Use cases and functional requirements are described with the approach that the HP of Country B accesses only one PS of Country A. This option is indicated in the PS Guidelines in order to reduce the number of PSs belonging to one single patient as, in some countries, one patient can have more than one PS (e.g.: one PS per region). This is because it was perceived that it is not possible to define a set of rules to decide the prevalence of the clinical information in the process of its integration: integrating information from many different Summary documents can therefore produce a less useful document with a lot of complementary, redundant or similar information regarding the same issue (e.g.: allergy to betalactamics, allergy to antibiotics, allergy to penicillin, rash due to penicillin etc.).
  • Nevertheless, the approach ’Multiple Patient Summaries’ (meaning that the HP gets access to the list of existing PSs for that patient and selects and asks for any of them) is presented in the additional use case ADD_Handle multiple Patient Summaries, for information purposes and in preparation of a possible future eHDSI scope extension, but not included in the current technical implementation of the eHDSI.
10Patient SummaryIt is out of scope in eHDSI other potential use of the PS information (e.g.: public health, epidemiology, health management, etc.).ALL

The additional use case ADD_Handle Health Professional's (HP) access to the current ePrescriptions is out of the current eHDSI scope. This use case refers to the possibility for the health professional (the dispenser) to consult the current prescriptions of the patient.

12ePrescriptionThe additional use case ADD_Handle the medicine newly prescribed in Country B is out of the current eHDSI scope. This use case refers to the possibility of prescribing medicine(s) in a country (B) when the patient comes from a different country (A) where he/she has a valid identification in terms of health care. ALL

Sealed prescriptions (or information): The decision of a patient to hide information (e.g. prescriptions or diagnosis related to HIV) is part of each country’s process.  This document will not cover or solve the scenario where the patient goes to country B and decides to authorise the HP in that country to consult the hidden information.


Precautionary cancellation: The dispenser might decide s/he is unable to safely dispense a medicine and cancel the prescription temporarily, until the prescriber revises the prescription. As this is a process not implemented in every country, it is currently out of the scope of eHDSI.  

15ePrescriptionPharmaceutical care: It cannot be assured that for the eHDSI, all the information needed for correct or proper Pharmaceutical care will be available. It is assumed that medication surveillance, as part of the pharmaceutical care, will be covered by other processes in the country where health care within the context of eHDSI is given. However, it is recommended that the current prescriptions could be accessed by the pharmacist.ALL

Narcotics: They have specific legislation and are too complicated to deal with at this stage.


Substitution of active ingredient, strength and/or pharmaceutical dose form: as countries have different legislation regarding this topic and it is a complicated matter to solve for the eHealth DSI, substitution will include the simplest possibilities with the lowest impact for patient safety namely brand name and package size.


Medicinal products which are prepared in a pharmacy in accordance with a medical prescription for an individual patient (commonly known as the ‘magistral formula’ or extemporaneous preparations) or those prepared in a pharmacy in accordance with the prescriptions of a pharmacopoeia and intended to be supplied directly to the patients served by the pharmacy (commonly known as the ''officinal formula'' or ''extemporaneous preparations'').


It is out of the eHDSI scope to send back (from Country B to Country A), a copy of the original medicine dispensed (PDF).

Original dispensed medicine:

DescriptionCountry A will also need to know the original dispensed medicine in Country B (but not translated to an equivalent one in Country A) and the one in the eHDSI semantic format to verify the active ingredient dispensed (as in most cases, the same medicinal product does not exist).
Associated Goals
  • For  safety  and  security  reasons  as  the  brand  name  of  the  product  is probably going to be changed.  If the patient withdraws a different medicine and when taking it, he has adverse reaction, the Country A HP will be able to diagnose based on the information on what it was originally prescribed and what the patient has actually taken
  • Traceability reasons
  • Dispense provider
  • NCPs

  • No labels


  1. What about Core services like SMP/SML, Terminology server... ? Are they in scope ?

    1. Yes, but the core services are part of the eHDSI Service offering provided by the Solution Provider ( and for this reason they are not mentioned here. We are referring in this case to the use cases covered by eHDSI (Patient Summary and ePrescription/eDispensation), also known as ''eHDSI services''.

  2. It's important to have a link from the requirements (located under eHDSI SERVICE OFFERING) to this page. I was just trying to look for something in the requirements which was in fact written here. Simona-Maria TIPLEA Frederic BULCKAEN

    1. Thank you for the comment Joao. Indeed, this page has now been moved under eHDSI SERVICE OFFERING, as an introduction page to the Requirement Catalogue.