Pseudonymization for Secondary Use of Cloud Based Electronic Health Records

Transcription

1 Pseudonymization for Secondary Use of Cloud Based Electronic Health Records Liangyu Xu 1, Armin B. Cremers 2 and Tobias Wilken 3 Institute of Computer Science III University of Bonn, Bonn, Germany 1 [email protected], 2 [email protected], 3 [email protected] Abstract This paper presents a security solution for cloud based ehealth (electronic health) systems to facilitate storing and secondary use of EHR (electronic health records). By utilizing a proposed pseudonym scheme and communication protocols, the solution aims to protect the privacy of patients during both the ordinary healthcare activities (e.g. medical treatments based on the EHR) and secondary use of the EHR (e.g. medical research). We implement a prototype of the system on a PaaS (Platform as a Service) cloud to demonstrate the feasibility of the system in practice. Keywords: Pseudonym; Secondary Use; EHR; ehealth; Cloud; Privacy; Security. 1. Introduction Electronic Health Records (EHR) [1] have become more and more popular in ehealth (electronic health) technology. Nowadays, they are replacing the conventional paper based health records to store the healthcare information of patients in many countries and areas [2]. As EHR are much easier to store, retrieve and share the healthcare information, they greatly improve the efficiency and the quality of health care [3]. EHR are also intended to facilitate the secondary use of the healthcare data. This includes medical research, decision making in health policies, and quality assurance in health care [4]. Secondary use of EHR can enhance healthcare experiences for individuals, expand knowledge about disease and appropriate treatments, strengthen understanding about the effectiveness and efficiency of our healthcare systems, support public health and security goals, and aid businesses in meeting the needs of their customers [5]. Enabling a broader use of healthcare data for research has great potential for improving health outcomes, reducing medical errors, predicting health trends, and demonstrating the comparative value of drugs and other treatments. Thus, the secondary use of health data is attracting more and more attentions in many countries and areas [4, 6]. In many current ehealth systems, the EHR of one patient may be distributed divisively over multiple healthcare providers (e.g. hospitals, practices) which the patient has ever visited. The divisive distribution causes many problems (e.g. authorization, server reliability, different EHR data format) for the applications where all the EHR data of a patient need to be gathered together. E.g. a doctor diagnoses the patient with reference to all the previous EHR data; a medical researcher collects all the EHR data of a certain kind of patient [7]. For the secondary use of EHR data, the scattered EHR in multiple locations will bring many other obstacles. The disclosure of health information and the real identities of associated patients during secondary use may cause severe privacy problems. The real identity information of patients is often not necessary in secondary use and needs to be removed from the EHR data in advance (de-identification) [8]. It is, however, a technical challenge to remove the patients identity information consistently and unify the pseudonym or anonym [9] of the same patient. Another obstacle is that the secondary users might have difficulties contacting the patients to get consent for authorizing the secondary users to use the EHR data legally. Furthermore, the secondary users might also encounter problems in giving feedbacks to the participant patients (e.g., concerning a new treatment suggested by the research). An alternative way is to store all the EHR in a centralized manner. The sharing and gathering EHR data of patients will be much faster and more comprehensive than the distributed manner. To this end, a cloud [10] is an ideal media for storing EHR, providing wide access to the EHR data, because it is able to offer ubiquitous services to customers over the Internet [11]. In the ordinary healthcare activities (e.g. patients visit doctors and pharmacies), all healthcare entities (e.g. healthcare providers, patients, health insurance companies) can access the EHR data from the cloud any time any where, thus facilitating all these activities. E.g., doctors can view all health records of the patients stored in the cloud conveniently; the patients can purchase medicines from a pharmacy by using the electronic prescriptions stored in the cloud. Moreover, the cloud can provide great convenience to the secondary use of EHR as follows. Firstly, if the EHR of a large population segment are stored in the cloud, the secondary users have chance to gather more extensive health information. Secondly, the computation ability of the cloud can provide potential services to the secondary users, e.g. the cloud can help a medical researcher find target participants through powerful searching ability in all the EHR data stored in the cloud. Finally, as the cloud could be a media for the communications between the secondary users and patients, the secondary users can get the consent from the patients and give feedbacks to the latter through the cloud online conveniently. The public accessibility of the cloud brings the risks of disclosing patients health information to ubiquitous attackers. Thus the security of the EHR data and the privacy of the patients will become an enormous challenge when the EHR are stored in the cloud. Normally, the EHR data should be encrypted and the encryption keys should only be known to the intended entities. In addition, the identity information of the patients should also be strictly managed and never be linked to the EHR data by attackers. However, the 1 ASE 2014 ISBN:

