; UseCases_LSP
Learning Center
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>



  • pg 1
									                        EUROPEAN COMMISSION
                        Information Society and Media Directorate-General

                        ICT for Citizens and Businesses
                        ICT for Health

                                                                    Brussels, 27 February 2007
                                                                    DG INFSO H1 (2007)

Subject: Reflection on possible use cases for the Call for the Large Scale Pilot in eHealth
'EU wide implementation of eHealth services to support continuity of care: patients'
summaries and ePrescription solutions1.


The Large Scale Pilot in the eHealth domain will be launched in the first quarter of 2008 and
will be operational for 36 months. This Large Scale Pilot will consist of two sub-pilots which are
titled 'EU wide implementation of patients' summaries/Emergency Data Set to support continuity
of care' and „EU wide implementation of ePrescription solutions to support continuity of care').
The two sub-pilots will be based on existing developments in Member States and on an agreed
architecture and common basic modules. From here onward, 'Large Scale Pilot' is referred to
simply as 'Pilot'. The Pilot will propose a method of involving the users of the system/service and
the health authorities in defining the use cases and the definition, the purpose of the Pilot based
on the Pilot objectives, and on standards or existing recommendations at EU and international
level for the two topics included in the Pilot 'EU wide implementation of eHealth services to
support continuity of care: patients' summaries and ePrescription solutions.

An Emergency Data Set should be understood as a minimum set of data about a patient which
would allow the relevant healthcare providers to address a particular emergency situation, and/or
provide continuity of care in another country or in any other case where unscheduled care is
needed outside the home country or region of the patient.

For ePrescription solutions, the sub-pilot will identify and characterise the three basic
components of the overall services (that are involved in the cross-border aspect of the
ePrescribing application), namely:

- Electronic medication records.

- Informed prescribing with decision support.

- Electronic transmission of prescription.

The sub-pilot on ePrescription should focus at least on Electronic medication records (see also
footnote 1).

The Pilot proposal will indicate the scope of the data items to be shared, with a detailed
description of how the scope and structure of these will be agreed. Where necessary, the

    ePrescription solutions should be understood as a set of at least three types of applications, namely
     electronic medication records, decision support systems, electronic transmission of prescriptions. The
     Pilot shall cover at least both electronic medication records and electronic transmission of prescription.

Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) 299 11 11.
Office: BU31. Telephone: direct line (32-2) 2998965. Fax: (32-2) 2960181.

E-mail: Octavian.Purcarea@ec.europa.eu
structure should allow for optional data items (since not all Member States can necessarily
provide all the items).

The text which follows identifies the orientations suggested by the expert group on eHealth
interoperability³ as guidance for the building of the use-cases for the content of the Pilot
proposal following discussions with this group.

Preliminary observations:

The two sub-pilots must define situations for the use of four cases to support continuity of care:
the Emergency Data Set, Patient summaries, Electronic Medication Record, and ePrescription.

These situations must represent real user needs, and must illustrate credible situations of either
unexpected or unscheduled care events where the use of Information and Communication
Technologies (ICT) are intended to ensure continuity of care.

The use cases should clearly depend on small-scale events (as described in this document) and
must show that the use of technology (or technologies) is actually needed. They must show
immediate benefits in terms of both qualitative and quantitative results.

The technology or technologies used in the two sub-pilots must be readily accessible both off-
line and on-line, comprehensive, and displayable in a user-friendly manner.

The use cases should allow for a better understanding of the need for ICT in the two sub-pilots
by the various actors involved. They should also define the relevant information needed,
describe the flow of information involved, and reveal the different communication needs. The
various reimbursement issues which could be related to the use of technologies under these
circumstances will not be covered in these use cases.

These use cases should be detailed. However they may be enhanced further during the Pilot

Typology of use cases:

The use cases could be divided into two categories, depending on the scale of the event: small-
scale and large-scale events.

Examples of small-scale use events are the kinds of accident that implicate healthy persons who
are travelling abroad for purposes of work, study or tourism; or events that occur to a person who
has a chronic condition or who has a special condition (e.g., pregnancy) who is travelling across

Accidents can implicate a healthy person who has various risk factors (e.g., an allergy, genetic
disease, or who is implanted with some form of medical device) or a patient with a chronic
disease who is travelling abroad. In this case, the availability of the appropriate emergency
medical data or a patient summary could shorten the time to diagnosis, avoid redundant
examination, orient the diagnosis more appropriately, or help avoid medical error. Here, there is
an immediate perceived benefit in terms of the quality of care and reduction in costs through the
avoidance of redundant examination and removal of possible errors.

