Secure e-Health System on Passive RFID: Outpatient Clinic and Emergency Care

Abstract

In recent years, many researches have demonstrated several RFID-based solutions to enhance patient medication safety and avoid human errors. Although RFID-based procedure is more efficient than traditional process, patient's information may be attacked (or stolen) during the data transmission period. This will cause inappropriate medication use and medical errors. In this paper, we introduce a robust RFID-based e-Health system which strengthens the system security and protects the patient's privacy as well. In addition, our e-Health system can provide better efficiency of outpatient clinic procedure and emergency care procedure in hospital environment.

1. Introduction

Recently, RFID technology has promptly been adopted to enhance the communication efficiency in hospital environment. As a result, the development of a broad range of new electronic-Health (e-Hhealth) applications has emerged; these are, for example, patient safety and medication management [1–8], ubiquitous healthcare systems [9], inpatient-care systems [10, 11], autotracking clinical interventions [12], and electronic-health records [13]. All of these applications promise patient, nurse, doctor, and administrator to efficiently access relevant health information, enhance the quality of patient care, reduce healthcare errors, increase collaboration, and encourage the adoption of healthy behaviors.

Since new and efficient health information technologies realize the implementations of diverse e-Health services, the system security and patient (or hospital administrator) privacy have been focused by human right organizations, governments, and research community. The essential security elements for e-Health systems are data confidentiality, data integrity, service availability, accountability, and nonrepudiation of information. Meanwhile, personal privacy is the fundamental human right, and basic privacy protection principles are universal. Information privacy concerns exist wherever personally identifiable information is collected, processed, stored, and disclosed. In the following, we present basic information securities and privacy principles [14, 15]. (i)

Patient data must be processed fairly and used for specified and lawful purposes.

(ii)

Unauthorized or unlawful processing of patient data must be efficiently measured and dealt with.

(iii)

Accountability should be guaranteed.

(iv)

The consent for data processing should be freely given.

(v)

Patient data must not be exploited without adequate level of protection.

(vi)

Patient data must be adequate, relevant, and not excessive in relation to the purpose for which it is processed.

(vii)

Patient data processed for any purpose must not be kept for longer than is necessary for that purpose.

Based on the previous properties, we argue that data processing should be legal and meet regulatory and contractual obligations. In addition, the patient's health data (or personal examination report) is sensitive and, however, usually identifiable. Therefore, personal health data must be well protected to fulfill the above mentioned security and privacy principles; for example, the international standard ISO 27799 [16] can be a solution for security management of health information.

In this paper, we focus on RFID technology integrated with the process for medicine error reduction, patient (and inpatient) safety enhancement, and health care management. In particular, the issues of performance efficiency, system security, and patient privacy will be thoroughly investigated. We intend to deliver a patient privacy-aware e-Health system based on passive RFID to simultaneously enhance system efficiency and patient privacy.

2. Related Work

In 2007, Agrawal and Johnson [13] proposed a so-called Hippocratic Database which enables enterprises to comply with privacy and security laws without impeding the management of personal health information. To secure electronic health records, their proposal involves five techniques: (1) active enforcement of fine-grained data disclosure policies, (2) efficient auditing of past database access, (3) privacy-aware data mining, (4) deidentification of personal health data, and (5) robust information sharing. Later, to deal with the difficulty of securely manage the aggregation of health related data from various IT environments, Boyd et al. [10] developed a honest broker mechanism to maintain privacy for patient care and academic medical research. The honest broker can offload the burden of housing identifiable data elements of protected health information as well as manage date transfer between clinical and research systems.

In 2010, two tag coexistence schemes had been proposed by Chien et al. [2] to eliminate medication errors and enhance patient's safety. An online-based administration protocol and an offline version were proposed, respectively. However, the two proposed mechanisms did not consider important security and privacy issues [5]. Moreover, the feasibilities of these two schemes are doubted as only protocol designs are provided. That is, without any demosystem implementations, the practicability of these two protocols still has space for improvement. Later, Peris-Lopez et al. [4] implemented an Inpatient Safety RFID System (IS-RFID) which takes into account the information technology infrastructure of real hospital environment and completely covers the whole drug administration process. The system efficiency can be guaranteed as only lightweight cryptography modules such as random number generator and exclusive-or operations are exploited in IS-RFID. However, the insecurity of IS-RFID has been pointed by Yen et al. [7] in 2012.

Next, Yu et al. [8] developed a mechanism utilizing only simple logic gates, for example, AND, XOR, and ADD bitwise operations, to construct a secure e-Health system. Their scheme is efficient as it does not need any complicated cryptography modules. However, Wu et al. [6] have pointed the security vulnerability, that is, impersonation attacks, of their protocol. A lightweight binding proof protocol is then proposed to overcome the weakness identified in Yu et al.'s scheme. Next, Lin and Zhang [3] introduced an Elliptic Curve Cryptography- (ECC-) based solution to prove the coexistence of multiple RF tags and improve patient's drug security. Yet, as the heavy computation cost of ECC module cannot be afforded on resource-constrained RF tags, there exists a doubt on the feasibility of Lin and Zhang's scheme.

A wireless autotracking system for clinical intervention, such as drug administrations and blood tests at the patient bedside, is proposed by Ohashi et al. [12]. The system can authenticate patients and nurses, confirm medications, and provide relevant information based on the clinical situation and personal location. According to the evaluation, the proposed system can reduce significant medical errors and nurse workload with high efficiency. Najera et al. [11], in their study, first analyzed the case of a medical equipment tracking system for healthcare facilities enabling both real-time location and theft prevention. The authors then provided a solution for care and control of patients in a hospital environment based on passive RFID. Lo et al. [9] proposed a decision support systems, called the Ubiquitous Context-aware Healthcare Service System (UCHS), which uses microsensors integrated with RFID technology to sense user's life vital signal, such as electrocardiogram, heart rate, respiratory rate, blood pressure, blood sugar, and temperature and light. The UCHS is built upon an integrated service platform in which medical experts' knowledge and all position and negative influence of therapy are inferred via semantic network.