2 patients identity information needs to be frequently used in a typical ehealth system and thus confronts high risks of disclosure. A doctor may need the identity information of the patients to query their health insurance coverage from the health insurance companies. The cloud may need to check a patient s identity information to allow him to do any modifications to his EHR data when the patient is managing his EHR online. The secondary users may also need the identity information to confirm that the consent is exactly signed by the owners of the EHR entries and the feedbacks are given to the corresponding participants. A solution responding to the above privacy and security challenges is to use pseudonym scheme [9] to protect the identities of the patients and employ cryptographic algorithms to encrypt the EHR data. Pseudonyms are used to replace the real identity information when the identity information appears in the EHR data stored in the cloud. Patients pseudonyms are generated by secret keys, so they could not be linked to the patients real identities without knowing the secret keys. Due to the pseudonymization of the EHR data, some sections of EHR (e.g. diagnosis, treatments, and prescriptions) can even be plaintext or partially encrypted, as attackers could not find out whom the EHR entries they get from the cloud belong to. Obviously, the plaintexts or partial encrypted EHR data help the secondary users find potential target participants easily, and the pseudonyms can prevent the secondary users from knowing the real identities of the participants. However, pseudonymizing EHR stored in the cloud simultaneously serving both the ordinary healthcare activities and the secondary use confronts many obstacles. Firstly, a conventional pseudonym scheme may need a trusted third party, which may impose risks of disclosing the patients identities. Secondly, the pseudonymized EHR could possibly be linked to the real identity of a patient due to some unintended information enclosed in the EHR by advanced data statistical attacks [12]. Thirdly, the protocols for using the pseudonyms in the ordinary healthcare activities and secondary use might also possibly leak the identity information of the patients to attackers. E.g., a secondary user who sends feedbacks to patients may have a chance to know the identity information (such as contact information) of the patients. This paper aims to design such a pseudonym scheme for storing the EHR in a centralized manner (e.g. cloud). We will discuss the requirements to the pseudonym scheme and protocols for co-operating with the typical procedures during both the ordinary healthcare activities and secondary use of the EHR in ehealth systems. A concrete design of a pseudonym scheme and corresponding protocols to protect and security of the EHR data and the privacy of the patients will be presented, analyzed and evaluated in this paper. The remainder of this paper will be organized as follows. We list and discuss some previous related work in section 2. Section 3 gives a simple model of cloud-based ehealth systems and shows generally how pseudonyms are used to protect patients privacy during both the ordinary healthcare activities and the process of secondary use of EHR. A concrete pseudonym design will then be presented in section 4. In Section 5, schemes and protocols for using the pseudonym scheme in secondary use especially for medical research are presented. A prototype implementation for evaluation and points of security discussion will be addressed in section 6. The last section 7 presents some discussions and an outlook on future work. 2. Related Work A publicly standardized EHR format is important to migrate the EHR scattered in the distributed locations into central servers (e.g. a cloud). Different international organizations have been working on the definition of an EHR. Health Level 7 (HL7) maintains the XML-based Clinical Document Architecture (CDA) [13] that specifies the standards for exchanging clinical documents. The European Committee for Standardization (CEN/TC251) has completed a European Standard for the communication of the EHR named CEN EN The openehr consortium [14] maintains an architecture designed to support the constructions of distributed, patient-centered, life-long, shared healthcare records. Finally, ISO provides a set of clinical and technical requirements for an EHR architecture that support using, sharing and exchanging EHRs in the technical specification TS 18308:2004 [15]. Efforts have been made to translate the existing EHR distributed in multiple healthcare providers into a standard format. LOINC [16] is a code system to map laboratory tests from different hospitals to LOINC so that the lab results could be aggregated across all of the participating hospitals and analyzed together. The ResearchEHR platform [17] reported a system to convert legacy data into normalized archetypes and finally transforms archetypes and data extracts into other EHR standards. The Strategic Health IT Advanced Research Projects (SHARP) Program [18] receives source EHR data in several formats, generates structured data from EHR narrative text, and normalizes the EHR data using common detailed clinical models and consolidated health informatics standard terminologies. There exist some cloud services which the patients can store their personal health information in. Microsoft HealthVault [19] is one of such cloud based websites in which patients can register and manage their personal health records themselves, including sharing their EHRs with selected doctors or other desired persons. However, the website is in charge of protecting the security of the EHR and the privacy of the patients, so the website should be considered as fully trusted by the patients. Different pseudonym schemes were proposed to store the EHR in a central place. In [20, 21], novel designed pseudonyms are used to hide the real identities of the patients, and the EHR data were encrypted by the encryption keys only known by the patients. A new pseudonym scheme was proposed in [22]. They reported to use decentralized pseudonyms to store the EHR in the cloud. This scheme removes all unnecessary trusted parties except for trusted authorities for issuing certificates to healthcare providers. The security of the 2 ASE 2014 ISBN:

3 Visit Certificate 2014 ASE BigData/SocialInformatics/PASSAT/BioMedCom 2014 Conference, Harvard University, December 14-16, 2014 EHR data and privacies of the patients seem to be well guaranteed in these researches. However, the possibility of the secondary use of the EHRs in these pseudonym schemes remains as a problem. Some researches focus on anonymizing or pseudonymizing the EHR data existing in multiple clinics or hospitals for secondary use of the EHR [23-25]. They deal with the uniqueness of patients pseudonyms and protecting the identities of the patients. However, they usually need a trusted third party or a central server to help with the anonymization or pseudonymization procedure in order to guarantee the uniqueness of patients aliases. A trusted party reverses the pseudonyms to real identities when there are any feedbacks from the secondary users to the patients. It brings potential risks of disclosing the patients privacy. Therefore, our scheme strictly reduces the requirement of any such trusted third party. 3. Pseudonymization for Cloud-based EHealth Systems 3.1 Certificate Authority We build a basic cloud-based ehealth system model as shown in Figure 1. In this model which is based on [26], we exclude as much as possible all unnecessary trusted third parties which may have the possibility to leak the private information of the patients. As a corrupt insider may appear inside the trusted third party or a skilled outside attacker may conquer the servers at a trusted third party, an ehealth system, where patients highly private information is stored, without risks of disclosing the patients privacy due to such third trusted parties is much preferable. Patient Doctor Smart card MSK/PIN Patient s Smart card Cloud Certificate Certificate Secondary User Pharmacy Smart card Insurance company Certificate Authority Figure 1 An eheath model with pseudonymizing EHR for ordinary healthcare activities and secondary use To this end, we introduce in our model an entity named certificate authority. It issues digital certificates to other entities. The doctors, pharmacists, insurance companies and secondary users need to apply certificates from the certificate authority. Generally speaking, it is a normal process in many public key infrastructure (PKI) schemes. Each certificate applier needs to generate a self-known private key and a corresponding publicly known public key. The public key together with some necessary information of the applier (e.g. name, certificate type and valid period) is signed by the certificate authority to form a digital file i.e. the applier s certificate [27]. The certificate authority is one kind of restricted trusted third party which ensures the relying on the signatures or other assertions made by the entities in the system. Note that the certificate authority brings very limited risks to the security of the patients EHR data and private information of the patients. As the private keys in our system are only known by the certificate appliers, any corrupt insiders or outside attackers have no ability to disclose the encrypted content by the public keys or forge the signatures by the private keys. The certificate authority could be the health department of the government or an international trusted organization which confirms the qualifications of doctors, pharmacists, insurance companies and secondary users, and issues them digital certificates. The certificates and the corresponding private keys of the appliers can be stored in the protected memory of smart cards owned by them with authenticating PINs to avoid abuse of the smart cards. We render the smart cards of a doctor and a secondary user as examples in Figure Patient s Secret and Certificate Each patient generates a major secret key (MSK) which is only known by the patient himself. MSK is very important to the patient, because all the private information in the EHR and the private communications with other entities associated to the patient will be protected by MSK. In an ehealth system where smart cards are widely used, the patient s MSK is usually stored in the protected memory of a smart card owned by the patient as shown in Figure 1. A PIN set by the patient is employed to authenticate the patient to avoid abuse. Unlike the certificates of doctors, pharmacists, insurance companies and secondary users, a patient s certificate is not issued by the certificate authority but by the insurance company in registration at an insurance company. Each patient generates a pair of private and public key (ISK, IPK), and the public key IPK will be sent to the insurance company in order to get a certificate. The corresponding private key (ISK) which is only known by the patient could be stored in the protected memory of the smart card owned by the patient. In the registration process, the patient s real identity will be known by the insurance company. In many countries, the health insurance premium of a patient is paid partly by the employer and partly by the patient, and the patient has to contact an insurance company in person to sign the insurance contract with the insurance company. So the real identity of the patient is hard to be hidden from the insurance company. However, the patient s identity information should not be included in the certificate issued by the insurance company. Typically, a certificate number which can only be mapped to the patient s real identity by the insurance company, a token of the insurance company, the public key of the patient, and the valid period are necessary in the patient s certificate. 3 ASE 2014 ISBN:

4 3.3 Ordinary Healthcare Activities A patient s ordinary healthcare activities include visiting the doctors, get medicines from the pharmacies by the prescriptions, viewing and managing his own EHR, and so on. In these activities the EHR entries will be created and retrieved by different entities in the systems. In the following two typical scenarios, we explain how the pseudonyms of the patients are generated and used together with the EHR data, and how the patients privacy is protected by using the pseudonyms Visiting a Doctor A patient visits a doctor, taking along his smart card. The doctor checks the validity of the patient by checking the patient s certificate and challenging the patient s ISK with the insurance company's root certificate. The doctor does not necessarily know the identity of the patient. But in practice, as the doctor is assumed to be trusted, it is usually the case that the identity (at least parts of identity information such as name, gender, age, and telephone number) of the patient is known to the doctor. After the doctor s diagnosing and treating, the doctor writes down a record (including diagnosis, examinations, treatment and other information), with a prescription stating the medicines that the patient needs to buy at a pharmacy. Meanwhile, a new pseudonym (PID) and an encryption key (EK) are generated from the MSK by the patient s smart card. Both the record and the prescription will be encrypted by EK and signed by the doctor s private key. Afterwards, all the data from the doctor are uploaded to the cloud along with an index header, the new PID, forming a new EHR entry for the patient. Thus, an EHR entry needs to be at least compatible with the following sections where means concatenation, EHR entry = PID Enc EK(record) Sign d(record) Enc EK(prescription) Sign d(prescription). According to the above definition of EHR entry, a patient s EHR may contain many EHR entries as the patient visited doctors many times. Each EHR entry has a unique pseudonym PID and a separate encryption key EK. Due to the use of pseudonyms, the content in an EHR entry could actually be partially encrypted. For example, the diagnosis, examinations and even prescription in one EHR entry could be plaintext. However, some private information such as age, gender, DNA information and other identifiers should be encrypted by EK if they appear, because this information could be used to deduce the real identity of a patient. The cloud stores the EHR entries of each patient by indexing the PID section of the EHR entries. The cloud can check the validity of the doctors by verifying their certificates and challenging their private keys with the trusted authority s help to avoid illegal uploading of EHR entries. The PIDs are regenerated by the patients when EHR entries need to be retrieved. For example, when a doctor wants to view the anamnesis of a patient or a patient wants to view his own EHR, the patient regenerates all the PIDs one by one and sends them to the cloud in order to retrieve the content in corresponding EHR entries Getting Medicines from a Pharmacy A patient goes to a pharmacy to buy medicines by using the prescription which is enclosed in one of his EHR entries. The patient retrieves the EHR entry from the cloud by providing the cloud a PID (the PID of the EHR entry with an unused prescription) and shows the decrypted prescription with the doctor s signature to the pharmacist. The pharmacist can validate the prescription by the signature of the doctor. If the signature is valid, the pharmacist generates an additional signature on the prescription indicating that the prescription has been used and asks the patient to update the original prescription s signature section of the EHR entry by including the pharmacist s signature. The cloud needs to check beforehand whether the patient is the owner of the EHR entry or not. Only if he is, the cloud updates the old prescription s signature section by adding the pharmacist s signature. After the pharmacist confirms that the patient has updated the prescription s signature section, the medicines are sold to the patient. In this procedure, we assume that the cloud has some knowledge of the structure of EHR entries, and only allows the patient adding new signatures to the prescription s signature section. To avoid reuse of the prescription, the pharmacist can check whether there is already another pharmacist s signature in the prescription s signature section of the EHR entry or not before accepting the prescription. Due to the updating of the prescription signature, the updated EHR entry with a pharmacist s signature looks like this, updated EHR entry = PID Enc EK(record) Sign d(record) Enc EK(prescription) Sign d(prescription) Sign p(prescription). 3.4 Secondary Use Although all the patients EHR stored together in the cloud can be publicly accessed (even in plaintext due to partial encryption) by any secondary user directly, a secondary user usually needs more information from a target patient for further use of the EHR data. The secondary user could give a notification to the patient by marking one EHR entry of the patient. The patient can respond to the secondary user by sending the secondary user a new notification. The pseudonyms can protect the patient s real identity against the secondary user in the communications. A detailed process of the secondary use of the pseudonymized EHR will be presented in Section 5 based on a concrete pseudonym scheme presented in Section Requirements for the Pseudonyms In order to protect the privacy of the patients from attackers in ordinary healthcare activities and secondary use, a proper pseudonym scheme should basically feature as follows. Decentralized, unique and independent This requires that the pseudonyms cannot be generated by others without knowing the patient s major secret key MSK. Only the patient can generates a unique PID for each EHR entry. The PIDs should be independent from each other. Irreversible 4 ASE 2014 ISBN:

5 One or more pseudonyms of one patient cannot be used to deduce the real identity of the patient. An attacker without knowing MSK cannot find out other pseudonyms of one patient from the knowledge of some PIDs of the patient. Ownership proof Pseudonyms can be used to verify the patient s ownership on one EHR entry without revealing the patient s real identity to the verifiers. Such a pseudonym scheme provides a secure way to protect the patients real identities and security of EHR data stored in the cloud when the EHR data are used in the ordinary healthcare activities and secondary use. Besides a proper pseudonym scheme, some related protocols to utilize the pseudonyms are also important to prevent the disclosure of the patient s privacy. Especially in the secondary use, since the secondary users need to contact the patients to get consent from and give feedbacks to the patients, communication protocols based on the pseudonym scheme needs to be carefully designed to avoid possible leakages of the patients identity information. 4. A Psedonym Scheme A pseudonym scheme as specified in Section 3 may have different designs. One of the designs is presented as follows. As presented in [26], it is based on the discrete logarithm problem on a cyclic group. 4.1 Secrets Setup A patient s main secret key MSK is initially set and only known by the patient when the patient gets a blank smart card. The setup of MSK needs the help of some software coupling with the smart card. MSK can be stored in the protected memory of the patient s smart card in which the password PIN (PIN is usually short and easily memorable) usually can be set by the patient to avoid abuse of the smart card. The patient chooses a k-bits (k is usually no less than 160) prime integer q, and another prime number p (the size of p is usually no less than 512 bits) which satisfy q (p-1). By Z p we denote a multiplicative group modulo p. The patient finds g Z p, to be of order q modulo p. Then g is the generator of the subgroup G q. By randomly choosing x G q, a patient s MSK is formed: [x, g, p, q]. Due to the complexity of solving the discrete logarithm problem [28], given g, h G q, such that h was selected from G q uniformly at random, it is hard to compute an integer x such that g x = h mod p. The computation complexity to find such x is no less than O( q ) [29]. For ease of notation, we will sometimes drop the mod p part of the arithmetic expressions in G q. We build up our secure pseudonym scheme based on the discrete logarithm problem in the subgroup G q. 4.2 Algorithm for Generating PIDs We denote PID0 as (a0, b0) which is (0, 0) by default (PID0 could be some serial number to avoid possible pseudonym collisions and security risks as discussed in Section 6.2.1). Assuming that previously a patient has already generated and used i PIDs (i.e., PID1, PID2,, PIDi), the i+1 th pseudonym PIDi+1 can be generated by the following algorithm where means bit concatenation. INPUT: PID0 = (a0, b0), i, MSK, PIN (to be authenticated by the smart card) OUTPUT: PIDi+1, EKi+1 EKi+1 = KHash (i+1 a0 b0, x), where KHash is a keyed hash function by key x ai+1 =g EK i+1+hash(a 0 b 0 ) mod q, bi+1 = a i+1 PIDi+1 = Hash(ai+1 bi+1) Since the order number of the last used PID, i.e. the number i, is needed to generate the next new PID, the order number of the last PID should be stored somewhere, e.g., in the patient s smart card. EKi+1 can be used as the encryption key (it might be necessary to be truncated or padded according to the encryption algorithm) for encrypting the private contents of the EHR entry with the index of the new pseudonym PIDi Algorithm for Reproducing PIDs All the pseudonyms and encryption keys can be reproduced one by one through the following algorithm. INPUT: PID 0 = (a 0, b 0 ), MSK, PIN, last ( the order number of last used pseudonym PID last ) OUTPUT: PID1~PIDlast, EK 1 ~EK last FOR i=1 TO last DO EK i = KHash(i a 0 b 0, x), a i = g EK i+hash(a 0 b 0 ) mod q, b i = a i x PIDi = Hash(ai bi) The above algorithm shows how to reproduce all the used pseudonyms and the encryption keys. In fact any single PIDi and EKi pair can be reproduced by executing one single loop of the above algorithm. 4.4 Protocol for Verifying the Ownership of EHR Entries Following is the protocol for the verifier, e.g. cloud (abbreviated as C), validating a patient s (abbreviated as P) ownership of one EHR entry with pseudonym PID, where means sending a message. INPUT: an EHR entry with PID in the cloud; p, q of the patient s MSK are known by the cloud OUTPUT: Yes or No. P C: Patient sends (a, b) such that PID = Hash(a b) C: checks whether PID?= Hash(a b). If not, C returns No; otherwise continues. P C: Patient randomly chooses s, calculates and sends (A=a, B=a s mod p) C P: Cloud randomly chooses and sends c P C: Patient computes and sends y = s+cx mod q C: checks a y?= Bb c mod p. If yes, C returns Yes; otherwise returns No. x 5 ASE 2014 ISBN:

6 The security of the above algorithm and protocol relies on the difficulty of the discrete logarithm problem in G q and the one-way property of the hash function. Only the patient possessing the secret x can respond to the cloud s challenge correctly. Anybody else who wants to impersonate the patient is required to compute the discrete logarithm in G q which is conjectured to need the complexity of O( q) [29]. 5. Secondary Use of Pseudonymized EHR 5.1 Searching for Target Patients The pseudonymized EHR entries of all patients are publicly accessible in the cloud. A secondary user such as a clinical scientist in cancer research could surf in the cloud to look for target patients. Due to the partial encryption on the EHR data, the researcher can use the fast plaintext search service provided by the cloud to query any target EHR entries by some keywords such as cancer and tumor. The cloud could return the researcher all the available EHR entries in which the key words are matched. After the researcher finds out the EHR entries which are owned by unknown patients, the researcher needs to get more information from the patients. Firstly, the researcher usually needs to know which of these EHR entries belong to one patient. One patient might have multiple separated EHR entries regarding one disease (e.g. a chronic disease needs to be treated for many times, and each time a new EHR entry with a new PID is created), and these EHR entries are separately marked by the researcher. The researcher cannot sort these EHR entries without the help of the patient due to that the PIDs of one patient are independent from each other. Secondly, the researcher may want to obtain some further health information (e.g. related diseases) about the patient. However, the researcher could not find out any other EHR entries of the patient, because the researcher has no way to know what other pseudonyms the patient might have. At last, the researcher might want to know some personal identifiers of the patient (e.g., age, gender) and some more information which might be encrypted in the EHR entries by the encryption key EK only known by the patient. The researcher has to be able to contact these target patients and get help from the patients as these information can only be provided by patients themselves who know the MSK. 5.2 Inviting Target Patients and Managing Consent As the EHR data are highly private information, using these data outside of clinics or hospitals is usually restricted in laws and regulations. The researcher has to get signed consent from the patients to use the patients EHR data for some specified purposes (e.g. medical research). In the ehealth system, the consent can be digital files with digital signatures by patients through a digital signature scheme. After finding in the cloud an EHR entry which would come from a potential target patient, the researcher prepares a digital file for the patient s consent declaring the purpose and other information about the research. The consent can also include what information the researcher needs more (e.g. gender, age, other EHR entries of related diseases) from the patient. Then the researcher sends an invitation including the consent file to the patient who owns the EHR entry by asking the cloud to mark that found EHR entry as follows, Marked EHR entry = Original EHR entry Invitation Sign R(Invitation), where Invitation = uid Cert R Consent. The content of Original EHR entry is referred to the Section and Cert R is denoted as the certificate of the researcher, and Sign R(Invitation) means the signature of the researcher on the Invitation. uid is a long rand number the researcher generates and it intends to stand for the unique number of the patient. So the uids need to be collision free. The cloud must validate the researcher by checking the certificate of the researcher and challenging the private key of the researcher before the cloud accepts the researcher updating one EHR entry as above. 5.3 Responding to the Secondary User The patient who is the owner of the Marked EHR entry may get informed when he retrieves his EHR entries next time. Before accepting the invitation, the patient can at first check the validation of the Invitation. He can validate the invitation by checking the researcher s certificate and the signature of the Invitation. To accept the invitation, he can update the Marked EHR entry as follows, Agreed EHR entry = Marked EHR entry Reply where Reply = Enc PKR(uid Filled Consent Sign p(filled Consent) EK). Enc PKR means encrypting by the public key of the researcher in the researcher s certificate. The patient fills the identifiers (e.g. age, gender) and PIDs of other related EHR entries into the consent to form the Filled Consent if the researcher required. Sign p means the patient signs the Filled Consent to generate a signature. EK is the encryption key of each corresponding EHR entry as explained in Section 4.2. Sometimes the patient may have multiple EHR entries marked by the researcher, and each EHR entry was assigned with a different uid. The patient has to choose an arbitrary one from the assigned uids and enclose it into all his agreed EHR entries. If the researcher required the patient to provide some other health information (e.g. other EHR entries of some related diseases), the patient can attach the corresponding Enc PKR(uid EK) to the end of other related EHR entries which were not marked by the researcher. The patient has to tell the researcher EK to enable researcher to decrypt the required information which is encrypted in the EHR entries. If the EK was used to encrypt the patient s private information which is not intended to be known by the researcher, the patient can derive a new EK from EK (e.g. EK = Hash(EK+1)) to encrypt the information that could be known by the researcher and enclose EK in the Agreed EHR entry. Before the cloud accepts the patient s updating on the EHR entry, the cloud needs to verify whether the patient is the owner of the EHR entry or not to avoid malicious updates. The protocol in section 4.4 can be used to do the verification without disclosing any identity information of the patient to the cloud. The patient can also deny the invitation from the secondary user by saying No in the Reply or simply remove the secondary user s 6 ASE 2014 ISBN:

7 Invitation or giving no Reply to the Marked EHR entry. The patient may use the certificate from the insurance company and the corresponding private key (ISK) to sign the filled consent. However, sometimes the patient may mind the secondary user s knowing his certificate in the insurance company, as a secondary user might collude with the insurance company to discover the patient s real identity and private information in the EHR entries. In this case, the patient could also apply another certificate at the certificate authority to be used to communicate with secondary users. It could be a kind of anonymous certificate where the patient does not need to provide the real identity to the certificate authority. However, an attacker may impersonate the patient to respond to secondary user with the attacker s anonymous certificate from the certificate authority. The attack can be ruled out by the following two reasons. Firstly, the attacker could not pass through the ownership verification by the cloud. So the cloud will not allow the attacker to add forged reply if the attacker fails to prove the ownership of the EHR entry by the protocol in Section 4.4. Secondly, even if the attacker succeed in adding a forged reply to the EHR entry, the secondary user can easily drop the forged reply by checking the encryption key EK. As the attacker could not provide the correct EK, the secondary user can distinguish the forged reply from a failed decryption by incorrect EK. Other than that, if the patient has multiple EHR entries marked by the secondary user, as the attacker cannot know which marked EHR entries belong to the same patient, the secondary user can check the consistence of the information (e.g. birth date) in these multiple EHR entries to drop forged replies. The countermeasures to avoid forged reply may complicate or disturb the process of secondary use a bit, but the attacker could not benefit from the attacking to know any more private information about the patients. 5.4 Sending Feedback to Patients The researcher can discover whether her marked EHR entries are replied by the owners or not when she visits the cloud once again. The Reply of the agreed EHR entries can be decrypted by the researcher s secret key. Then the consent and the signatures of the patients could be extracted out. Afterwards, the encrypted data (e.g. gender and age) in the EHR entries can be decrypted by using the EKs enclosed in the replies by the patients. The researcher distinguishes different patients by uid. I.e., all the Agreed EHR entries with the same uid come from one patient. Till now, the researcher could find out all necessary information to conduct her research. After the researcher finishes her research, she might have some feedbacks to the patients. She may send a feedback to a patient by updating an agreed EHR entry like following, Feedback EHR entry = Agreed EHR entry Enc EK(Feedback Sign R(Feedback)). The Feedback could include any message sent from the researcher. Sign R(Feedback) is the researcher s signature on the Feedback. The Feedback and the signature from the researcher are encrypted by the encryption key EK of the corresponding EHR entry. Only the patient who knows the EK can decrypt the feedback. The patient can view the feedback when he accesses the cloud next time. 6. Evaluations 6.1 Features for Privacy Protection Fulfilling the Basic Requirements In Section 3.5, some basic requirements of the pseudonym scheme were discussed to apply the pseudonym scheme in the ordinary healthcare activities and secondary use. We explain the fulfillment of the pseudonym scheme presented in Section 4. Decentralized, unique and independent Each patient generates his own pseudonyms during the visiting to the doctors by using the algorithm presented in 4.2. The algorithm needs the patient s MSK which is only known by the patient. So the PIDs can only be generated by each patient. Due to the hash function used in the algorithm, the pseudonyms have negligible probability to collide. Different PIDs are generated from hash functions with different inputs, so the PIDs can be considered to be independent with each other. Irreversible The pseudonyms of each patient are generated finally by a hash function which could be considered as a one way function. So it is difficult to deduce the secret inputs for generating the pseudonyms. I.e., it is impossible to disclose the patient s real identity from knowing of any amount of PIDs. As each PID generation needs the patient s MSK, it is impossible for others to generate any other PIDs from knowing some PIDs of the patient. Ownership proof The protocol presented in Section 4.4 is used by the patient for the ownership proof to a verifier. The algorithm convinces the verifier that the patient knows the MSK for generating the PID of the EHR entry and thus the patient is the owner of the EHR entry. During the ownership verification process, the verifier can learn nothing else about the identity information of the patient. The verification also can resist replay attack as the random values used in the protocol Protecting Patients Privacy against the Insurance Companies In many practical ehealth systems, the insurance companies may know much information about the patients illnesses besides the patients identities. Here we discuss from a technical perspective how to prevent the insurance companies from knowing so much in the ehealth systems where our pseudonym scheme is used. The patients certificates issued by the insurance companies are used by doctors or pharmacists for validating patients insurance status. Since the patients certificates and corresponding private keys (ISK) are not used for encrypting or signing EHR data stored in the cloud, an insurance company that knows patients 7 ASE 2014 ISBN:

8 identities and certificates cannot know the content of EHR entries of the patients without knowing the encryption keys of the patients. Because the insurance company does not either know the pseudonyms of the patients, so the insurance company cannot actually know which EHR entries the patients have in the cloud. However, the insurance companies may still get important information about the patients illnesses from billing procedure in the following example. A bill from a doctor will be attached with both a doctor s signature and a patient s signature by the patient s certificate from the insurance company and corresponding private key (ISK). The bill is received and paid by the insurance company. Because the details of the bill usually contain a lot of information about the patient s illness (e.g. medicines, list of examinations and therapies), the insurance company can infer the illness type from the details of the bill for the patient. Beyond the limited privacy protection against insurance companies in this solution, some work to protect patients privacy against insurance companies as much as possible using pseudonymization appears at [26]. The solution provided pseudonymized bills to prevent the insurance companies from knowing which patients the bills are for Trustworthiness of the Cloud In this paper, the cloud is not only used as a scalable storage media for EHR data, it is also required to perform some validations. E.g., it verifies the ownership of EHR entry when a patient wants to update the EHR entry to send a reply in the secondary use, and it also validates a secondary user who wants to send an invitation to the EHR owner by updating one target EHR entry. This may require the cloud be honest or semi-trustworthy. However, this is reasonable in practice, because a dishonest cloud cannot benefit from the unintended operations (like modifying or forging the messages in secondary use) to get more private information of the patients. It only disturbs the normal process of secondary use. Furthermore, a dishonest operation can be easily detected by the patients or the secondary users, because all the messages between the patients or the secondary users have integrity check (e.g., encryption or signature). 6.2 Attacks and Countermeasures Guessing Attacks against Secret Keys The patients main secret key MSK may encounter a brute guessing attack if it is not well designed. A patient s secret x in his MSK usually is a large integer with a length of more than 160 bits as introduced in Section 4.1. An attacker only has a probability of 1/2 160 to guess a right x in MSK through one random attempt. But in the setting of this paper, the attacker may have better luck than random guess because of the public accessibility of the cloud. The attacker tries a random x and computes the first pseudonym by using the algorithm in Section 4.2. Then the pseudonym is sent to the cloud to ask whether a corresponding EHR entry with this pseudonym exists or not. If so, the attacker has successfully guessed an x of one patient in the system. If there are N patients in the system, the probability of success is N/2 160 which is much higher than the theoretical value 1/2 160 if N is large. A successful guess of one patient s secret may cause serious consequences as the attacker can view all the patient s EHR data and even impersonate the patient. However, it is not practical for the attacker to succeed in the attack as N is not that big. There are some ways to rule the attack out when N is considerably large. One way is to let the patient to choose g, p, and q besides x in the MSK. This will increase computation effort a little when a patient initializes his smart card, but it can add a big burden to the attacker. The attacker has to guess g, p, and q which are also big numbers besides x. It will make the success probability of the attacker s guess drop to a negligible value. Another way is to utilize PID0. In the algorithm of the pseudonym generation in Section 4.2, PID0 is a parameter and is by default set to (0, 0). To prevent attackers from guessing the patients secret keys, each patient can have a different PID0. Then the attacker needs to guess PID0 besides x. It will also make the success probability of the attacker s guess drop to a negligible value Attacks from Eavesdroppers When a patient accesses his EHR on the computer at home or on a mobile device, an attacker being able to monitor the network traffic (an eavesdropper) may record down all the pseudonyms that the patient sends to the cloud. Some eavesdroppers, e.g. the neighbors of the patients, might have chance to know the patients real identities. What is more, in many countries, the patients real identities are known by the ISP that provides Internet service. If the ISP wants to, it can easily record the pseudonyms that the patient sends to the cloud. An easy way to prevent the ISP or the eavesdroppers from knowing the mapping of the pseudonyms to patient s identity is to use secure channel for transmitting unencrypted data between patients and the cloud Potential attacks in Secondary Use A skilled attacker would succeed in modifying the marked EHR entries by replacing the researcher s certificate by the attacker s certificate. This attack can be easily ruled out by the patients from validating the certificate and signature of the secondary user before he proceeds to the next step of the secondary use. Also the attacker may easily eavesdrop the messages updated to the EHR entries, but in our communication protocols, all the critical information (like EK) in the messages is encrypted by the keys only known by the communicators. All the eavesdroppers cannot get any more private information of the patients from the communications between patients and secondary users other than the pseudonymized EHR contents existing in the cloud. 6.3 Implementation We implemented a prototype of our system in a PaaS cloud platform. The prototype implementation can be divided into three layers as shown in Figure 2: local clients, PaaS application, and database. The interfaces for local clients (e.g. patients, doctors, pharmacists and secondary users) are written in HTML5 and JavaScript. Common scenarios in the ordinary healthcare activities and secondary use are basically supported in separate web views. The smart cards of all the clients are simulated by a software module existing in the browsers of the clients. Due to the fact that the codes 8 ASE 2014 ISBN:

9 for creating, encrypting and signing the EHR entries are executed on the computers of the clients, it puts much less scaling pressure to the cloud. The PaaS application layer deals with the logics for all the ehealth Local PaaS Database Client Client Client Application Application MongoDB MongoDB MongoDB Client Client Application MongoDB MongoDB MongoDB Figure 2 Architecture of the prototype implementation transactions, such as validating the incoming data and verifying the ownership of the EHR entries in updating operations. The applications written in Python are stateless, which allows running multiple instances. The scalability can be easily achieved by adjusting the amount of the containers in each of which an instance of the application resides. The applications are currently hosted on top of a PaaS provider cloudcontrol [30] and can easily be transplanted to other PaaS providers. MongoDB is chosen as the backend database for storing the EHR objects efficiently with excellent scalability to multiple servers. The database can be easily extended by either sharding or replica-sets to handle high load and big data scenarios. The JSON-like data structure enables easy extension of the data format and allows different attributes in each EHR entry. To get an idea how many simultaneous requests can be handled by the cloud, different load tests are conduct for different application scenarios. These load tests provide the application throughput and give suggestions for the scaling up or down the resources depending on the load. In Figure 3, we give two examples of our tests for creating (a) and reading EHR (b) entries by simultaneous clients. We define a successful response as returning result without any errors. The results of the two tests show that the average response time of cloud stays almost stable with the reasonable increase of connections. For greater detail about our prototype implementation, please refer to the website where we put our code [31]. One can act as a patient, doctor, pharmacist, or secondary user at this website. (a) One minute load test on a sharded MongoDB setup for 60 to 180 patients who are creating EHR entries. The response time stays almost stable. The peak around 00:38 can be explained as a new allocation of data files on one of the servers. (b) One minute load test on a sharded server setup for 20 parallel researchers who are searching EHR entries based different criteria from a test database with around 1 million EHR entries searches were successful responded within this test. 7. Discussion Figure 3 Load test examples This paper presented a pseudonymized solution for ehealth systems which facilitates especially the secondary use of EHR in the cloud to a world range. The public accessibility of the cloud enables the secondary users to access the whole population s health data stored in the cloud. Any secondary user who owns a legal certificate can directly view and search the pseudonymized and partially encrypted EHR in the cloud to find potential target patients and communicate with the patients with our proposed protocols. No trusted third party is needed to de-identify (pseudonymize or anonymize) the EHR data for patients. This will simplify the process of secondary use of EHR data. More than that, this will avoid the risks of disclosing the patients privacy during the de-identification. The solution also provides an easier way for the secondary users to get the consent from the patients. Traditionally, the patients need to sign some paper consent to agree on some ongoing or future potential secondary uses of their EHR data. That would be very inefficient and usually worry the patients for unintended use of their EHR data. In our solution, the patients can clearly know what their EHR data are used each time through reading the consent. And the patients have more control on their EHR data for secondary use with positive or negative replies to the secondary users. Feeding back from the secondary users to the patients is naturally supported in our solution. It is an important purpose to let the patients know more about their health from the feedbacks for some secondary uses. The feedbacks from the secondary users can often interest and motivate patients. In our solution, neither real contact information of patients nor a trusted third messenger is necessary in the communication process. The feedbacks are sent from the secondary users in an encrypted manner and can only be read by the patients themselves. During the communications between patients and secondary users, the patients real identity information is never disclosed to anybody. Instead, the pseudonyms of the patients are used to connecting patients and secondary users. Although the secondary users could get consent and other information from the patients, and give feedbacks to the patients, they never know the real identities or the contact information of the owners of the 9 ASE 2014 ISBN:

10 EHR data during the whole process. Hence, the privacy of the patients is properly protected against the secondary users as the EHR data seem to be anonymous to the secondary users or other attackers. However, we also notice some unresolved problems in our solution. We assume that all the patients could read the invitations from the secondary users and respond in time. In practice, some patients may not frequently access their EHR entries and check the invitations. This will delay the progress of the secondary use in some cases. To avoid the delay, we might need additional notification schemes. E.g., instead of the patients, doctors who treated the patients and have more chances to access the cloud could help to notify the patients to receive the invitations when their EHR entries are marked by a secondary user. Another drawback in our system is that patients are fully in charge of reading the consent and feedbacks. This might require the patients have some professional knowledge about medicine or healthcare. This may be not the case to many patients in practice. Thus, we need to educate the patients or have additional auxiliary help systems. In the future work, we will continue to seek resolutions to these problems and evaluate it in a perspective of practice to discover further problems. We have implemented a prototype of the whole pseudonymized ehealth system on a PaaS cloud serving most functions in the ordinary healthcare activities and secondary use. The system is still under construction by testing current functions and adding more features. We hope this prototype implementation could give more practical advices to our theoretical design and be used to demonstrate the basic functions and features of our solution to interested reviewers and investors in future. It is also expected to help discover some security flaws in the public tests. The source codes are also shared at Github upon request from interested researchers and developers. Acknowledgement We would like to thank Dr. Adrian Spalka and Jan Lehnhardt who raised many challenges and comments from the viewpoint of practical ehealth systems to this paper. We also appreciate Dr. Hui Zhang from Department of Neuropsychology in University of Bochum who read this paper revising for language issues. References [1] D. Garets, and M. Davis, Electronic medical records vs. electronic health records: yes, there is a difference, Policy white paper. Chicago, HIMSS Analytics, [2] A. E. Shields, P. Shin, M. G. Leu, D. E. Levy, R. M. Betancourt, D. Hawkins, and M. Proser, Adoption of health information technology in community health centers: results of a national survey, Health Affairs, vol. 26, no. 5, pp , [3] T. Schabetsberger, E. Ammenwerth, S. Andreatta, G. Gratl, R. Haux, G. Lechleitner, K. Schindelwig, C. Stark, R. Vogl, I. Wilhelmy, and F. Wozak, From a paper-based transmission of discharge summaries to electronic communication in health care regions, Int J Med Inform, vol. 75, no. 3-4, pp , Mar-Apr, [4] C. Safran, M. Bloomrosen, W. E. Hammond, S. Labkoff, S. Markel-Fox, P. C. Tang, and D. E. Detmer, Toward a national framework for the secondary use of health data: an American Medical Informatics Association White Paper, Journal of the American Medical Informatics Association, vol. 14, no. 1, pp. 1-9, [5] T. Botsis, G. Hartvigsen, F. Chen, and C. Weng, Secondary use of EHR: data quality issues and informatics opportunities, AMIA summits on translational science proceedings, vol. 2010, pp. 1, [6] C. H. Infoway, White Paper on Information Governance of the Interoperable Electronic Health Record, overnance%20paper%20final_ _en.pdf, [7] P. L. Elkin, B. E. Trusko, R. Koppel, T. Speroff, D. Mohrer, S. Sakji, I. Gurewitz, M. Tuttle, and S. H. Brown, Secondary use of clinical data, Stud Health Technol Inform, vol. 155, pp , [8] M. A. Rothstein, Is deidentification sufficient to protect health privacy in research?, The American Journal of Bioethics, vol. 10, no. 9, pp. 3-11, [9] A. Pfitzmann, and M. Hansen, Anonymity, unlinkability, undetectability, unobservability, pseudonymity, and identity management-a consolidated proposal for terminology, Version v0, vol. 31, pp. 15, [10] P. Mell, and T. Grance, The NIST definition of cloud computing (draft), NIST special publication, vol. 800, no. 145, pp. 7, [11] Z. Rui, and L. Ling, "Security Models and Requirements for Healthcare Application Clouds", In Cloud Computing (CLOUD), 2010 IEEE 3rd International Conference on, pp IEEE, [12] C. Stingl, and D. Slamanig, Privacy-enhancing methods for e-health applications: how to prevent statistical analyses and attacks, International Journal of Business Intelligence and Data Mining, vol. 3, no. 3, pp , [13] R. H. Dolin, L. Alschuler, S. Boyer, C. Beebe, F. M. Behlen, P. V. Biron, and A. S. Shvo, HL7 clinical document architecture, release 2, Journal of the American Medical Informatics Association, vol. 13, no. 1, pp , [14] D. Kalra, T. Beale, and S. Heard, The openehr foundation, Studies in health technology and informatics, vol. 115, pp , [15] ANSI, ISO. "TS Health Informatics-Requirements for an Electronic Health Record Architecture, [16] C. J. McDonald, S. M. Huff, J. G. Suico, G. Hill, D. Leavelle, R. Aller, A. Forrey, K. Mercer, G. DeMoor, and J. Hook, LOINC, a universal standard for identifying laboratory observations: a 5-year update, Clinical chemistry, vol. 49, no. 4, pp , [17] J. A. Maldonado, C. M. Costa, D. Moner, M. Menárguez-Tortosa, D. Boscá, J. A. Miñarro Giménez, J. T. Fernández-Breis, and M. Robles, Using the ResearchEHR platform to facilitate the practical application of the EHR standards, Journal of biomedical informatics, vol. 45, no. 4, pp , [18] S. Rea, J. Pathak, G. Savova, T. A. Oniki, L. Westberg, C. E. Beebe, C. Tao, C. G. Parker, P. J. Haug, and S. M. Huff, Building a robust, scalable and standards-driven infrastructure 10 ASE 2014 ISBN:

11 for secondary use of EHR data: the SHARPn project, Journal of biomedical informatics, vol. 45, no. 4, pp , [19] Microsoft, HealthVault, [20] Z.-R. Li, E.-C. Chang, K.-H. Huang, and F. Lai, A secure electronic medical record sharing mechanism in the cloud computing platform, In Consumer Electronics (ISCE), IEEE 15th International Symposium on, pp IEEE, [21] A. Lysyanskaya, R. L. Rivest, A. Sahai, and S. Wolf, Pseudonym systems, Selected Areas in Cryptography, pp , [22] L. Xu, and A. B. Cremers, A Decentralized Pseudonym Scheme for Cloud-based ehealth Systems, Proc. International Conference on Health Informatics, pp , [23] K. Pommerening, and M. Reng, Secondary use of the EHR via pseudonymisation, Studies in health technology and informatics, pp , [24] L. L. Iacono, Multi-centric universal pseudonymisation for secondary use of the EHR, Studies in health technology and informatics, vol. 126, pp. 239, [25] J. Lehnhardt, and A. Spalka, Decentralized generation of multiple, uncorrelatable pseudonyms without trusted third parties, Trust, Privacy and Security in Digital Business, pp : Springer, [26] L. Xu, A. Cremers, Patients Privacy Protection against Insurance Companies in ehealth Systems, in: K. Bernsmed, S. Fischer-Hübner (Eds.) Secure IT Systems, Springer International Publishing, 2014, pp [27] D. Solo, R. Housley, and W. Ford, Internet X. 509 public key infrastructure certificate and certificate revocation list (CRL) profile, [28] K. S. McCurley, The discrete logarithm problem, Proc. Symp. in Applied Math, vol. 42, pp [29] C. H. Lim, and P. J. Lee, A key recovery attack on discrete log-based schemes using a prime order subgroup, Advances in Cryptology CRYPTO'97, pp : Springer, [30] PaaS provider, [31] Prototype, 11 ASE 2014 ISBN: