Sage Journals: Discover world-class research

Abstract

Peking University has several prestigious teaching hospitals in China. To make secondary use of massive medical data for research purposes, construction of a clinical data warehouse is imperative in Peking University. However, a big concern for clinical data warehouse construction is how to protect patient privacy. In this project, we propose to use a combination of symmetric block ciphers, asymmetric ciphers, and cryptographic hashing algorithms to protect patient privacy information. The novelty of our privacy protection approach lies in message-level data encryption, the key caching system, and the cryptographic key management system. The proposed privacy protection approach is scalable to clinical data warehouse construction with any size of medical data. With the composite privacy protection approach, the clinical data warehouse can be secure enough to keep the confidential data from leaking to the outside world.

Keywords

Clinical data warehouse data encryption hospital information system privacy protection

Introduction

In the last two decades, we have witnessed an ever increasing volume of data that is being collected in hospital information systems (HISs), especially in electronic medical records (EMRs). As clinical databases provide a rich source of data for research in areas such as medical care delivery and medical quality monitoring, how to make secondary uses of those collected large volume data has become a hot research topic in the literature.^1–5 Abhyankar et al.⁶ proposed a method to standardize clinical laboratory data for secondary use. Tolar and Balka⁷ put forward advice about how to enhance care through secondary use of EMR data in a general practice setting. The Strategic Health IT Advanced Research Projects Area 4 Consortium (SHARPn) project funded by the US government in 2010 to build a robust infrastructure for secondary use of electronic health records (EHRs) data has taken shape.⁸

Driven by demand, data warehousing has been proposed as a way of supporting secondary use of those invaluable medical data maintained in current HISs.^9,10 With the aid of data warehousing technologies, we can collect and integrate data from various HISs, and build multidimensional patient information cubes or data marts. Based on the raw, aggregate, or statistical information displayed in a clinical data warehouse (CDW), researchers may have various hypotheses tested, which can stimulate further research in healthcare-related issues. Several CDWs^11,12 have been developed for this purpose.

However, with the increasing complexity of integrating patient data from different departments or hospitals, and the keen desire of other entities such as insurance companies and pharmaceuticals companies to access these data, serious pressure is put on a CDW’s capability to protect patient privacy. Privacy violations may result in loss of dignity, and confidential information from a person’s medical record may influence his or her credit, employment, and the ability to get health insurance.¹³ Therefore, protecting patient privacy becomes a big challenge for CDW designers.

In response to these concerns, various methods have been employed. From the policy and law side, several bills were introduced during the past two decades in some developed countries. Take the United States as an example; the Health Insurance Portability and Accountability Act (HIPAA) was signed into law in 1996, and component privacy regulations were published in December 2000.¹⁴ However, in China, due to the fact that China is a developing country, the most worrying aspect regarding healthcare services for citizens is medical cost, and only a small portion of the population may be conscious of their privacy in the process of seeing a doctor. Research on patient privacy protection is still in its initial stage, and aside from some graduates’ theses^15,16 that discuss the issue of legislation to protect patient privacy, there is neither a specific bill nor regulation regarding patient privacy protection. From the technology side, first, user access control^17,18 has been proposed as a measure to limit users’ access to confidential and sensitive data. Second, lots of methods for data encryption and pseudonymization have been proposed by researchers^19–23 to protect privacy. In this article, we propose the use of composite methods to implement privacy protection in CDW, which is being developed at Peking University (PKU). In our composite approach, the privacy model is composed of various data encryption methods and a user access control mechanism in a layered CDW structure, and we mainly describe the composite data encryption approach in this article.

The structure of this article is as follows: a brief introduction of the Peking University Clinical Data Warehouse (PKUCDW) and the necessity of protecting patient privacy in the CDW are given in the “Background and significance section”; the “Methods” section presents a composite privacy protection model designed for the PKUCDW; and finally, the “Conclusion” section summarizes the results and the contribution of this article.

Background and significance

Background of PKUCDW

