This document discusses privacy-preserving backup and recovery of emergency data in Germany's telematics system. It analyzes the existing scenario for backing up and recovering emergency data stored on electronic health cards. The existing scenario has disadvantages related to privacy and data security. The document proposes an improved scenario that uses secret sharing techniques like Krawczyk's secret sharing scheme to distribute encrypted emergency data fragments across multiple servers, allowing for privacy-preserving backup and recovery while avoiding single points of failure.

1. Privacy Preserving Back-up and Recovery of Emergency Data
Seminar on System Security for Master
Summer Semester 2010
Zdravko Danailov
Matr.Nr.: 108003256581
3rd August 2010
Abstract
The processes of back-up and recovery of emergency data play an important role within the
Telematics system. Their completion has to be executed completely secure with no risk of a
data loss and preserving the privacy of the patient. In this paper we will take a look at the
existing/proposed scenario for back-up/recovery of emergency data and discuss the problems by
its implementation. In order to improve this scenario and solve the problems we will put forward
a new scenario.
1

2. Contents
1 Introduction 5
2 Preliminaries 5
2.1 The Telematics infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Electronic Health Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Health Professional Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Hardware Security Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Emergency data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6 Existing problems by donation of organs . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Scenario Back-up/Recovery of emergency information 8
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Examination of the existing/ proposed solution . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Disadvantages of the solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4 Krawczyk's Secret Sharing Scheme 11
4.1 Secret Sharing Scheme (n,m) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Shamir's Secret Sharing Scheme (n,t) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Information Dispersal Scheme (n,m) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4 Krawczyk's Secret Sharing Scheme (n,m) . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Our proposal solution 14
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 Back-up of emergency data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3 Recovery of emergency data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6 Conclusion 19
A Appendix A 21
B Appendix B 22
C Appendix C 22
2