In 2013, Köstinger et al. [17] developed a ward round system with mobile smartphones in which Near Field Communication (NFC) technology is utilized to explore new ways of interaction. The system achieves patient identification via NFC tags. In their proposed scenario, when the patient arrives in the hospital, he/she will get a NFC wristband. This wristband carries information about their real identity, and in the following the hospital staff will utilize NFC-enabled mobile device to retrieve the information from the wristband. In 2013, Ajami and Carter [18] analyzed the advantages and disadvantages of adopting RFID in emergency room. In their study, the advantages are as follows: improving patient's safety, eliminating or reducing clinical errors, and decreasing medical errors to improve patient safety and save lives. However, the authors argued that the cost of healthcare system is still high for service providers. In addition, the privacy, legality, and security are the key problems needed to be solved in e-Health environment. Safdari et al. [19] have pointed that the organization needs to concentrate on the following privacy and security issues: (1) only authorized users can access sensitive information, (2) the integrity and accuracy of data should be guaranteed, and (3) the hospital needs to protect the patient information. In order to achieve these three goals, the authors provided a security solution, that is, anonymous transmission at tag side. That is, user can retrieve the unique tag ID without revealing the relationship between the object and the tag ID.

3. The Proposed e-Health System: Novel Outpatient Clinic Process and Emergency Care Procedure

In this section, we introduce an efficient and patient privacy-aware e-Health system based on passive RFID. We assume that the tags are able to perform PRNG function and XOR operation. Note that the output of PRNG function must be at least 96 bits for system security. In addition, 128 bits, 256 bits, and 512 bits are acceptable bit lengths also. Before we present the details of our proposed system, it is important to define the adversary model of our system environment. In 2001, Canetti and Krawczyk [20] demonstrate two adversary models: the unauthenticated-links model and the authenticated-links model. In the unauthenticated-links model, there exists a probabilistic polynomial-time attacker Eve who controls the communication links and the schedule of protocol events. Eve has the abilities, such as message modification, transmission injection, and the protocol event rescheduling. In general, Eve is able to send the following queries. (i)

Session-state reveal: Eve submits a party's identity and an incomplete session identifier to learn the state of the session. Note that Eve cannot learn any long-term secrets or master keys held by the party.

(ii)

Session-key query: Eve submits a party's identity and a complete session identifier to learn the session key in the intended session.

(iii)

Session expiration: Eve submits a party's identity and a complete session identifier for letting the simulator erase the session key and related session states.

(iv)

Party-corruption query: Eve decides to corrupt a party and learns all secrets or master keys of the party and then completely controls the party.

On the other hand, the authenticated-links model is applicable to the case that the attacker does not have the capability to inject or modify the transmitted messages. Under the previous assumptions, we then define our adversary model into two types: type I model and type II model. In type I model, a probabilistic polynomial-time attacker Eve controls the communication links and the schedule of protocol events. In addition, Eve is able to perform message modification, transmission injection, and the protocol event rescheduling with oracle queries such as session-state reveal, session-key query, session expiration, and party-corruption query. Mapping to the hospital environment, Eve can be the roles of nurse, doctor, examiner, and system administrator who are legitimate and verified in our system and possess the authorization of some system functionalities. In type II model, there exists a probabilistic polynomial-time attacker Eve, who is restricted to delivering messages generated from one of the communicating parties to the other one. Mapping to the hospital environment, this kind of attacker can be an outsider who does not have the capability to inject or modify the transmitted messages. Note that an insider without any entity verification or function authorization can be an example also. In addition, all the adversaries can simply obtain an RF reader and smart card reader to help his/her cryptanalysis.

In the following, we will demonstrate the details of our system. The proposed system consists of two newly designed processes on passive RFID that are (1) outpatient clinic process and (2) emergency care procedure, which accelerate and improve hospital administration and patient services.

3.1. New Outpatient Clinic Process on Passive RFID

This subsection presents a novel outpatient clinic process adopting passive RFID technology. The major procedures are illustrated in Figure 1 in which eight processes, that is, parts A to H, are presented. First, the part A's purpose is to bind patient's identity with a temporarily issued RFID tag in which patient's smart card will be utilized to encrypt (or protect) tag's information. Afterward, an anonymous authentication mechanism will be adopted in part B when doctors require confirming patient's legitimacy. Suppose that the patient is diagnosed with needing further examination tracking or condition tracking. Part C will be informed to maintain the record of the doctor's diagnosis. Next, in part D the inspector will reconfirm patient's legitimacy via patient's tag, and generates evidences in part E. Lab processes bind the drug jar and patient's identity, and store the binding information in backend server via part F. Finally, parts G and H are utilized for medication administration. In the following, we illustrate the details of these eight procedures.

Figure 1

The proposed outpatient clinic process based on passive RFID.

3.1.1. Part A: RFID Tag Issuing & Bind It with ID Card

In part A (Figure 2), the main target is to bind RF tag ${Tag}_{i}$ and patient's identity, where the patient's smart card is used for data encryption. In this part, the tag and the patient's identity will be bound in backend server. (A1)

Patient's tag $Ta g_{i} \to Reader: PI D_{i}$ .

Patient's smart card → $SCReader: k_{i}$ .

In action (A1), the RF reader inquiries the $Ta g_{i}$ and retrieves the unique identity $PI D_{i}$ of ${Tag}_{i}$ . Note that $PI D_{i}$ can be the patient's temporary and unique identity. At the same time, the smart card reader (SCReader) scans the user's smart card to retrieve the patient's secret key $k_{i}$ . Note that the user's smart card can be any type of smart card which possesses the user's secret key such as Citizen Digital Certificate [21] or Mifare Card [22].

(A2)

$Reader \to SCReader: PI D_{i}$ .

(A3)

Data encryption for $PI D_{i}$ .

The RF reader transfers $PI D_{i}$ to SCReader for encryption in action (A2). When SCReader receives the $PI D_{i}$ , it exploits the patient's secret key $k_{i}$ to encrypt $PI D_{i}$ in action (A3), that is, $x_{i} = {AES}_{k_{i}} (PI D_{i})$ , where AES represents Advanced Encryption Standard [23].

(A4)

$SCReader \to Reader: Pse u_{i}, x_{i}$ .

(A5)

$SCReader \to Backend Server: Pse u_{i}, x_{i}$ .

Figure 2

The part A of the new outpatient clinic process.

Afterward, SCReader generates a pseudonym $Pse u_{i}$ connected to value $x_{i}$ and sends ${Pse u_{i}, x_{i}}$ to RF reader which then writes the received value ${Pse u_{i}, x_{i}}$ to $Ta g_{i}$ to replace the original value $PI D_{i}$ in action (A4). Meanwhile, SCReader transmits ${Pse u_{i}, x_{i}}$ to the backend server. So far, both the tag $Ta g_{i}$ and the backend server maintain the values $Pse u_{i}$ and $x_{i}$ .

3.1.2. Part B: Examined and Diagnosed by a Doctor (Anonymous Authentication)

In part B (Figure 3), the patient gets examination and diagnosis from a doctor. During the procedures, an anonymous authentication is invoked to protect patient's privacy. (B1)

$Reader \to Ta g_{i} : n_{r}^{b}$ .

(B2)

$Ta g_{i} : m_{b} = x_{i} \oplus PRNG (n_{r}^{b} \oplus x_{i})$ .

First, the doctor utilizes the RF reader to send a newly generated random number $n_{r}^{b}$ to the patient's tag $Ta g_{i}$ in action (B1). With this random number $n_{r}^{b}$ , $Ta g_{i}$ computes $m_{b} = x_{i} \oplus PRNG (n_{r}^{b} \oplus x_{i})$ in action (B2).

(B3)

$Ta g_{i} \to Reader: Pse u_{i}, m_{b}, n_{r}^{b}$ .

(B4)

$Reader \to Backend Server: Pse u_{i}, m_{b}, n_{r}^{b}$ .

Next, in action (B3)

Ta g_{i}

responds the message

(Pse u_{i}, m_{b}, n_{r}^{b})

to the RF reader which soon forwards

(Pse u_{i}, m_{b}, n_{r}^{b})

to the backend server. Finally, the backend server exploits

Pse u_{i}

to efficiently retrieve the value

x_{i}

and computes

x_{i} \oplus PRNG (n_{r}^{b} \oplus x_{i})

. Then, the backend server verifies the correctness of

m_{b}

in action (B4), that is, whether the received value

m_{b}

equals to the calculated value

x_{i} \oplus PRNG (n_{r}^{b} \oplus x_{i})

or not. If this verification is passed, the legitimacy of patient can be confirmed without revealing his/her identity. Note that in this stage,

Pse u_{i}

is used to gain system efficiency. Since

Pse u_{i}

is a random nonce temporarily representing the patient's primary key during the search in the backend database,

Pse u_{i}

will not reveal any information regarding the patient's privacy. For this reason, this design will not influence the system security.

Figure 3

The part B of the new outpatient clinic process.

3.1.3. Part C: Further Tracking

Once the patient needs further physical examinations, part C (Figure 4) will be launched. The doctor firstly encrypts and stores the patient's diagnosis (or inspection report) with a unique number P in the backend server. The patient then utilizes the following processes to record the reference number of his/her diagnosis (or inspection report) in his/her own tag ${Tag}_{i}$ . (C1)

$Ta g_{i} \to Reader: Pse u_{i}, n_{t}^{c}$ .

(C2)

$Reader \to Backend Server: Pse u_{i}, n_{t}^{c}$ .

First of all, $Ta g_{i}$ generates a random number $n_{t}^{c}$ and sends ${Pse u_{i}, n_{t}^{c}}$ to the RF reader in part (C1). Secondly, RF reader forwards ${{Pseu}_{i}, n_{t}^{c}}$ to the backend server in Part (C2).

(C3)

$Backend Server \to Reader: m_{c}$ .

(C4)

$Reader \to Ta g_{i} : m_{c}$ .

Thirdly, the backend server retrieves the value

x_{i}

via

Pse u_{i}

and computes

m_{c} = PRNG (n_{t}^{c} \oplus x_{i}) \oplus P

. Then, the backend server transmits

m_{c} = PRNG (n_{t}^{c} \oplus x_{i}) \oplus P

to the RF reader in part (C3). Finally, the reader sends

m_{c}

Ta g_{i}

which then derives the number P with the received value

m_{c}

, that is,

P = m_{c} \oplus PRNG (n_{t}^{c} \oplus x_{i})

. After that,

Ta g_{i}

possesses the values P.

Figure 4

The part C of the new outpatient clinic process.

3.1.4. Part D: Examination Room & X-Ray Process (Anonymous Authentication)

Once the patient obtains the reference number, that is, P, of the diagnosis (or inspection report), the next stage is performed, that is, examination procedure or X-ray process. In part D (Figure 5), the inspector at each substage will reconfirm patient's legitimacy via patient's tag ${Tag}_{i}$ . (D1)

$Reader \to Ta g_{i} : n_{r}^{d}$ .

First, the RF reader generates a random number $n_{r}^{d}$ and sends it to ${Tag}_{i}$ in action (D1).

(D2)