PKU is affiliated with six prestigious teaching hospitals. Three of them are general hospitals, and three others are special hospitals specializing in cancer, dentistry, and mental disorder. All affiliated general hospitals have adopted HISs such as EMRs, laboratory information systems (LISs), pharmacy information systems (PISs), picture archiving and communication system (PACS), and so on. Motivated by making secondary use of large volume data collected in HISs, a research group at Peking University Medical Informatics Center (PKUMIC) with experts from computer science, decision making, data mining, statistics, and epidemiology was formed in 2011. A very important mission for PKUMIC is to centralize and integrate data from HISs located in all affiliated hospitals and to develop a CDW to extract new knowledge and valuable information from a large volume of medical data.

Structure of PKUCDW

We adopted the architecture proposed by Inmon²⁴ to design our CDW. In this structure, a data warehouse (DW) should be a repository that provides data for data marts, which are created only after the creation of a complete DW.

Inmon’s DW structure matches our requirement for a CDW very well. The main mission of PKUCDW is to warehouse the data in main HISs across all affiliated hospitals and to analyze the data from different research angles. The end users of PKUCDW include not only researchers at PKUMIC but also medical staff in affiliated hospitals. As different users would require data for analysis from their own perspectives, it would be better if we could provide them with different data marts or cubes according to their specific requirements. Here, a cube implies something very specific, while a data mart is more inclusive and it can have tables or cubes. The structure of PKUCDW is shown as in Figure 1.

Figure 1.

Structure of PKUCDW.

Privacy concerns

The biggest concern for the public about making secondary use of data in HISs is patient privacy violation. Besides those routine clinical data such as common clinical symptoms and laboratory results that are stored in HISs, confidential data such as Name, Address, Telephone number, Medical record number, Identification card number (IDN), Health insurance card number, and sensitive data such as HIV/AIDS status information are also included. If these confidential and sensitive patient data get disclosed to the public or some malicious users, it may cause negative effects for the patients. Besides patients’ confidential and sensitive information, there are some privacy data of doctors that are stored in HISs as well. For example, detailed information such as Name, Address, Telephone number, and Employee’s card number of clinicians are stored in the HISs together with patient data. Thus, we have concerns about not only patients’ but also clinicians’ privacy in the design and development of PKUCDW.

In our case, although all researchers and staff involved in the CDW project have signed agreements with PKUMIC or affiliated hospitals on privacy protection, there are still concerns about internal personnel disclosing, as all parties with strong interests in the EMRs data may make every possible attempt to access the data. Take pharmaceutical companies, for instance, as clinicians in different hospitals may have different preferences in prescribing medicines for patients, salesmen from pharmaceutical companies are keen to get EMR data to do analysis about which clinician in which hospital favors which medicines. With the above concerns in mind, it is necessary for us to employ technological methods together with administrative procedures to protect data privacy in the design and development of PKUCDW.

Overview of privacy protection methods

In general, privacy protection can be enforced from two perspectives. From one perspective, protecting privacy needs to limit the number of users that can access the data, and from the other perspective, protecting privacy needs to limit the data that can be accessed. For limiting users’ access to data, different user access control mechanisms have been proposed and employed in the literature.^{17,18,25–27} For limiting the data that can be accessed by users, different data de-identification approaches have been developed.^21,22,28,29 Procedures from administration perspectives and methods from technological perspectives have been proposed and employed in a complementary way in the literature.^{7,21,22,25,30} However, most methods employed in the literature are for medical data sharing or publishing, and they lack viable and practical approaches to comprehensively protect patient privacy from the beginning of HISs data transmission to the end of researchers’ data manipulations.

Data encryption

The general approaches used to protect or to de-identify person-specific confidential and sensitive information include data encryption and data pseudonymization.^7,19–21 As our study focuses on encrypting data to protect privacy, we only briefly discuss data encryption methods in the following. Data encryption can protect sensitive data from unauthorized access. Two widely used data encryption methods in the literature are symmetric block cipher and public key cryptography. A symmetric block cipher uses a permutation–substitution network to encrypt a fixed size of data block, with a predefined encryption key. The security of a block cipher depends on the length of the encryption key, and the time complexity of a brute force attack against a cipher of 256 bits key is O(2²⁵⁶).³¹ Unlike a symmetric block cipher, which uses one shared secret key between two partners, a public key cryptography system uses two keys, one private key, which is kept secret to itself, and one public key, which can be published to the outside world. The security of a public key cryptography relies upon the asymmetric behaviors of some well-known hard mathematical problems, for example, integer factorization and discrete logarithm problems. The public key cryptography technique provides security functionalities such as data encryption, key exchange, and digital signature.