3. List of Figures
1 Overview of the entire architecture [Gem08a] . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Primary systems architecture [Gem08a] . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 Scenario for back-up/recovery of emergency data . . . . . . . . . . . . . . . . . . . . . . 9
5 Period of renewing of the eHC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6 Recovery of the emergency data on the eHC . . . . . . . . . . . . . . . . . . . . . . . . . 11
7 Secret Sharing Scheme(n,m) [Sch06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8 Curve over 5 points [Sch06] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9 Information Dispersal Scheme (n,m) [Sch06] . . . . . . . . . . . . . . . . . . . . . . . . . 13
10 Krawczyk's Secret Sharing Scheme(n,m) [Sch06] . . . . . . . . . . . . . . . . . . . . . . . 13
11 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12 Our proposal solution one for back-up of emergency data . . . . . . . . . . . . . . . . . 16
13 Our proposal solution two for back-up of emergency data . . . . . . . . . . . . . . . . . 17
14 Our proposal solution one for recovery of emergency data . . . . . . . . . . . . . . . . . 18
15 Our proposal solution two for recovery of emergency data . . . . . . . . . . . . . . . . . 19
16 Standard form for organ donation [Gem08d] . . . . . . . . . . . . . . . . . . . . . . . . . 23
17 Aris' legend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3

4. List of Abbreviations
DEC Decryption
e.g. for example
eHC electronic Health Card
ENC Encryption
ePrescription electronic Prescription
gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte mbH
GMA German Medical Association
HIS Hospital Information Systems
HPC Health Professional Card
HSM Hardware Security Module
IDS Information Dispersal Scheme
PAS Practice Administration Systems
PhAS Pharmacy Administration Systems
PIN Personal Identication Number
PTA Patient Transport Ambulance
SOA service-oriented architecture
SS Secret Sharing
VPN Virtual Private Network
4

5. 1 Introduction
Preserving the privacy of the patient in case of emergency or by back-up/recovery of personal data on
the electronic Health Card (eHC) is an important aspect by the development of the Health Telematics
infrastructure. Its very complex structure, in which there are several dierent groups of involved
persons, as well as its usage for transfer and storage of signicant data, certainly arise the question
about the security. The goal of this paperwork is to examine the existing/proposed scenario for back-
up and recovery of emergency data made by gematik- Gesellschaft für Telematikanwendungen der
Gesundheitskarte mbH [SOZ09]. We will analyze how secure is this scenario, as regards to the risk of
exposing personal information about a patient and irreversibly losing an information.
Outline In order to scrutinize the existing scenario for back-up and recovery of emergency data, the
structure of this paperwork proceeds as it follows: Chapter 2 focuses on the theoretical fundamentals
of the Health Telematics infrastructure, and gives brief information about the necessary types of cards
used by the scenario. Also pays attention to what are emergency data and Hardware Security Module.
An analysis of the existing/proposed scenario within the Telematics infrastructure, as well as its dis-
advantages will be performed in chapter 3. Chapter 4 is about the Krawczyk's information dispersal
scheme. It will pay attention to specic details, concerning the dispersal and recovery of important
data. In chapter 5 our solution of the scenario will be presented, eliminating the disadvantages for
the proper execution of back-up/ recovery of emergency data, determined in chapter 3.Chapter 6 will
conclude with a critical view on the existing scenario, which has already been examined in detail in
this paperwork.
Before we start with the examination of the scenario prepared in order to store emergency data as
a back-up or recover such data on the eHC of the patient we will make clear some of the basic terms
which are used in this paper.
2 Preliminaries
2.1 The Telematics infrastructure
Health Telematics designates the combination of telecommunication and informatics in the healthcare
sector. In some countries, Health Telematics corresponds to the term 'Tele-health' and also to the term
'e-Health', which seems to be currently establishing itself both in Germany and at an international
level.
The entire architecture [Gem08a] is shown in Figure 1.
For the purpose of this paper we need to clarify what are the primary systems in their essence.
The primary systems (Figure 2 [Gem08a]) provide application programs for the medical care
providers and insurants. The programs used by the medical care providers are Practice Adminis-
tration Systems (PAS) for medical specialists and dentists, Hospital Information Systems (HIS) for
hospital, rehabilitation centers etc. and Pharmacy Administration Systems (PhAS) for pharmacies.
The programs, which are relevant for the insurants are eKiosk and Versicherten@Home. They provide
functions for the insurants to access their data, in order to 'Hide/Show' specic data as well as to
administrate the rights or in some cases to delete data. [Gem08a]
2.2 Electronic Health Card
In order to improve the health insurance system the German government enacted a law [SOZ09], by
which they started an enormous infrastructural Telematics project: the introduction of a national
electronic Health Card (eHealth Card). This microprocessor chip card is an important element in the
5

6. Figure 1: Overview of the entire architecture [Gem08a]
Figure 2: Primary systems architecture [Gem08a]
fast developing Telematics infrastructure. This card is simply the key to a health system data as well
as to applications for computing and processing such data. The main purpose by the initiation of this
project is the enhancement of eciency, quality and transparency in medical care. TThe solution is a
patient based sector-spanning network with persistent information ow.-[PRS07] For this reason the top
organizations of the national German health system assumed the responsibility to create and introduce
the required infrastructure and therefore founded gematik - Gesellschaft für Telematikanwendungen
der Gesundheitskarte mbH [SOZ09] in 2005. [PRS07]
The electronic health card (eHC) is a working out of the Fraunhofer Institute supported by the Federal
Ministry of Health in Germany. The eHC is conceived and developed as a service-oriented architecture
(SOA) with some restrictions, such as: tthe health card can only be accessed locally on the client side;
or services should use remote procedure calls for communication due to performance and availability
issues.-[LHM09] As a result, the system architecture is divided into dierent layers. This gives to
the system the possibility to provide ÿeveral service applications such as emergency data, electronic
prescription (ePrescription), electronic medical report or an electronic health record system.-[LHM09]
6

7. 2.3 Health Professional Card
The Health Professional Card (HPC), which nowadays is an immutable part of the eHC' concept, pri-
marily was one independent construct. In 1996 the German Medical Association (GMA) together with
the National Association of Statutory Health Insurance Physicians founded a work group named 'Elek-
tronischer Arztausweis', which concentrated on this subject. Rapidly came clear that the introduction
of the HPC would not be possible without a reconcilement with the eHC. [Sch09] HPC can be dened
as än individually programmed access authorization card held by the health professionals-[ILP06] (e.g.
doctors and pharmacists). Despite of the integration with the eHC, the HPC has also its own sig-
nicance. Thus, the particular medical associations as well as pharmacists' associations, which are
responsible for the issuance of the cards, can provide applications of their own. For example, a medical
association can upload a database with specic medical data online, where the HPC serves as an access
key instead of password and login id.
2.4 Hardware Security Module
By denition the hardware security module is a device, which securely processes and saves security-
relevant information, such as crypto keys and data. It can be also a chip card controller. [Gem08c]
Via the HSM, a doctor can authenticate himself and write or edit data on an eHC with the permission
of the patient. To give permission for execution of such process the patient has to enter his PIN code
over the integrated keyboard on the HSM.
2.5 Emergency data
What are emergency data and what information is kept within? By denition this is information
about the data in case of emergency, including the declaration (the completed and signed form) for
organs' spending. [Gem08b] There are dierent main categories such as relevant diagnoses, medication
or allergy/ intolerance (please, see Appendix A). The declaration for organs' spending is part of the
emergency data, but it can be completed or left blank. This means that both of them can be lled
out independently from one another. An example of this form can be found in appendix B. [Gem08d]
2.6 Existing problems by donation of organs
Among the many problems tightly connected with the donation of organs, for the illegal trade of organs
and the transportation diculties by natural perils seems to have no wholly and permanent solution.
• Criminal/illegal trade of organs
The criminal/illegal trade of organs is the biggest existing problem by donation of organs. There
are two dierent basic types of illegal organ trade. By the rst type because of indigent con-
ditions people sell their own body organs for prot. By the second the organs are taken from
executed prisoners. TThe black market trade of human organs is sustained by wealthy indi-
viduals, sometimes on long waiting lists for transplants, traveling to foreign countries for the
procedure.-[IL009]
• Transportation diculties by natural perils
Time plays very important role by transportation of organs for donation. If the specic organ
cannot be transported betimes to the matching person (patient), it becomes unusable. Sometimes
because of natural perils such as earthquakes, oods, re or even eruption of volcanoes can induce
diculties and impossibility to transport the organs to the specic location. As proof of this
statement the following facts are mentioned below: on the 14th April 2010 by the eruption of
Eyjafjallajökull [URL10a], located in Iceland, an enormous cloud of volcanic ash was released
7

8. in the atmosphere, causing mass ight cancellations all over Europe, spanning from the UK to
Russia over fears that the soot may be catastrophic to planes - such as causing engines to fail
in-ight or severely reducing the pilot's visibility.
The ash clouds were drifting between six to nine thousand meters above the ground, and were
moving eastwards, over northern France and Austria and towards Russia at about 40 kilometers
per hour.
Because of the embargo over ights there were dramatic consequences for the transportation of
organs. Birgit Blome (50) from the German foundation for organ transplantation said : TThe
organs -heart, lungs and liver, which are usually transported via ight, are now found locally and
transported by car.-[URL10b] The director of the foundation for transplantation Eurotransplant
Axel Rahmel also said:Ït is already a challenge, when the transportation is possible only via
ambulances or PTA (Patient Transport Ambulance)-[URL10c]
3 Scenario Back-up/Recovery of emergency information
3.1 Overview
Before we start examining the scenario for back/recovery of emergency data, it is important to make
clear, which are the persons involved, what types of HSM are used, as well as what are the possible
processes.
Figure 3: Overview
As illustrated in Figure 3, the persons involved in this scenario are patient, doctor and in case of
emergency - paramedic. Moreover, there are two dierent types of Hardware Security Modules, which
are used: 1.chip cards - eHC, HPC 2. chip card terminal. Regarding the possible processes within this
scenario, the emergency data can be updated, backed up or recovered.
3.2 Examination of the existing/ proposed solution
The proposed scenario for back-up/recovery of emergency data (including data for organ donation)
proceeds as it follows. The whole process (Figure 4) is executed oine. After the obligatory authen-
tication through the eHC of the patient and HPC of the doctor the data on the eHC can be edited or
created and then saved. This data is overwritten/saved on the eHC. As it is explained in the gematik
8

9. documentation there can be made two more back-ups, though they are not obligatory. First a docu-
ment with the data concerned can be printed out and given to the patient for personal preservation.
Second a temporary copy of the data can be saved in the primary system of the doctor within the
documentation. If the eHC is not usable (because of substitution process, loss or defect) the insurant
must turn to the doctor, who made the last save/back-up of the emergency data. He can recover the
data on the new eHC on basis of the document given to the patient, or using the stored data in his
primary system. [Gem08d]
Figure 4: Scenario for back-up/recovery of emergency data
9

10. 3.3 Disadvantages of the solution
After we have scrutinized the process of saving the emergency data and creating a back-up or recovering
it on the eHC will try to cover all disadvantages of the solution. For this purpose we will examine
some theoretical cases below.
Figure 5: Period of renewing of the eHC
• Renewing of the eHC, because of loss, defect or expiry
In case of emergency the patient has to have the document, printed by his doctor (shown in
Figure 5). There is no other option for the medical person to ind outtthe data, concerning the
individual health characteristics of the patient, because the process is executed oine. On rst
place the creation of this document is not obligatory. Second, it is only a sheet of paper, which
can be lost, stolen or destroyed (e.g. during natural perils, re). Moreover it exposes private
data.
• Recovery of the emergency data on the eHC
The back-up made in the primary system of the doctor is only temporary. This means that if the
back-up is deleted after particular period of time and the optional ppaper pack-upïs not available
(1. not created, 2. created, but lost/stolen or destroyed), there is no other way of recovering the
data, so it is irreversibly lost.The whole process is shown in Figure 6.
10

11. Figure 6: Recovery of the emergency data on the eHC
From these examples we can conclude that the process possesses two major disadvantages: it is
executed oine and is completely unsecure. For this reason we will propose another solution in the
following chapter 5, which will solve these problems.
4 Krawczyk's Secret Sharing Scheme
In this section we will take a look at the Krawczyk's Secret Sharing Scheme (shown in Figure 10 [Sch06]),
which we use by our solution for recovery/ back-up of emergency data. Before we present this specic
scheme we shall clarify what is secret sharing and what are its properties.
11

12. 4.1 Secret Sharing Scheme (n,m)
Figure 7: Secret Sharing Scheme(n,m) [Sch06]
Secret Sharing Scheme (Figure 7 [Sch06]) was invented by both Adi Shamir and George Blackley
S
independently of each other in 1979. It is a method for distribution of a secret among a group
n S
of -participants. The reconstruction of is possible only when a sucient number of shares (in
m
this case ≥ ) are combined together, which means that m-1
-shares provide no information about
S . [Sch06] [Bla79] [WIKa] [WIKb]
4.2 Shamir's Secret Sharing Scheme (n,t)
Figure 8: Curve over 5 points [Sch06]
Shamir's Secret Sharing Scheme is based on polynomial interpolation (Figure 8 [Sch06]). The
process of distribution proceeds as it follows:
1. pick t points to dene a polynomial of degree t-1
2. create a polynomial of degree t-1 with the secret S as the rst coecient (k ) and the remaining
coecients (k ,...,k ) picked at random
0
t−1 1
3. nd n points on the curve and give one to each of the participants (in this case n) [Sch06]
The process of reconstruction proceeds as it follows:
t n
1. at least out of the players reveal their points, there is sucient information to t an (t-1)-th
degree polynomial to them
2. the rst coecient of the polynomial is the secret S
12

13. The Shamir's Secret Sharing Scheme is information-theoretically secure (also unconditional
secure S
), meaning that an attacker cannot extract any information about the secret (from less than
m shares), whatever how much computational time he invests. Additionally, the size of each share
S
has to be equal (or ≥) to the size of the secret , which makes the Shamir's Secret Sharing Scheme
storage ecient . [Sch06] [Sha79] [WIKc]
4.3 Information Dispersal Scheme (n,m)
Figure 9: Information Dispersal Scheme (n,m) [Sch06]
The Information Dispersal Scheme (Figure 9 [Sch06]) is based on error correcting codes, such as
e.g. Reed-Salomon Code. In comparison with the Secret Sharing Scheme, where a secret S is shared
among the participants, the Information Dispersal Scheme is a method for distribution of information
F n
among a group of -participants. The reconstruction is possible when sucient number of fragments
m
(≥ ) is combined together. By this specic method the secrecy is not important, so it is possible to
F m
gain information about from less than fragments. Every fragment has a length of |F | . [Sch06]
m
4.4 Krawczyk's Secret Sharing Scheme (n,m)
Figure 10: Krawczyk's Secret Sharing Scheme(n,m) [Sch06]
Krawczyk's Secret Sharing Scheme (n,m) (Figure 10 [Sch06]) combines both Secret Sharing (SS)
and Information Dispersal (IDS) Schemes in one. The process of distribution proceeds as it follows:
13