$Ta g_{i} : m_{d} = (x_{i} ∥ P) \oplus PRNG (n_{r}^{d} \oplus x_{i})$ .

(D3)

$Ta g_{i} \to Reader: Pse u_{i}, m_{d}$ .

(D4)

$Reader \to Backend Server: Pse u_{i}, m_{d}, n_{r}^{d}$ .

Figure 5

The part D of the new outpatient clinic process.

Second, $Ta g_{i}$ calculates $m_{d} = (x_{i} ∥ P) \oplus PRNG (n_{r}^{d} \oplus x_{i})$ in action (D2) and transmits ${Pse u_{i}, m_{d}}$ to the RF reader in action (D3). Finally, in action (D4) the reader forwards ${Pse u_{i}, m_{d}, n_{r}^{d}}$ to the backend server which then retrieves $x_{i}$ and P via $Pse u_{i}$ and verifies the correctness of $m_{d}$ . That is, if the received value $m_{d}$ , equal to the calculated value $(x_{i} ∥ P) \oplus PRNG (n_{r}^{d} \oplus x_{i})$ , the legitimacy of this patient can be proved.

3.1.5. Part E: Examination Room & X-Ray Process (Evidence Generation)

Once the legitimacy of the patient is confirmed, the patient will get the service from examination or X-ray rooms. In this stage, we will generate a corresponding evidence (or proof) for further verification if any. That is, part E (Figure 6) will create an evidence for the patient's inspection procedure. (E1)

$Reader \to Ta g_{i} : n_{r}^{e}, t_{i}$ .

(E2)

$Ta g_{i} : m_{e} = (x_{i} ∥ P ∥ t_{i}) \oplus PRNG (n_{r}^{e} \oplus x_{i})$ .

(E3)

$Ta g_{i} \to Reader: Pse u_{i}, m_{e}$ .

First, the RF reader generates a random number $n_{r}^{e}$ and sends $(n_{r}^{e}, t_{i})$ to $Ta g_{i}$ in action (E1), where $t_{i}$ is the current timestamp. Second, $Ta g_{i}$ computes $m_{e} = (x_{i} ∥ P ∥ t_{i}) \oplus PRNG (n_{r}^{e} \oplus x_{i})$ in action (E2) and then sends ${Pse u_{i}, m_{e}}$ to the RF reader in action (E3).

(E4)

${Tag}_{E_{i}} \to Reader: n_{r}^{e}, t_{i}$ .

(E5)

$Reader \to Backend Server: Pse u_{i}, m_{e}, E_{i}, n_{r}^{e}$ .

(E6)

$Backend Server: digital signature of {Pse u_{i}, m_{e}, E_{i}, n_{r}^{e}}$ .

Figure 6

The part E of the new outpatient clinic process.

Next, the tag ${Tag}_{E_{i}}$ sends $E_{i}$ to the RF reader in action (E4), where $E_{i}$ is the inspector's identity maintained in the inspector's tag ${Tag}_{E_{i}}$ . Then, the reader transfers the message ${Pse u_{i}, m_{e}, E_{i}, n_{r}^{e}}$ to the backend server in action (E5). Finally, the backend server will generate a digital signature of ${Pse u_{i}, m_{e}, E_{i}, n_{r}^{e}}$ as an evidence for further verification. This proof will be useful once possible medical disputes happen. Note that the technique of digital signature can be RSA [24] or DSA [25].

3.1.6. Part F: Lab Process

The purpose of lab process (Figure 7) is to bind the target blood jar and patient's identity in the backend server. That is, we intend to correctly identify the source, that is, the target patient, of the target blood jar. (F1)

$Reader \to Ta g_{i} : n_{r}^{f}$ .

$Reader \to Ta g_{C_{j}} : n_{r}^{f}$ .

(F2)

$Ta g_{i} : m_{f} = x_{i} \oplus PRNG (n_{r}^{f} \oplus x_{i})$ .

(F3)

$Ta g_{i} \to Reader: Pse u_{i}, m_{f}$ .

Firstly, in action (F1) the reader generates a random number $n_{r}^{f}$ and sends it to $Ta g_{i}$ and $Ta g_{C_{j}}$ embedded on the target blood jar. Then, $Ta g_{i}$ computes $m_{f} = x_{i} \oplus PRNG (n_{r}^{f} \oplus x_{i})$ in the subpart (F2) and issues ${Pse u_{i}, m_{f}}$ to the RF reader in the subpart (F3).

(F4)

$Ta g_{C_{j}} : m_{f}^{'} = n_{r}^{f} \oplus C_{j}$ .

(F5)

$Ta g_{C_{j}} \to Reader: m_{f}^{'}$ .

Next, $Ta g_{C_{j}}$ sends a computed value $m_{f}^{'} = n_{r}^{f} \oplus C_{j}$ to the reader in actions (F4) and (F5), respectively, where $C_{j}$ is the identity of $Ta g_{C_{j}}$ .

(F6)

$Reader \to Backend Server: Pse u_{i}, m_{f}, n_{r}^{f}, C_{j}$ .

(F7)

$Backend Server: verify the legitimacy of the patient$ .

The RF reader then retrieves

C_{j}

from

m_{f}^{'}

and transfers the message

{Pse u_{i}, m_{f}, n_{r}^{f}, C_{j}}

to the backend server in the subpart (F6). Finally, in action 7 the backend server retrieves

x_{i}

via

Pse u_{i}

, and verifies the legitimacy of the patient. That is, the backend server examines whether the computed

x_{i} \oplus PRNG (n_{r}^{f} \oplus x_{i})

equals to the received

m_{f}

or not. If it holds, the server appends the information

C_{j}

to the patient's record.

Figure 7

The part F of the new outpatient clinic process.

3.1.7. Part G: Medication Administration

Part G (Figure 8) discusses the medication administration which is able to confirm the correctness of each target drug suggested by the doctor. In brief, this process will verify if current medicine jar is in the drug list suggested by the doctor; if yes, the medicine (or drug) in the jar will be taken into the patient's unit dose medication. Note that since the doctor's diagnosis has been completed in parts B and C, the suggested medicine list is maintained in the backend server. This list corresponds with the patient's information $x_{i}$ . (G1)

$Backend Server \to Reader: n_{r}^{g}$ .

Figure 8

The part G of the new outpatient clinic process.

First, the backend server generates a random number $n_{r}^{g}$ and transmits $n_{r}^{g}$ to the RF reader (e.g., the action (G1)).

For each $tag M_{m}$ , $m = 1, 2, \dots, n$ .

$Reader \to Tag M_{m} : n_{r}^{g}$ .

$Tag M_{m} : m_{g} = PRNG (n_{r}^{g} \oplus n_{t}^{g}) \oplus {ID}_{M_{m}}$ .

$Tag M_{m} \to Reader: n_{t}^{g}, m_{g}$ .

Second, the reader forwards $n_{r}^{g}$ to the tag $M_{m}$ embedded on each medicine jar (e.g., the subpart (G2)), where $m = 1, 2, \dots, n$ . Third, the tag $M_{m}$ computes $m_{g} = PRNG (n_{r}^{g} \oplus n_{t}^{g}) \oplus {ID}_{M_{m}}$ and sends $(n_{t}^{g}, m_{g})$ to the reader, where $n_{t}^{g}$ is a random number generated by the tag $M_{m}$ (e.g., the action (G3) and (G4)). ( $G_{n + 2}$ )

$Reader \to Backend Server: n_{r}^{g}, all (n_{t}^{g}, m_{g}) s$ .

Next, the reader forwards $n_{r}^{g}$ with all $(n_{t}^{g}, m_{g})$ s to the backend server which then verifies all the received values $m_{g}$ s to check if ${ID}_{M_{m}}$ is in the suggested list. If the verification holds, the server will inform the pharmacist to put the drug into unit-dose medication. Finally, the backend server calculates $m_{UD} = {ID}_{M_{m}} \oplus x_{i}$ , and stores $m_{UD}$ in both the backend server and tag $D_{i}$ embedded on the patient's medicine bag.

3.1.8. Part H: Pick Up the Medicine (Matching Verification)

In part H (Figure 9), we present the matching verification in Outpatient Department (OPD) dispensary when collecting medicine. (H1)

$Reader \to Ta g_{i} : n_{r}^{h}$ .

$Reader \to Tag D_{i} : n_{r}^{h}$ .

(H2)

$Ta g_{i} \to Reader: Pse u_{i}$ , $m_{t} = (x_{i}) \oplus PRNG (n_{r}^{h} \oplus x_{i})$ .

$Tag D_{i} \to Reader: m_{h} = (m_{UD}) \oplus PRNG (n_{r}^{h} \oplus m_{UD})$ .

First, in the subpart (H1) the reader generates a random number $n_{r}^{h}$ and sends $n_{r}^{h}$ to both $Ta g_{i}$ and the tag $D_{i}$ embedded on the patient's medicine bag. Second, $Ta g_{i}$ sends $Pse u_{i}$ and $m_{t} = (x_{i}) \oplus PRNG (n_{r}^{h} \oplus x_{i})$ to the RF reader, and $D_{i}$ transmits $m_{h} = (m_{UD}) \oplus PRNG (n_{r}^{h} \oplus m_{UD})$ to the reader in the subpart (H2).

(H3)

$Reader \to Backend Server: Pse u_{i}, m_{t}, m_{h}, n_{r}^{h}$ .

Figure 9

The part H of the new outpatient clinic process.

When the reader receives these two incoming values, the reader forwards ${Pse u_{i}, m_{t}, m_{h}, n_{r}^{h}}$ to the backend server for the matching verification, that is, whether the received value $m_{t}$ is equal to the computed value $(x_{i}) \oplus PRNG (n_{r}^{h} \oplus x_{i})$ or not, and whether the received value $m_{h}$ is equal to the computed value $(m_{UD}) \oplus PRNG (n_{r}^{h} \oplus m_{UD})$ or not. If it is verified successfully, this medicine bag correctly and actually belongs to the patient with $x_{i}$ . Note that $Pse u_{i}$ will be used to efficiently retrieve corresponding information of the patient.

3.2. Novel Emergency Care Process on Passive RFID

In Section 3.2, we present a novel emergency care process based on passive RFID (Figure 10). The major difference between outpatient clinic procedure and emergency care process is whether the patient is a roadside patient or not. In general, the roadside patients may not possess their ID card. This causes the inconvenience on identifying these patients. In such case, our process will issue a RFID tag as the roadside patient's temporary ID card. Please refer to part A of Figure 10. In the following, we present part A in a more detailed way. Note that the other parts in emergency care process are the same with that ones in outpatient clinic process. For clarity, we hence ignore the details of these procedures.

Figure 10

The proposed emergency care process based on passive RFID.

In part A of Figure 10, there are two conditions in this action. If the patient is roadside patient without ID card, the hospital will issue an RFID card with a temporary identity number to this patient. Next, in action (A1) of Figure 11 the RF reader inquiries the $Ta g_{i}$ and retrieves the unique identity $PI D_{i}$ in action (A1). After that, RF reader transmits $PI D_{i}$ to the backend server. Since in this stage the roadside patient does not have any history of medical information, the consideration of this patient's privacy can be ignored. Therefore, $PI D_{i}$ can be substituted for $x_{i}$ in emergency care process until the patient's has been identified. In other conditions, if this roadside patient has the ID card, the process will perform the same steps of part A of the new outpatient clinic process.

Figure 11

The part A of the novel emergency care process.

4. Security and Efficiency Analyses

In this section, we present the security and efficiency analyses of our proposed e-Health system, such as data confidentiality and patient anonymity, data integrity and nonrepudiation, resistance to the replay attack, and system efficiency.

4.1. Security Analysis

In our proposed e-Health system, we consider the adversary who does not have the capability to inject or modify the transmitted messages. Thus, such type of attacker can be an outsider (and an insider) without any entity verification or system authorization.

Claim 1.

The proposed e-Health system can provide patient anonymity and data confidentiality

In the outpatient clinic process, we use the key $k_{i}$ in the user's smart card to encrypt the patient's $PI D_{i}$ number. This prevents the attacker from cracking $PI D_{i}$ number as the attacker cannot know the key. In addition, since $x_{i} = {AES}_{k_{i}} (PI D_{i})$ is connected with the patient's secret key $k_{i}$ , this value $x_{i}$ can correctly be connected to this patient via $k_{i}$ even though this patient had left the hospital and this card had been assigned to another new patient. Moreover, at each session we utilize the secret value $x_{i}$ to protect all the transmitted messages. Without knowing the value $x_{i}$ , the adversary cannot obtain the sensitive information regarding the patient. Hence, our proposed system can ensure the data confidentiality.

Furthermore, as we implement an anonymous authentication technique in the proposed e-Health system, the doctor only needs to know if the patient is legal (or illegal) without revealing the real identity of this patient. In a more detailed way, in our proposed system all the messages are transmitted in cipher format instead of plain text. The secret $x_{i}$ is utilized to protect transmitted messages during each action. In that case, all sensitive information such as reference number P and the patient's identity are well protected. In addition, at each action we exploit random numbers, that is, $n_{r}^{b}$ , $n_{t}^{c}$ , $n_{r}^{d}$ , $n_{r}^{e}$ , $n_{r}^{f}$ , $n_{r}^{g}$ , and $n_{r}^{h}$ , to randomize transmitted messages. On the other hand, in the emergency care process we cannot learn the patient's identity (or privacy) because the roadside patient will not provide any information of his/her medical history. As a result, our proposed system can guarantee the property of patient anonymity.

Claim 2.

The proposed e-Health system can provide data integrity and nonrepudiation

In part E of our proposed system, we generate a random number $n_{r}^{e}$ and retrieve the identity $E_{i}$ of the inspector's tag ${Tag}_{E_{i}}$ . Next, to make an evidence for further verification, the signature of message ${Pse u_{i}, m_{e}, E_{i}, n_{r}^{e}}$ is produced [24, 25]. If adversary intends to modify ${Pse u_{i}, m_{e}, E_{i}, n_{r}^{e}}$ , the verification of this signature will fall. Therefore, the generated evidence can achieve the data integrity and non-repudiation at the same time.

Claim 3.

The proposed e-Health system can resist to the replay attack

In each session of our proposed system, we exploit random numbers, that is, $n_{r}^{b}$ , $n_{t}^{c}$ , $n_{r}^{d}$ , $n_{r}^{e}$ , $n_{r}^{f}$ , $n_{r}^{g}$ , and $n_{r}^{h}$ , in randomizing transmitted messages. In addition, in part E a timestamp $t_{i}$ is involved with the signature creation. These random numbers and timestamp cannot only randomize the transmitted messages but also ensure the resistance the replay attack.

4.2. Discussion on Efficiency and Security

In this paper, we adopt the concept of passive RFID to construct our proposed system, where RF tag only needs to support lightweight cryptography modules, that is, random number generator PRNG and exclusive-or operations XOR. This design is one of the future trends of RFID technology development in hospital environments [4, 8, 18]. The cost of RFID tag reflects the capability of tag; that is, heavy cryptography modules always need higher computation cost while lightweight ones require fewer. In the hospital environment, the computation efficiency is highly critical as the processing time for each medical procedure is one of the major considerations during the design of an e-Health system. Thus, without any heavy cryptography modules, we believe that our proposed system achieves a good system efficiency.

In addition, from Figures 1 and 10, we can easily conduct the traditional outpatient clinic process and emergency care procedure without any RFID related procedures. Compared to the original non-RFID hospital administration system, we believe that the efficiency can be gained during parts D and F. In general, the process of examination room and LAB is time consuming. With our design, the process time of these two processes can be reduced, and the patient security is guaranteed as well. Note that although the other parts mainly focus on security enhancement and privacy protection, we still think that our proposed e-Health procedures are efficient. In brief, our system introduces a new way to implement a solution for not only achieving hospital administration efficiency but also delivering the security enhancement and privacy protection at the same time.

5. Prototype Implementation

In this section, we demonstrate the prototype implementation of our proposed e-Health system.

5.1. System Environment

In the prototype implementation, the environment is shown as that in the Table 1. First of all, we adopt android with version 4.1.1 as the base operating system to construct our e-Health system. In addition, we use the Eclipse Java EE IDE to develop our system. NEXUS 7 tablets are used to support the computations at the tag side and at the reader side. For instance, once the authentication process begins, the NEXUS 7 tablet at the doctor (or nurse) side will act as a RF reader to send a random number to the Mifare card at the patient side. Note that we also utilize Mifare cards as the target RF tags embedded on the drug bag. In our system, NEXUS 7 tablets are used to transfer and receive information via Near Field Communication (NFC) technology. Moreover, NFC has three communication modes that are peer-to-peer mode, read/write mode, and card emulation mode. In our prototype implementation, we use read and write mode as the basic communication mode.

Table 1

Environment description.

Smartphone	NEXUS 7
Operating system	Android 4.1.1
RFID tag	Mifare Card
Development environment	Eclipse Java EE IDE

5.2. System Architecture and Implementation

As mentioned in Section 3, the outpatient clinic process and emergency care process are almost the same. We thus implement only the outpatient clinic process as the system prototype. Figure 12 is the architecture of implementation of our proposed outpatient clinic process. In the following, we will illustrate the implementation of each process (i.e., part A to part H). Before that, we present the system snapshot at the doctor side (i.e., the reader side or the server side) in Figure 13, while Figure 14 shows the patient information on the NEXUS 7 tablet at the doctor side. Similarly, Figures 15 and 16 demonstrate the system snapshot at the patient side (i.e., the tag side) and the patient information on the NEXUS 7 tablet at the patient side, respectively. Note that in our implementation, the patient also possesses a NEXUS 7 tablet to clearly demonstrate all processes including the message transmission, entity authentication, match verification, and others. Two NEXUS 7 tablets at the doctor side and the patient side will not exploit the peer-to-peer mode to ensure that the prototype implementation actually reflects the practicality of our proposed RFID-based e-Health system.

Figure 12

The architecture of the outpatient clinic process.

Figure 13

The system snapshot of the NEXUS 7 tablet at the doctor side.

Figure 14

The patient information on the NEXUS 7 tablet at the doctor side.

Figure 15

The system snapshot of the NEXUS 7 tablet at the patient side.

Figure 16

The patient information on the NEXUS 7 tablet at the patient side.

(i) RFID Tag Issuing & Bind with ID Card. In our simulation of part A, we use Mifare card to substitute personal smart card with a unique secret key. First, the NEXUS 7 tablet at the server side scans the card and explores the secret key $k_{i}$ to encrypt the unique identity $PI D_{i}$ , that is $x_{i} = {AES}_{k_{i}} (PI D_{i})$ . Second, the NEXUS 7 tablet at the server side stores the information $x_{i}$ and a temporary pseudonym $Pse u_{i}$ in backend server for future verification process. Figure 17 presents the message for the success of transmitting the secret information $x_{i}$ and $Pse u_{i}$ to the backend server.

Figure 17

Success image of part A.

(ii) Authenticating the Patient Identity in Part B, Part D, Part E, Part F, and Part H. In parts B, D–F, and H, we implement an anonymous authentication. First, the NEXUS 7 tablet at the server side sends a random number to the NEXUS 7 tablet at the patient side (please refer to Figures 13 and 15). This random number can randomize all transmitted messages. Then, the application (shown in Figure 15) at the patient side will perform the corresponding procedures as that mentioned in Section 3.

(iii) Information Storing at the Patient Side in Part C. Part C presents the patient needs for further physical examinations. At first, patient's encrypted diagnosis with its number P is stored in the backend server. Next, the NEXUS 7 tablet at the patient side sends a random number $n_{t}^{c}$ to the server which then computes $m_{c} = PRNG (n_{t}^{c} \oplus x_{i}) \oplus P$ . The server then sends $m_{c}$ to the NEXUS 7 tablet at the patient side. Finally, the patient possesses the values P and $x_{i}$ .

(iv) Lab Process in Part F. In part F, an anonymous authentication for the patient is firstly performed. Next, the server will request the information $C_{j}$ . Then, server generates a random number $n_{r}^{f}$ and sends it to tag $C_{j}$ which computes value $m_{f}^{'} = n_{r}^{f} \oplus C_{j}$ . Tag $C_{j}$ send $m_{f}^{'}$ back to the server. Finally, the server retrieves the number $C_{j}$ . Figure 18 shows the write mode in part F.

Figure 18

The write mode in part F.

(v) Medication Administration in Part G. In part G, we use RFID card binding with the medicine jar, and our application at the server side can confirm the correctness of drugs suggested by the doctor. The system verifies whether the medicine jar is in the suggested list. If the verification holds, the verified medicines will be put into patient's medicine bag. First, the application at the doctor side generates a random number $n_{t}^{g}$ to the tag. Tag computes $m_{g} = PRNG (n_{r}^{g} \oplus n_{t}^{g}) \oplus M_{i}$ and then sends $(n_{t}^{g}, m_{g})$ to the server. Next, the server verifies the received value $m_{g}$ to check if $M_{i}$ is in the doctor suggested list. After that, the server computes $m_{UD} = M_{i} \oplus x_{i}$ and stores the $m_{UD}$ in the patient's medicine tag $D_{i}$ for part H. Figure 19 presents the matching success result of part G.

Figure 19

Matching success image of part G.

(vi) Pick Up the Medicine in Part H. In part H, the server will first check the validity of the patient. Next, the server needs to make sure the correctness of the patient's medicine tag $D_{i}$ . As the previous authentication process, the server first generates a random number and sends it to tag $D_{i}$ . Then, tag $D_{i}$ computes $m_{h} = (m_{UD}) \oplus PRNG (n_{r}^{h} \oplus m_{UD})$ and sends $m_{h}$ to the server side for matching verification.

6. Conclusion

In this paper, we have introduced an e-Health system consisting of two processes, that is, outpatient clinic process and emergency care process. Eight RFID-based procedures are proposed for enhancing the system efficiency of these two processes. Several techniques such as data encryption, digital signature, anonymous authentication, and tag coexistence proof are adopted as core designs in the proposed system to simultaneously achieve system security and protect patient privacy. Based on our prototype implementation, we believe that our e-Health system can easily be implemented in hospital environment. In brief, our e-Health system demonstrates the system robustness, user/patient privacy protection, and the process efficiency on the medical administration. In the future, more complex hospital scenarios will be discussed. For example, once patient transferring happens, doctor may need to access information from different hospitals. As a result, the cross-hospital authentication (and authorization) of the doctor will be considered as a major design issue.

Footnotes

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

Acknowledgments

The authors gratefully acknowledge the support from the Taiwan Information Security Center (TWISC) and the National Science Council, Taiwan, under the Grants nos. NSC 102-2218-E-259-004, NSC 102-2218-E-011-012, and NSC 102-2218-E-011-013. The authors also gratefully acknowledge anonymous referees for their valuable comments which have improved the presentation of this paper.

References

Chen

C.-L.

C.-Y.

Using RFID yoking proof protocol to enhance inpatient medication safety

Journal of Medical System 2012 36 5 2849 2864

Chien

H.-Y.

Yang

C.-C.

T.-C.

Lee

C.-F.

Two RFID-based solutions to enhance inpatient medication safety

Journal of Medical Systems 2011 35 3 369 375

2-s2.0-79959770845

10.1007/s10916-009-9373-7

Lin

Zhang

ECC-based grouping-proof RFID for inpatient medication safety

Journal of Medical Systems 2011 36 6 3527 3531

2-s2.0-79960522521

10.1007/s10916-011-9757-3

Peris-Lopez

Orfila

Mitrokotsa

van der Lubbe

J. C. A.

A comprehensive RFID solution to enhance inpatient medication safety

International Journal of Medical Informatics 2011 80 1 13 24

2-s2.0-78650292473

10.1016/j.ijmedinf.2010.10.008

Wickboldt

A.-K.

Piramuthu

Patient safety through RFID: vulnerabilities in recently proposed grouping protocols

Journal of Medical Systems 2012 36 2 431 435

2-s2.0-77950557386

10.1007/s10916-010-9487-y

S. H.

Chen

K. F.

Zhu

Y. F.

A secure lightweight RFID binding proof protocol for medication errors and patient safety

Journal of Medical Systems 2012 36 5 2743 2749

2-s2.0-80052033548

10.1007/s10916-011-9750-x

Yen

Y.-C.

N. W.

T.-C.

Two RFID-based solutions for secure inpatient medication administration

Journal of Medical System 2012 36 5 2769 2778

10.1007/s10916-011-9753-7

Y.-C.

Hou

T.-W.

Chiang

T.-C.

Low cost RFID real lightweight binding proof protocol for medication errors and patient safety

Journal of Medical Systems 2012 36 2 823 828

2-s2.0-77955285148

10.1007/s10916-010-9546-4

C.-C.

Chen

C.-H.

Cheng

D.-Y.

Kung

H.-Y.

Ubiquitous healthcare service system with context-awareness capability: design and implementation

Expert Systems with Applications 2011 38 4 4416 4436

2-s2.0-78650727792

10.1016/j.eswa.2010.09.111

10.

Boyd

A. D.

Hosner

Hunscher

D. A.

Athey

B. D.

Clauw

D. J.

Green

L. A.

An “Honest Broker” mechanism to maintain privacy for patient care and academic medical research

International Journal of Medical Informatics 2007 76 5-6 407 411

2-s2.0-34047179114

10.1016/j.ijmedinf.2006.09.004

11.

Najera

Lopez

Roman

Real-time location and inpatient care systems based on passive RFID

Journal of Network and Computer Applications 2011 34 3 980 989

2-s2.0-79952440568

10.1016/j.jnca.2010.04.011

12.

Ohashi

Ota

Ohno-Machado

Tanaka

Smart medical environment at the point of care: auto-tracking clinical interventions at the bed side using RFID technology

Computers in Biology and Medicine 2010 40 6 545 554

2-s2.0-77953357846

10.1016/j.compbiomed.2010.03.007

13.

Agrawal

Johnson

Securing electronic health records without impeding the flow of information

International Journal of Medical Informatics 2007 76 5-6 471 479

2-s2.0-33947621113

10.1016/j.ijmedinf.2006.09.015

14.

Ruotsalainen

Privacy and security in teleradiology

European Journal of Radiology 2010 73 1 31 35

2-s2.0-73449137507

10.1016/j.ejrad.2009.10.018

15.

Kreps

G. L.

Neuhauser

New directions in eHealth communication: opportunities and challenges

Patient Education and Counseling 2010 78 3 329 336

2-s2.0-77950355514

10.1016/j.pec.2010.01.013

16.

ISO 27799, Health Informatics—Security Management in Health Using ISO/IEC 17799

17.

Köstinger

Gobber

Grechenig

Tappeiner

Schramm

Developing a NFC based patient identification and ward round system for mobile devices using the android platform

Proceedings of the IEEE Point-of-Care Healthcare Technologies (PHT ’13)

2013

176 179

10.1109/PHT.2013.6461313

18.

Ajami

Carter

M. W.

The advantages and disadvantages of Radio Frequency Identification (RFID) in Health-care Centers, approach in Emergency Room (ER)

Pakistan Journal of Medical Sciences 2013 29 1, supplement 443 448

19.

Safdari

Maserat

RFID technology in health environment opportunities and challenges for modern cancer care

Asian Pacific Journal of Cancer Prevention 2012 13 12 6533 6537

20.

Canetti

Krawczyk

Analysis of key-exchange protocols and their use for building secure channels

Advances in Cryptology—EUROCRYPT 2001 2001 2045 453 474 Lecture Notes in Computer Science

21.

Citizen Digital Certificate, http://moica.nat.gov.tw/html/en

22.

Mifare Card, http://www.mifare.net/en/home

23.

Announcing the Advanced Encryption Standard (AES) Federal Information Processing Standards Publication 197. United States National Institute of Standards and Technology (NIST), November 2001

24.

Rivest

R. L.

Shamir

Adleman

A method for obtaining digital signatures and public-key cryptosystems

Communications of the ACM 1978 21 2 120 126

2-s2.0-0017930809

10.1145/359340.359342

25.

Proposed federal information processing standard for digital signature standard (DSS)

Federal Register 1991 56 169 42980 42982