In the case of chronic diseases, the patient may face the need to refill prescriptions or replace
lost drugs while travelling abroad. Moreover, such a patient could face an acute episode that is
triggered by a particular condition (e.g., in extreme climate conditions, with prolonged effort, or
when travelling long distance. An example of such a use case is attached in annex (see annex 1).

Specific conditions (e.g., pregnancy) can predispose a person to a high frequency of medical
encounters which are not scheduled or expected.
                                    DRAFT version 27/02/2007                                     2
In the case of a large-scale event (e.g., an infectious outburst, a terrorist attack, a plane crash, a
military combat operation, or a large-scale natural or human disaster such as extreme climate
change or strong winds), the need for rapid information is essential to facilitate orientation of the
emergency team, triage of patients, and the outcome of the treatment required. In this particular
case, the information system that is generally used could be damaged and alternatives (such as
off-line solutions, portable and satellite devices) could be foreseen. It should be noted that,
during its meeting on 17 January 2007, the eHealth Interoperability Expert Group expressed,
however, its preference to include only small-scale use cases in the Pilot.

Details of use cases:

For the purpose of the sub-pilots, accidents can be defined as unexpected events that involve
healthy persons (who may be subject to health risk factors) that are travelling in a country other
than their own or persons who experience a chronic disease. Such events could be traumatic,
infectious or poisonous in nature. In this use case (accidents), the existing risks: e.g., allergies,
genetic diseases which are not immediately apparently (such as haemophilia) can delay medical
intervention or can predispose a patient to medical errors. The use of an Emergency Data Set or
patient summary can give timely and appropriate information to the health professional involved
in the event about the patient's medical history and health risks, and can speed up the delivery of
both diagnosis and treatment.

The actors involved in such use cases could be, for example, the members of a 112 call centre, an
emergency team, an ambulance team, the inpatient unit in a hospital, or an intervention unit.

A key notion in this case is that of quick access to vital information (such as patient
identification, orientation of the care team, blood type, existing allergies and risks, implants,
current medication, existing chronic diseases).

At the level of a Call Centre the access to Emergency Data Set or a Patient summary can allow
remote identification of the patient based on information received from on–site witnesses. This
would be possible after proper authentication of the care provider and access to Emergency Data
Set/Patient summary. The information accessed in the Emergency Data Set/Patient summary
about current diseases, treatment, allergies could provide prior orientation for the emergency
team before arrival at the event site.

At the point of intervention, the emergency team could use auto-powered devices, that are
connecting wirelessly, and that are providing vital information at the point of care or in the
ambulance. These devices could allow the identification of the patient and authentication of the
care provider followed by access to a Emergency Data Set/ Patient summary that is collected
from distributed sources. The treatment could be performed on-site (emergency treatment) based
on the information that has been collected.

As an example, the haemophilic patient who does not speak the local language (or is
unconscious) following a car accident could be properly identified, as could the precise nature of
his or her disease The information collected from his/her Emergency Data Set/ Patient summary
would help orientate the treatment to be offered more rapidly and shorten the interval to
additional laboratory tests.

Once he or she has arrived as the hospital, the patient could be appropriately examined and
treated since information from the Emergency Data Set/Patient summary is immediately known
about his/her current treatment, allergies, health history, health risks and other details, such as
prior dental treatment.

This information could enable appropriate care, help avoid unnecessary examination and tests
(including duplication of some tests). During this particular episode, the Emergency Data
Set/Patient summary of the patient should be updated and health professional access to the
patient information should be recorded in an audit trail.

                                     DRAFT version 27/02/2007                                       3
A patient with a chronic disease (who may each year have several medical examinations,
regular laboratory tests, several drugs administered, and be followed by different teams of health
practitioners) may need to refill his or her prescriptions or have replacement treatment while
travelling across Europe. Alternatively, such a patient could face an acute episode that is
triggered by a particular condition (such as climate conditions, intense physical effort).

In the event of the need to refill prescription or replace the loss of a drug (for example – a
diabetic patient or a cardiac patient might lose, forget, or finishing his/her treatment) while
travelling across Europe, such a patient could receive his or her refill in any pharmacy in any
other country or region where s/he can be identified and where his or her Medication Record can
be accessed.

The access to his or her Medication Record from Patient summary can allow the refill of a
prescription, and thus ensure continuity of care. A translation service could identify on-line the
drug based on the DCI (Dénomination Commune Internationale) and suggest the local drug for
refill when travelling abroad. These actions however pose challenges related to regulatory issues,
the trans-national identification of patients, authentification of health professionals who may
access the Medication Record, and recognition and acceptance of prescriptions from the Member
States. These specific aspects will certainly be raised in discussion and greater detail during the
application of the two sub-pilots.

Alternatively, the patient who is travelling abroad could consult a doctor who is on call in
another country. Due to the availability of the Emergency Data Set/Patient Summary; the
physician could then have available to him/her a rapid overview of the patient's history and
condition and adapt/refill the prescriptions, thereby enabling continuity of care.

Ideally, the prescriptions should be available at the closest pharmacy or the pharmacy of choice
of the particular patient.

In the case of a chronic patient travelling abroad who experiences an acute episode that is
triggered by particular conditions (e.g., an acute episode of adrenal insufficiency started as a
result of extremely hot weather) the ICT support could contribute at several steps of the patient

The Call Centre involved could identify the patient and his/her chronic disease based on the
identification provided by witnesses or by the emergency team. The access to Emergency Data
Set/ Patient Summary could provide the patient's current diagnosis, his/her ongoing treatment,
health history, various examination results. Such information is essential for avoiding medical
errors, duplication of tests, and delays in arriving at both diagnosis and treatment.

The patient could be quickly assessed at the point of care or at the hospital, and further
examination could be performed (such as a physical examination, laboratory tests, radiological
examination). The data from the Emergency Data Set/ Patient Summary or Medication Record
could help orientate the diagnosis.

The new medication details coming from the current episode should be uploaded into the
Emergency Data Set/ Patient Summary or Medication Record and the health professionals'
access to the patient information should be recorded in an audit trail.

In the use case that refers to Special Conditions (such as pregnancy), a healthy person who is
travelling abroad has an unscheduled encounter with a doctor. Examples include a weekend
intervention, an acute episode, an accident, or – in the case of pregnancy – going into labour
unexpectedly). Access to an Emergency Data Set/Patient Summary could enable the health
professionals involved to obtain a rapid orientation on the particular conditions involved, and
ensure continuity of care. In the case of a pregnant woman, the Emergency Data Set/ Patient
Summary could detail some of her essential obstetric data (such as name of her obstetrician,
medical history, examinations already performed, blood tests, immunizations, observations, and

                                    DRAFT version 27/02/2007                                     4
The data from this encounter could be uploaded into the Emergency Data Set/ Patient Summary
and the current obstetrician would be informed of the encounter or intervention.

Such a use case illustrates the benefits of the use of Emergency Data Set/Patient Summary and
Medication Record in the event of particular conditions.

Observations from the Expert group on eHealth interoperability:

These special conditions should be explored at a later stage during the development of the Pilot.

The details required for large-scale use cases, such as natural disasters, should not be explored in
the Pilot.

Language and terminology issues need to be solved by the relevant stakeholders (i.e., the users
involved in the Pilot).

The use cases should be developed in the Pilot itself. They should bear in mind the relevant legal
and regulatory issues.

Small-scale use case should have two criteria for selection: i.e., frequency of occurrence, and the
effectiveness of ICT in dealing with the proposed situations.

The use cases should primarily focus on accidents. A secondary focus should be on chronic
diseases such as diabetes or cardiovascular diseases. Dental emergencies may also be a context
that is worth considering.

DG SANCO and DG EMPL should be consulted for information about the patterns relevant to
members of the European Union's population that travels abroad, and the frequency of their
accidents and cross-border health encounters.

Both the experience of the Netc@rds2 project and the i2health project and relevant data that are
available from 112 Call centres should be used to refine the use cases by both the Pilot proposers
and within the Pilot itself. Experiences from use cases developed by national authorities should
also be used to refine the use case in the Pilot.

The use cases should be technology-neutral. However, it is important to mention the relevant
standards compliance in whichever solution is proposed.

In describing the use cases, the Pilot should take into account the relevant technical and systems
architecture, legal framework, and healthcare systems in each country.


                                    DRAFT version 27/02/2007                                        5
Annex 1: Example use case

Use case: A patient with diabetes and chronic heart disease experiencing an acute
condition which worsens while travelling abroad

A 68 year old retired teacher visited his general practitioner (GP) to ask if it would be
safe for him to travel to the Mediterranean for a four-week holiday. John had never been
to the Mediterranean and planned to go on the trip with his wife who had just become a
pensioner too.

John had been attending his GP regularly for many years. He developed diabetes 20 years
ago, and was later also treated for hypertension and hypercholesterolemia. Two years ago
John developed angina, and his GP made a referral for him to the local hospital to find
out if heart surgery was indicated. The specialist concluded that there was no hurry for an
operation. If treatment with the relevant medicine did not succeed, then John could get a
new referral. However during the x-ray examination of John's heart, John developed an
allergic reaction to the contrast fluid. He also experienced an atrial fibrillation for some
minutes. The examination had to be cut off and therefore was not completed entirely.

The GP nevertheless encouraged John to go on holiday. He told him that the health care
service where he was going was just as good as at home. The GP retrieved John's
electronic health record and drug chart and gave him an ePrescription. John could then
later get his drugs at the pharmacy that he needed to take along on holiday. The GP
printed out a paper copy of his drug chart and gave it to him - just in case. He also
explained to John what would be important for other doctors to know if he got ill. John
was pleased to hear about that.

Patient summary

John gave the GP his approval for which categories of information were to be included in the patient
summary. When the GP had completed the recording in John's electronic health record (EHR), a message
containing all information needed to establish the patient summary was automatically sent to the national
patient summary database. The patient summary was marked "automatic update", meaning that any new
information of the relevant categories recorded in John's EHR would be automatically added to his patient
summary. As a unique means of identification, John's passport number, driver licence number and national
patient identifier were recorded. John chose a combination of his mother-in-law's name and his son's
birthday as a password for his patient summary.


Unfortunately, when John arrived at his destination airport, his suitcase did not turn up.
In his hand baggage, John had only the insulin and tablets he needed for that very day.
Nor could John remember exactly the name or the dosage for all drugs that he needed.
The paper copy he got from his GP was in his suitcase. It was Saturday and John could
not reach his GP at home. Would the hospital back home know which medicines he was
using these days? Could the local doctor or pharmacy get the information? John tried the
local pharmacy first.

                                      DRAFT version 27/02/2007                                         6
Patient summary

John was lucky. The local pharmacy at his holiday destination had access to the European patient
summary network and John got the medicine that he needed. John gave the pharmacist his passport and
the pharmacist entered John's nationality and his passport number into the patient summary system. She
thereafter gave John the keyboard so that he could enter his password. Using John's patient summary, the
pharmacist identified herself. As a pharmacist, she was allowed to request any active ePrescriptions issued
for John. She immediately received the prescription that John's GP had 'written' earlier on. John then
obtained and paid for his medicine. Finally, the pharmacist entered information into John's patient summary
about the medicine that she had dispatched. This information was also sent automatically to the
ePrescription server where John's prescription was stored.


On the third week of his trip, however, John suddenly got a lasting chest pain that
wouldn‟t go away even when John was resting. The hotel called the ambulance and he
was brought to the hospital immediately. The examination showed that he had atrial
fibrillation and ischemia. John told the specialist at the hospital that he had had an
episode with an irregular pulse while he was at the hospital at home. He also said that
when he was treated at his own hospital at home he had became critically ill. But John
didn‟t know why he'd become ill or what had happened. Could it have been the drugs
they had tried, the anaesthesia, or something else? This was vital information to obtain in
order to proceed effectively in trying to treat John's fibrillation and relieve his pain.

Patient summary

Since John had a patient summary, the holiday destination hospital specialist was able to call up the
information she needed. To get the information, the specialist first had to enter her healthcare professional
ID and her personal password. Then she entered John's passport number and nationality (just as John had
selected at home) as the unique identifier to get access to his data. The specialist then recorded
information about John's medical condition and the treatment she had provided to him in John's patient


The specialist got John's fibrillation under control by medication. But there were still
signs of serious ischemia. The specialist decided to send him home to his own country
straightaway because John needed an immediate coronary heart operation. John was
referred to a hospital with a heart surgery unit close to the destination airport in his home
country. John's own local hospital could not perform this kind of service.

Preparing for the operation, the heart surgeon needed all the relevant information about
what had happened to John while abroad. Had the hospital staff started with
anticoagulation or another new medicine, and what “episode” was it that they were
referring to two years ago at John's local hospital? They were planning an initial x-ray

                                       DRAFT version 27/02/2007                                            7
Patient summary

The surgeon logged on to John's patient summary system using his professional ID and his personal
password. To access John's patient summary, he entered John's national patient identifier. He also had to
state the reason for his access request. Using the patient summary he got access both to the information
recorded by the specialist who had treated John on holiday, and also the information originally recorded by
the GP. He could also see precisely what hospital had performed the heart examination on John two years
ago, and he made a request to get access to the results from that examination. All the necessary
information was in place when John arrived at the hospital.


The operation went well and John was transferred to his local hospital for rehabilitation.
Two weeks after the operation he showed up again at his GP‟s office. John certainly had
a lot to tell his GP about when they read together through his discharge notes and patient

                                       DRAFT version 27/02/2007                                          8

To top