14. 1. randomly pick a symmetric key K and encrypt symmetrically the secret S, building E= ENCk(S)
2. partitionE in n fragments (e ), using an IDS
i
3. disperse K in n shares (k ), using a SS
i
4. send to every participant (in this case n) a share s i ek
= ( i , i ) [Sch06]
The process of reconstruction proceeds as it follows:
1. at leastm out of the n players reveal their shares s i ek
= ( i , i ), i 1...m
2. reconstruct E from e , using the IDS
i
3. reconstruct K from k , using the SS
i
4. decrypt E: S=DECk(E) [Sch06]
The Krawczyk's Secret Sharing Scheme (n,m) is not information-theoretically secure, because by su-
K
cient computational time an attacker can nd out the key , decrypt some shares, which are common
S s
to him, and extract some information about the secret . Additionally, the size of each share is | i |=
K S
m + | | | |. [Sch06]
|S|
The Krawczyk's Secret Sharing Scheme (n,m) needs less storage and also bandwidth in comparison
to Shamir's SS. It is computationally secure , which means that practically from m-1
shares an
S
attacker cannot extract any information about the secret . [Sch06] [Kra94]
5 Our proposal solution
5.1 Overview
Before we present our proposal solution for back/recovery of emergency data, it is important to make
clear, which are the persons involved, what types of HSM are used, as well as what are the possible
processes.
As illustrated in Figure 11, the persons involved are patient, doctor and in case of emergency -
paramedic. By our proposal solution we use two types of HSMs as well: 1.chip cards - eHC, HPC 2.
chip card terminal. Regarding the possible processes, the emergency data can be updated, backed up
or recovered.
First, in our proposal scenario, we tolerate non-availability, in order to grant more possibilities for
recovery of the specic emergency data. By this way despite that a particular source, containing a
share of emergency data is not accessible, the emergency data can be still recovered. Second, we
minimize the risk of revealing emergency data (private personal data), by using Secret Sharing. Third,
for the processes of back-up and recovery of emergency data we use no encryption, but Secret Sharing.
5.2 Back-up of emergency data
The process for back-up of emergency data is executed in four phases:
1. Phase of authentication
For authentication can be used many dierent well-known methods. The patient and doctor (or
paramedic) can authenticate themselves via e.g. PIN, ID-patient/ ID-doctor, ID-eHC/ID-HPC,
Fingerprints, dierent types of digital signatures, etc.
14