Methods

Message-level encryption

Since the patient data such as name, IDN, and other information are very critical and sensitive, we need to provide an end-to-end protection for them. The name and IDN must be encrypted at rest and in-transit, starting from the upload server of the hospital HIS system to the backend system in the CDW. Encrypting data at rest can effectively prevent sensitive data from being accessed by unauthorized users. Even if the malicious third party gained access to the electronic media, the data they receive are cipher-texts, whose original meaning cannot be revealed without proper cryptographic algorithms and encryption keys. Encrypting data in-transit can protect the data from eavesdropping when data are transmitted along wired or wireless communication channels. Without correct cryptographic algorithms and keys, the malicious third party cannot recover the original plain-text from the cipher-text in a reasonable amount of time.

Encrypting data at rest can be implemented by a variety of techniques at different layers, from the lower level hard drive encryption to higher level application layer data encryption. Although hard drive encryption is an easy solution, we chose not to apply it in the CDW for several reasons. The first reason is that if all data on the hard disk are encrypted, they will have to be decrypted when being read by the applications, which results in a significant reduction in performance. The second reason is that the hard-disk encryption can only protect the data from breaching in some special cases such as when the system is powered off and the hard drives are stolen. When the system is up and running, the data on the hard drive is decrypted automatically and become clear-texts to end users, including malicious users who break into the system, which actually defeats the whole purpose of data encryption.

Another solution is to use database layer encryption technologies to enforce data encryption at rest. The advantage of this solution is the ease of use and user transparency, which means existing applications can run smoothly without code change. However, a big disadvantage of this solution is that it is limited to a particular database product, which makes the interoperability between different products a big problem. Another issue is the limitation of the cryptographic key management capabilities of database column-level encryption solution, because existing solutions ordinarily use only one key for each table or for each column. If one key is compromised, then a bunch of data will be leaked. The third problem is that the database encryption solution can be applied only to structured data. However, there are large volumes of unstructured data, such as XML files, in the HIS systems. To enforce data encryption for these unstructured data, we need other technologies. Therefore, instead of using hard-disk encryption and database-level encryption, we chose to encrypt data at the message layer, which can effectively solve this issue.

Encrypting data in-transit can also be enforced at different layers. The widely adopted network layer data security protocol IPsec and the transport layer protocol SSL/TLS (secure socket layer/transport layer security) provide a transparent secure communication channel to end users. However, both of these techniques encrypt all the data transmitted through the channel, which consumes a lot of computing resources and requires considerable effort to set up the environment.

When designing the security architecture of the CDW, we adopted an application-level data encryption solution to protect data at rest and in-transit at the same time. All the data in hospital HIS systems are first classified into two classes, either private or public. Private data are those data that contain sensitive information such as patient name, IDN, and so on, which need to be encrypted at rest and in-transit. Public data are those data that do not contain sensitive, personal information and can be accessed freely by a third party, which can be stored on physical devices and transmitted in clear-text format. Most of the clinical data are classified as public data and thus can be stored and transmitted in clear-text, which saves a lot of computing resources. Only a small portion of the clinical data is classified as private data and must be encrypted at rest and in-transit. Figure 2 shows the security architecture of the PKUCDW. The private data at the data source are encrypted at one end and can be decrypted at the other end, based on the end user’s security role and policy. Specifically, if the end user is a CDW developer with lower level access right to the data, he or she has to deal with encrypted data if he or she has no right to access decrypted data. The same rule applies to end users of CDW data.

Figure 2.

Security architecture of PKUCDW.

Data encryption process

The following pseudo code (Algorithm 1) is the encryption algorithm, which is used by the hospital upload servers. The input is private data and the output is the cipher-text. The encryption key generation and protection happens automatically behind the scenes, which is transparent to end users.

Algorithm 1: Encrypt Private Data Into Cipher-Text

Input: clear-text of private information

Output: encrypted private information

out EncryptData(in)

{

seedtime <- GetSeed(time());

aes_key <- SHA-256(seed | seedtime);

cipher <- AES-Encrypt-CBC(in, aes_key);

server_public_key <- GetServerPublicKey();

encrypted_key <- RSA-Encrypt(aes_key, server_public_key);

digest <- SHA-256(cipher | encrypted_key);

client_private_key <- GetClientPrivateKey();

signature <- RSA-Sign(digest, client_private_key);

keyhash <- SHA-256(aes_key);

crc <- CRC32(cipher | encrypted_key | signature | keyhash);

out <- cipher | encrypted_key | signature | keyhash | crc;

}

All sensitive data are encrypted at the upload server of the hospital HIS system, using the Advanced Encryption Standard (AES; Federal Information Processing Standards (FIPS) 197) algorithm, with a 256-bit session key.³² The session key is generated at run time by a cryptographic hashing algorithm such as secure hash algorithm (SHA)-256 and is therefore unique for each session. We chose SHA-256 instead of the still widely used message digest 5 (MD5) and SHA-1 algorithms because of the known security attacks against these two algorithms.^26,27 The session key is further encrypted by the RSA algorithm with a 2048-bit CDW public key, which is a RSA public key on the CDW server side. This encrypted session key is appended to the cipher-text and a digest of these two fields is generated by the SHA-256 algorithm. This digest is signed by the RSA algorithm with the 2048-bit private key of the hospital HIS system. Each hospital has its own private RSA key, which is unique within the system.

A cryptographic hashing function is used to compute the digest of the session key, which is appended to the string for caching purposes. The last step is to use the cyclic redundancy check (CRC)-32 algorithm to calculate a checksum for all the data, including the cipher-text, the encrypted session key, the digital signature, and the session key hash value. A final optional step is to transform the whole message into a Base64 format, which is easier to transmit in ordinary text format. The following diagram in Figure 3 shows the detailed data flow and data format of the cipher-text generation.

Figure 3.

Client side private data encryption.

Data decryption process

After receiving the cipher-texts transmitted from the client, they will be stored on hard disks in the CDW server. Algorithm 2 is applied at the application server on the CDW side, which is the other end of the data flow. Here, the decryption key is retrieved based on end users’ role, and plain-text is recovered only for valid users.

Algorithm 2: Decrypt cipher-Text into private data

Input: cipher | encrypted_key | signature | key hash | crc

Output: clear-text

out Decrypt(in)

{

crc2 <- CRC32(cipher | encrypted_key | signature | keyhash);

if (crc2 != crc) report error;

client_public_key <- GetClientPublicKey();

digest <- RSA-Verify(signature, client_public_key);

digest2 <- SHA-256(cipher | encrypted_key);

if (digest2 != digest) report error;

server_private_key <- GetServerPrivateKey();

aes_key <-RSA-Decrypt(encrypted_key, server_private_key);

out <- AES-Decrypt-CBC(cipher, aes_key);

}

Upon receiving the cipher-text from the client (one affiliated hospital’s HIS upload server), if the message was coded in Base64, the server will transform the message back into binary form. Then a CRC-32 algorithm is applied to the received message, excluding the last CRC portion, to generate a new checksum CRC′. The newly calculated CRC′ is compared against the received CRC to check whether the message was modified during the transmission. If the checksum test passed, the RSA verification algorithm is applied to the client’s signature to recover the original digest of the cipher-text and encrypted session key. An SHA-256 algorithm is used to calculate a new digest of the received cipher-text and encrypted session key. The newly generated digest is compared to the original digest to check whether the received cipher-text and encrypted session key are the original ones sent from the client. Figure 4 shows the data verification phase of the decryption process.

Figure 4.

Server side data verification.

After the CRC test and digital signature verification, the RSA decryption algorithm is applied to the encrypted session key, with the private key of the CDW server, to recover the original AES-256 session key. This key is then used by the AES-256 decryption algorithm to decrypt the cipher-text and get the original private data. Figure 5 shows the data decryption phase. The session key hash can be used to greatly improve the performance of bulk data processing, where lots of private data are required to be decrypted in a batch process. When systems are running in this mode, the already decrypted session key and its hash value are stored in memory, and when a new cipher-text is received, the session key hash is searched against the in-memory cache to find the original session key. The cache is implemented as a hash table, whose search time complexity is O(1). Even if the message is captured by malicious third parties, the original session key cannot be recovered because of the irreversibility of the one-way cryptographic hashing function.

Figure 5.

Server side data decryption.

Cryptographic key management

Algorithm 3 is used to retrieve the server’s private key from the key server. Note that the private key of the CDW application server and hospital HIS upload server are never stored in plain-text on hard disks. The private key is encrypted by the AES-256 algorithm with a predefined server side key–encryption–key. The cipher-text is further separated into two parts, where the first part is stored on one key server, and the second part is stored on another key server with privileged access rights. These two parts are transmitted through secure communication channels from the two key servers and are concatenated into one piece on the central key server. Then the AES-256 decryption algorithm is used to decrypt the cipher-text and get the private key. The following diagram in Figure 6 shows a detailed data flow of the server’s private key retrieval.

Algorithm 3: Retrieve The Server’s Private Key

Input: None

Output: Server’s Private Key

out GetServerPrivateKey()

{

c1 <- Get1stHalf(server1);

c2 <- Get2ndHalf(server2);

secret <- c1 | c2;

out <- AES-DEC-CBC(secret, server_aes_key);

}

Figure 6.

Server side private key retrieval.

Apart from the data encryption technology used to protect the patients’ private information, a cryptographic hashing algorithm (SHA-256) is applied to each private data to generate a digest, for the purpose of indexing and cross-referencing. Since the code space of the SHA-256 algorithm is 256 bits, the possibility of code collision is extremely small, and it is practical for ordinary applications.

The novelty of our privacy protection model lies in the message-level data encryption technology designed into our CDW system, which protects data at rest and in-transit at the same time, and results in a minor reduction in performance to the whole system, due to the creative design of the cryptographic key caching system. Another novel design is our cryptographic key management system, which utilizes the separation-of-knowledge technique to reduce the attack surface and improve the overall security level of the system.

Results

On a test environment that has a 3.1-GHz central processing unit (CPU) and 16-GB memory machine, we ran the application 10 times to test the decryption performance. Table 1 shows the performance test results. The first column shows the decryption speed in megabits per second. The second column is the medical record reading speed in milliseconds, where there are 10,000 records and each record contains 20-kB data. The third column shows the record reading rate in milliseconds, where there are also 10,000 records, each of which is 20 kB and each contains some cipher-text fields. The average decryption speed is 141.74 Mbps. The average speed of noncipher-text record reading is 659.4 ms. The average speed of reading records containing cipher-text is 693.8 ms. There is a 5% performance penalty because of the encryption/decryption process added to the workflow.

Table 1.

Performance test results of the encryption system.

Test	Decryption speed (Mbps)	Noncipher-text record reading (ms)	Cipher-text record reading (ms)
1	141.436	671	686
2	141.592	655	702
3	143.82	645	687
4	143.982	656	688
5	141.592	675	695
6	141.43	655	687
7	138.979	655	702
8	136.752	671	702
9	143.88	656	702
10	143.982	655	687

Conclusion

The security of the confidential data relies upon the encryption of the session key by the CDW’s public key. To recover the session key without the CDW’s private key is equivalent to solving the integer factorization problem, which is a well-known hard mathematical problem. The fastest algorithm to solve the problem is the general number field sieve (GNFS) algorithm, whose time complexity is $O (e^{({(\frac{64}{9} n)}^{\frac{1}{3}} {(\log n)}^{\frac{2}{3}})})$ , where n is the length of the integer counted in bits.³³ We chose the value of n tobe 2048, because the largest number factored by the GNFS algorithm was 768 bits long, and this length will be safe for quite a long time.³⁴ Since a malicious third party does not have the CDW’s private key in hand, there is no feasible way for him or her to recover the session key in a reasonable amount of time, and he or she cannot get back the private data in plain-text either.

Meanwhile, patient privacy protection is a complex social issue, which involves policy-making, technology, and psychology. The focus of our study is on technological solutions, especially data encryption techniques. The composite privacy protection model ensures that the data each end user acquires is secure.

In China, few researchers in computer sciences, medical informatics, or statistics are doing research on privacy protection for medical data. Although our CDW project is small in scope compared to the larger initiatives at the national or international level, we do hope that the data privacy model designed for the PKUCDW can provide some useful ideas and insight for projects of larger scope and stimulate more research on advanced patient privacy protection techniques.

Footnotes

Funding

This research was supported by a grant funded by the Ministry of Education of China under Grant No.: 13YJC630066. The research was also supported by a grant from the Natural Science Foundation of China (NSFC) under Grant No.:81301296.

References

Iavindrasana

Cohen

Depeursinge

. Clinical data mining: a review. Yearb Med Inform 2009; (1):121–133.

Jiang

Chen

Liu

. A study of machine-learning-based approaches to extract clinical entities and their assertions from discharge summaries. J Am Med Inform Assoc 2011; 18(5): 601–606.

Wright

Pang

Feblowitz

. A method and knowledge base for automated inference of patient problems from structured data in an electronic medical record. J Am Med Inform Assoc 2011; 18(6): 859–867.

Bellazzi

Zupan

. Predictive data mining in clinical medicine: current issues and guidelines. Int J Med Inform 2008; 77(2): 81–97.

Goldberg

Spencer

Farmer

. Use of disease-modifying therapies in patients hospitalized with heart failure: a population-based perspective. Am J Med 2007; 120(1): 98.e1–98.e8.

Abhyankar

Demner-Fushman

McDonald

. Standardizing clinical laboratory data for secondary use. J Biomed Inform 2012; 45(4): 642–650.

Tolar

Balka

. Caring for individual patients and beyond: enhancing care through secondary use of data in a general practice setting. Int J Med Inform 2012; 81(7): 461–474.

Rea

Pathak

Savova

. Building a robust, scalable and standards-driven infrastructure for secondary use of EHR data: the SHARPn project. J Biomed Inform 2012; 45(4): 763–771.

Wisniewski

Kieszkowski

Zagorski

. Development of a clinical data warehouse for hospital infection control. J Am Med Inform Assoc 2003; 10(5): 454–462.

10.

Wong

STC

Hoo

Knowlton

. Design and applications of a multimodality image data warehouse framework. J Am Med Inform Assoc 2002; 9(3): 239–254.

11.

Correll

Kvecher

. DW4TR: a data warehouse for translational research. J Biomed Inform 2011; 44(6): 1004–1019.

12.

Lowe

Ferris

Hernandez

. STRIDE—an integrated standards-based translational research informatics platform. AMIA Annu Symp Proc 2009; 2009: 391–395.

13.

Goodwin

Prather

. Protecting patient privacy in clinical data mining. J Healthc Inf Manag 2002; 16(4): 62–67.

14.

Taboada

Cabrera

Iglesias

. An agent-based decision support system for hospitals emergency departments. Procedia Comput Sci 2011; 4: 1870–1879.

15.

Yang

. Civil law protection of patients’ privacy right. Huazhong University of Science and Technology, 2006 (in Chinese).

16.

Liang

. Study on civil law protection of patients’ privacy right in medical activities. Lanzhou University, 2009 (in Chinese).

17.

Sandhu

Coyne

Feinstein

. Role-based access control models. IEEE Comp 1996; 29(2): 38–47.

18.

Kalam

AAE

Baida

Balbiani

. Organization based access control. Policy 2003, proceedings of IEEE 4th international workshop on policies for distributed systems and networks, 4–6 June 2003, pp. 120–131. Lake Como, Italy, Washington DC, USA: IEEE Computer Society.

19.

Cassa

Miller

Mandl

. A novel, privacy-preserving cryptographic approach for sharing sequencing data. J Am Med Inform Assoc 2013; 20(1): 69–76.

20.

Murphy

Gainer

Mendis

. Strategies for maintaining patient privacy in i2b2. J Am Med Inform Assoc 2011; 18(Suppl. 1): i103–i108.

21.

Neubauer

Heurix

. A methodology for the pseudonymization of medical data. Int J Med Inform 2011; 80(3): 190–204.

22.

Fung

BCM

Wang

Chen

. Privacy-preserving data publishing: a survey of recent developments. ACM Comput Surv 2010; 42(4): 1–53.

23.

Erdal

Liu

Ding

. A database de-identification framework to enable direct queries on medical data for secondary use. Methods Inf Med 2012; 51(3): 229–241.

24.

Inmon

. Building the data warehouse. Wellesley, MA: QED Information Sciences, Inc., 1992.

25.

Blobel

Nordberg

Davis

. Modelling privilege management and access control. Int J Med Inform 2006; 75(8): 597–623.

26.

Wang

. How to break MD5 and other hash functions. In: Cramer

(ed.) Advances in cryptology-EUROCRYPT 2005, LNCS Volume 3494, 2005. 24th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Aarhus, Denmark, May 22-26, 2005. Proceedings. Springer-Verlag Berlin Heidelberg, 2005, pp. 19–35.

27.

Wang

Yin

. Finding collisions in the full SHA-1. In: Shoup

(ed.) Advances in cryptology-CRYPTO 2005, LNCS Volume 3621, 2005. 25th Annual International Cryptology Conference, Santa Barbara, California, USA, August 14–18, 2005. Proceedings. Springer Berlin Heidelberg, 2005, pp. 17–36.

28.

El Emam

Dankar

. Protecting privacy using k-anonymity. J Am Med Inform Assoc 2008; 15(5): 627–637.

29.

El Emam

Dankar

Issa

. A globally optimal k-anonymity method for the de-identification of health data. J Am Med Inform Assoc 2009; 16(5): 670–682.

30.

Malin

Benitez

Masys

. Never too old for anonymity: a statistical standard for demographic data sharing via the HIPAA Privacy Rule. J Am Med Inform Assoc 2011; 18(1): 3–10.

31.

Ferguson

Kelsey

Lucks

. Improved cryptanalysis of Rijndael. In: Goos

Hartmanis

van Leeuwen

. (eds) Fast software encryption’00, (Lecture notes in computer science), vol. 1978. 7th International Workshop, FSE 2000 New York, NY, USA, April 10–12, 2000 Proceedings. Springer Berlin Heidelberg, 2000, pp. 231–230.

32.

Daemen

Rijmen

. The design of Rijndael: AES—the advanced encryption standard. Berlin Heidelberg: Springer-Verlag, 2002.

33.

Pomerance

. A tale of two sieves. Not Am Math Soc 1996; 43(12): 1473–1485.

34.

Kleinjung

Aoki

Franke

. Factorization of a 768-bit RSA modulus. In: Rabin

Tal

(ed.) Advances in Cryptology – CRYPTO 2010, LNCS Volume 6223, 2010. 30th Annual Cryptology Conference, Santa Barbara, CA, USA, August 15–19, 2010. Proceedings. Springer, 2010, pp. 333–350.

Protecting privacy in a clinical data warehouse

Abstract

Keywords

Introduction

Background and significance

Background of PKUCDW

Structure of PKUCDW

Privacy concerns

Overview of privacy protection methods

Data encryption

Methods

Message-level encryption

Data encryption process

Algorithm 1: Encrypt Private Data Into Cipher-Text

Data decryption process

Algorithm 2: Decrypt cipher-Text into private data

Cryptographic key management

Algorithm 3: Retrieve The Server’s Private Key

Results

Conclusion

Footnotes

Funding

References