15. Figure 11: Overview
2. Complete the form for emergency data and/ or form for organs' donation
In this phase all necessary information, such as relevant diagnoses, operations, procedures or
relevant medications in case of emergency is lled out. As already mentioned in section 2.5, the
declaration for organs' spending can be also completed or left blank.
3. Conrmation of the data, e.g. via ngerprint or PIN by the patient and doctor
In any case of changing the emergency data (e.g. creation or update), the new copy has to be
veried. So the emergency data has be read by the patient and then conrmed by both patient
and doctor via ngerprint (assuming that the chip card terminal has a touch screen) or PIN.
4. Back-up
In comparison to the existing/ proposed solution for back-up of emergency, made by gematik,
where all four phases (if a back-up is made, because it's optional) are executed oine, we suggest
an obligatory back-up, executed oine and online.
Our proposal solution one for back-up of emergency data
(a) using Krawczyk's SS - executed online via e.g. VPN
In this case using Krawczyk's SS, we can secure a back-up of emergency data on three
dierent servers; more exactly we disperse fragments of the information S (emergency data)
to each one of them.
(b) using a portable device (e.g. USB-Stick) - executed oine
As an extra back-up, a copy of emergency data is saved in the primary system database
and also on portable device (e.g. USB stick), which is given to the patient.
The advantages of this proposal solution (Figure 12) for back-up of emergency data, compared
to the gematik' solution are:
(a) The creation of back-up is obligatory
15

16. Figure 12: Our proposal solution one for back-up of emergency data
(b) In case of emergency, if the eHC is not present (for any reason), it is still possible that the
paramedic can obtain emergency data online (via e.g. VPN) - from the three servers. Even
if one of the servers is not accessible, the information S can be reconstructed. Otherwise
the necessary data can be gained from the USB stick oine.
(c) The risk of exposing private data is minimised.
Our proposal solution two for back-up of emergency data By this solution (Figure 13)
we use Krawczyk's SS to disperse the information:
(a) online (via e.g. VPN) - securing a back-up of emergency data on three dierent servers;
(b) 2. oine - securing a back-up of emergency data on a portable device (e.g. USB-Stick) and
in the primary system database;
More exactly we disperse 5 fragments of the information S (emergency data) to each one of them
(please, see Figure 13: Our proposal solution two for back-up of emergency data).
16

17. Figure 13: Our proposal solution two for back-up of emergency data
The advantages of this proposal solution for back of emergency data, compared to the gematik'
solution are:
(a) The creation of back-up is obligatory
(b) In case of emergency, if the eHC is not present (for any reason), it is still possible that
the paramedic can obtain emergency data online (via e.g. VPN) - from the three servers.
Even if one of the servers is not accessible, the information S can be reconstructed from the
fragments on the other two servers and on the USB stick.
5.3 Recovery of emergency data
The process for recovery of emergency data is executed in two phases:
1. Phase of authentication
For authentication can be used many dierent well-known methods. The patient and doctor (or
paramedic) can authenticate themselves via e.g. PIN, ID-patient/ ID-doctor, ID-eHC/ID-HPC,
Fingerprints, dierent types of digital signatures, etc.
17

18. 2. Recovery
For the process of recovery of emergency data, we will present two proposal solutions as we did
for back-up (in the previous section 5.2).
Figure 14: Our proposal solution one for recovery of emergency data
Our proposal solution one for recovery of emergency data
(a) using Krawczyk's SS - executed online via e.g. VPN
Using Krawczyk's SS, we can reconstruct emergency data from the three dierent servers;
more exactly we 'gather' the fragments of the information S (emergency data) from each
one of them.
(b) using a portable device (e.g. USB-Stick) - executed oine
The other option to recover a copy of emergency data is from the primary system database
or also from the portable device (e.g. USB stick), which has been given to the patient.
In case of emergency, if the eHC is not present (for any reason), it is still possible that the
paramedic can obtain emergency data online (via e.g. VPN) - from the three servers. Even
if one of the servers is not accessible, the information S can be reconstructed. Otherwise the
necessary data can be gained from the USB stick oine, minimizing the risk of exposing private
data. In case of renewing the eHC (lost, stolen or defect), the recovery is possible online from
the three servers, as well as oine from the primary system database or the portable device (e.g.
USB stick), given to the patient.
18

19. Our proposal solution two for recovery of emergency data By this solution (Figure 15)
we use Krawczyk's SS to reconstruct the information:
(a) online (via e.g. VPN) - reconstructing emergency data from the three servers;
(b) oine - reconstructing emergency data from the portable device (e.g. USB-Stick) and/ or
the primary system database;
Figure 15: Our proposal solution two for recovery of emergency data
In case of emergency, if the eHC is not present (for any reason), it is still possible that the
paramedic can obtain emergency data online (via e.g. VPN) - from the three servers. Even if
one of the servers is not accessible, the information S can be reconstructed from the fragments
on the other two servers and on the USB stick, because we need minimum 3 sources containing
fragments of S. In case of renewing the eHC (lost, stolen or defect), the recovery is possible using
the online sources (three servers), combining them with the oine ones (the primary system
database or the portable device (e.g. USB stick), given to the patient), if one or two of the
servers are not accessible.
6 Conclusion
The Health Telematics infrastructure was created and is being developed to bring security and comfort,
to save resources etc. So it is simply inevitable to set limits to the need of fast and practical solutions
within this rapidly developing system. However, it arises the question about the functionality of
these solutions. In this paperwork we have scrutinized a solution for the processes of back-up and
recovery of emergency data and we have shown some problems by their execution. That's why, after
we've analyzed these problems, we have tried to eliminate them, by working out a better solution for
19

20. back-up and recovery of emergency data, which can be easily implemented. In our proposal scenario,
we tolerate non-availability, in order to grant more possibilities for recovery of emergency data. We
minimize the risk of revealing emergency data (private personal data) and try to keep the solution
easily applicable, by using Secret Sharing. This makes our proposal solution computationally secure
and facile to implement within the existing Health Telematics infrastructure, which despite of its
strengths or weaknesses is a reliable, trustworthy system that will play an enormous role for the
further development of the health care sector.
References
[Bla79] G.R. Blakley. Safeguarding cryptographic keys. In Proceedings of the 1979 AFIPS National
Computer Conference, volume 48, pages 313-317. AFIPS Press, Monval, NJ, USA. 1979.
[Gem08a] Gematik. Einführung der Gesundheitskarte - Gesamtarchitektur. pages 325. September
2008.
[Gem08b] Gematik. Einführung der Gesundheitskarte - PKI für CV-Zertikate Grobkonzept. pages 34.
June 2008.
[Gem08c] Gematik. Einführung der Gesundheitskarte - PKI für die X.509-Zertikate, Grobkonzept.
pages 28. June 2008.
[Gem08d] Gematik. Fachkonzept - Daten für die Notfallversorgung (Notfalldaten). pages 76. August
2008.
[IL009] Illegal organ trade. http://www.mahalo.com/stub/illegal-organ-trade, 2009. data
called on 27.05.2010.
[ILP06] Robert Istepanian, Swamy Laxminarayan, Constantinos Pattichis. M-health:
emerging mobile health systems. ISBN 978-0-387-26558-2. In International Top-
ics in Biomedical Engineering, pages 623. Springer US, New York. 2006.
http://www.springerlink.com/content/978-0-387-26558-2.
[Kra94] Hugo Krawczyk. Secret sharing made short. Advances in Cryptology (CRYPTO). ISBN
0-387-57766-1. In Lecture Notes in Computer Science, volume 773, pages 136-146. Springer
US, New York. 1994. http://www.cs.cornell.edu/courses/cs754/2001fa/secretshort.pdf.
[LHM09] Roger Lee, Gongzu Hu, Huaikou Miao. Computer and Information Sci-
ence. ISBN 978-3-642-01208-2. In Studies in Computational Intelligence, vol-
ume 208, pages 304. Springer Berlin Heidelberg, Berlin/Heidelberg. May 2009.
http://www.springerlink.com/content/j014155j5547/?v=editorial.
[PRS07] Norbert Pohlmann, Helmut Reimer, Wolfgang Schneider. ISSE/SECURE 2007: Se-
curing Electronic Business Processes: Highlights of the Information Security Solutions
Europe / SECURE 2007 Conference. ISBN 978-3-834-80346-7. 1st edition, pages 444.
Vieweg+Teubner, Wiesbaden. September 2007.
[Sch06] Thomas Schneider. Verteilte Geheimnisse und Informationen. pages 44. August 2006.
http://thomaschneider.de/talks/Verteilte_Geheimnisse_und_Informationen/handout.pdf.
[Sch09] Klaus Schmeh. Elektronische Ausweisdokumente: Grundlagen und Praxisbeispiele. ISBN
978-3-446-41918-6. volume 14, pages 282. Carl Hanser Fachbuchverlag, München. Au-
gust 2009. http://www.onleihe.de/static/content/carlhanser/20090804/978-3-446-42108-
0/v978-3-446-42108-0.pdf
20

21. [Sha79] Adi Shamir. How to share a secret. ISSN 0001-0782. In Communi-
cations of the ACM, volume 22, pages 612-613. ACM, New York. 1979.
http://crypto.csail.mit.edu/classes/6.857/papers/secret-shamir.pdf.
[SOZ09] Sozialgesetzbuch Fünftes Buch (V). 2009. Ÿ 291 - http://www.sozialgesetzbuch-
sgb.de/sgbv/291.html and Ÿ 291b - http://www.sozialgesetzbuch-sgb.de/sgbv/291b.html.
[URL10a] Eruption of Eyjafjallajökull Volcano, Iceland. http://earthobservatory.nasa.gov/
IOTD/view.php?id=43252, 2010. data called on 28.05.2010.
[URL10b] Noch Monate Asche-Chaos? http://www.bild.de/BILD/news/2010/04/19/
asche-chaos/noch-monate-chaos-nach-vulkan-ausbruch-in-island.html, 2010.
data called on 28.05.2010.
[URL10c] Vulkanasche-Chaos. http://www.berlinonline.de/berliner-zeitung/archiv/.bin/
dump.fcgi/2010/0419/tagesthema/0053/index.html, 2010. data called on 28.05.2010.
[WIKa] Secret sharing. http://en.wikipedia.org/wiki/Secret_sharing. data called on
10.06.2010.
[WIKb] Secret sharing. http://de.wikipedia.org/wiki/Secret_Sharing. data called on
10.06.2010.
[WIKc] Shamirs secret sharing. http://de.wikipedia.org/wiki/Shamirs_Secret_Sharing. data
called on 10.06.2010.
A Appendix A
The following list was worked out by BAND (Bundesvereinigung der Arbeitsgemeinschaften der Notärzte
Deutschlands), the DIVI (Deutschen interdisziplinären Vereinigung für Intensiv und Notfallmedizin),
the DGAI (Deutschen Gesellschaft für Anästhesiologie und Intensivmedizin) and the BÄK (NKS)
(Ausschuss 'Notfall-, Katastrophenmedizin und Sanitätswesen'). It covers the current status and can be
updated anytime if necessary. The terms within this list should be used without any changes. [Gem08d]
1. relevant diagnoses, operations, procedures in case of emergency
· Bronchial asthma
· COPD (chronic obstructive pulmonary disease)
· Coronary heart disease
· Cardiac insuciency
· Cardiac arrhythmia
· Cardiac pacemaker
· Internal Debrillator
· Cerebral cramps
· Neuropathy
· Inborn coagulation disorder
· acquired coagulation disorders
· Medicinal induced coagulation disorders
· Diabetes mellitus
· Addison's syndrome
· Glaucoma
21

22. · Glass eye
· Contact lens
· Obligatory dialysis renal insuciency
· Chronic liver insuciency
· Relevant infectious disease
· Organ transplantation
· Abdominal aortic aneurysm
· further particulars
2. relevant medications in case of emergency
· Beta-Blocker
· ACE-Hemmer
· Diuretic
· Calcium-Antagonist
· Nitro-preparation
· Anti-arrhythmic drug
· Digitalis
· Beta mimetic
· Cortisone
· Immunosuppressant drug
· Aldosterone antagonist
· Anticonvulsant
· Antidepressant drug
· Antipsychotic
· Platelet aggregation inhibitor
· Phenprocoumonum, e.g. Marcumar R
· Heparin
· Factor VIII / IX
· Desmopressin, e.g. Minirin R
· Insulin
· Cholinesterase
· Opiate
· NSAR
· further particulars
B Appendix B
An example of declaration for organs' spending is shown in Figure 16 [Gem08d] below.
C Appendix C
In Figure 17 are shown the basic notations in Aris, used for the creation of the process models.
22

23. Figure 16: Standard form for organ donation [Gem08d]
Figure 17: Aris' legend
23