iPatient Privacy Copyright Cloud Management

: The advent and rapid rise of network technology and cloud computing have led to new opportunities for ushering in a new era in telehealth. Thanks to the Internet of Things (IoT) and advances in 5G communication, telehealth is expanding and shows no signs of slowing down. It provides patients including elderly and disabled patients with convenient and easy access to healthcare services across space and time. However, the continuous real-time transmission of health information over networks also exposes private data to the risk of being intercepted by third parties. The privacy of the primary individual patient must be managed under the protection of the patient’s anonymous key while storing, transferring, sharing, and adding privacy rights. A question arises: How can we design a secure communication environment for remote access control to personal privacy matters? The patient’s electronic medical record is protected by the patient’s private key, and our scheme provides a real anonymous design for the patient with absolute autonomy over their privacy. Each update of the cloud medical records is patient-led and performed in a secure tunnel. As a result, this study reveals that the cloud-based iPatient privacy copyright management fully controlled by an individual patient is indeed safe and e ﬀ ective.


Introduction
Personal handwritten medical records are being phased out, and electronic personal medical records are now commonplace. An iPatient, which refers to a patient-led, privacy and medical record copyright issue, is rising to the challenge of privacy security. Most medical records kept by hospitals or private clinics are viewed and distributed without the patient's authorization. As such, many medical agencies have begun to pay attention to the importance of this issue and have begun to design a medical record database system that is centrally managed and shared. Most of the current patient privacy and medical record copyrights based on medical priority can be read by medical personnel with unlimited access only by a one-time authorization. Such privacy protection is obviously deficient. Anyone maliciously intending to obtain the privacy of others' medical records can easily illegally obtain relevant information. Hence, how to let patients fully control their own personal privacy and medical record copyright has become an important issue in today's privacy-sensitive information-dominated society. With the advent of the cloud computing era, most data are stored in cloud servers; therefore, we call these data management solutions "iPatient privacy copyright cloud management." Additionally, telehealth has received considerably increased attention. In this medical treatment approach, all the medical prescriptions, personal privacy, medical record copyright, etc., are transmitted on the public network and the data are stored in the cloud system. The main topics in this paper include the following: How to ensure telehealth visits occur in a secure transmission environment, how to securely transfer data and securely process data, and how to ensure that all actions related to patient privacy are performed with the patient's full authorization. The management of general medical

Related Work
In this study, we used a symmetric key to encrypt and decrypt all transmitted medical record copyrights. Therefore, we established a secure tunnel for all transmitted data and designed a symmetric key agreement mechanism. The key agreement was roughly divided into two parts, namely offline processing and online processing. In the case of offline processing, the user had to use a token that was unavailable to others to initialize the key agreement. Prior studies used personal identity IDs and passwords for preliminary verification, which is often referred to as the two-factor verification method [1,2].
When coupled with other auxiliary mechanisms or biological characteristics, they are often referred to as three-factor authentication [3,4]. However, new research mostly used fuzzy hashing conducting one-way exclusive pairing for biological characteristics, changing slightly each time [5,6]. Our research used fuzzy hashing plus identity anonymity; thus, it is a single-factor dynamic anonymous offline processing method [3,4,7]. Offline processing security vulnerability issues include smart card loss or brute force password cracking attacks, and many prior studies have also proposed possible vulnerabilities and solutions [8][9][10]. Alternatively, in the case of offline processing, a zeroknowledge information exchange key agreement was performed through the public network [11]. In the case of the key agreement mechanism, many scholars had proposed related agreements [8,[11][12][13][14][15]. In 2002, using fingerprints as passwords and using a remote login authentication through smart cards and biometrics were common [9]. Two years later, the improperly designed communication process posed a risk of masquerade attacks even though biometrics are hard to counterfeit [16].

Related Work
In this study, we used a symmetric key to encrypt and decrypt all transmitted medical record copyrights. Therefore, we established a secure tunnel for all transmitted data and designed a symmetric key agreement mechanism. The key agreement was roughly divided into two parts, namely offline processing and online processing. In the case of offline processing, the user had to use a token that was unavailable to others to initialize the key agreement. Prior studies used personal identity IDs and passwords for preliminary verification, which is often referred to as the two-factor verification method [1,2].
When coupled with other auxiliary mechanisms or biological characteristics, they are often referred to as three-factor authentication [3,4]. However, new research mostly used fuzzy hashing conducting one-way exclusive pairing for biological characteristics, changing slightly each time [5,6]. Our research used fuzzy hashing plus identity anonymity; thus, it is a single-factor dynamic anonymous offline processing method [3,4,7]. Offline processing security vulnerability issues include smart card loss or brute force password cracking attacks, and many prior studies have also proposed possible vulnerabilities and solutions [8][9][10]. Alternatively, in the case of offline processing, a zero-knowledge information exchange key agreement was performed through the public network [11]. In the case of the key agreement mechanism, many scholars had proposed related agreements [8,[11][12][13][14][15]. In 2002, using fingerprints as passwords and using a remote login authentication through smart cards and biometrics were common [9]. Two years later, the improperly designed communication process posed a risk of masquerade attacks even though biometrics are hard to counterfeit [16].
In 2012, a study addressed a medical information system for an integrated electronic patient record (EPR) with a one-way operation hash function as the main security mechanism. The study also reduced the time of encryption and decryption operations through multiplications [17]. However, it was still possible to carry out impersonation attacks although prior studies provided irreversible In 2012, a study addressed a medical information system for an integrated electronic patient record (EPR) with a one-way operation hash function as the main security mechanism. The study also reduced the time of encryption and decryption operations through multiplications [17]. However, it was still possible to carry out impersonation attacks although prior studies provided irreversible encryption and decryption operations for medical information systems. Impersonators can obtain fake user information by hacking the database [12]. In the case of user anonymity, in 2017, some scholars addressed anonymous mechanisms [3,4,7,14,15]. However, our study found that the anonymity in many studies was pseudonymous because the same alias was also easily traced to an association with the real identity. Our study will design one real untraceable anonymous agreement. As telehealth has received substantially increased attention, cloud data communication and storage security for telehealth have become quite important issues [3,[18][19][20][21][22][23]. There are many possible malicious attacks in traditional communication security issues such as man-in-the-middle, spoofing, and replay attacks [23][24][25][26]. Recently, Lin [27] proposed an authorized sharing mechanism for telehealth. Several weaknesses existed in Lin's scheme. Lin's scheme only discussed security protocols transferring data from the data centers to the hospital and lacked a design for storage or modification. Hospitals and data centers did not know the user's location and the real address, and consequently, they were unable to directly send communication messages. Additionally, the immutable pseudonyms were not truly anonymous and the medical record update did not establish a user-led secure channel, and data were probably at risk of being tampered with or counterfeited [27].
The main points of our study focus on the patients' complete anonymity but fully controlled through a zero-knowledge key agreement mechanism withstanding existing malicious communication attacks. All sensitive information is processed and transmitted after the secure tunnel is established. We designed an iPatient privacy copyright cloud management system, the details of which are shown in Figure 2.

The Proposed Mechanism
In this section, we describe our iPatient copyright privacy cloud management protocols. We apply the patient personal biometric signal and lightweight biometric hash function to encipher the security for the patient's private copyright. Our proposed protocol contains three phases, namely the initialization phase, registration phase, and electronic patient record sharing and updating phase. A scenario of iPatient copyright privacy cloud management is illustrated in Figure 2. Table 1 lists the notations used in the proposed protocols.

The Proposed Mechanism
In this section, we describe our iPatient copyright privacy cloud management protocols. We apply the patient personal biometric signal and lightweight biometric hash function to encipher the security for the patient's private copyright. Our proposed protocol contains three phases, namely the initialization phase, registration phase, and electronic patient record sharing and updating phase. A scenario of iPatient copyright privacy cloud management is illustrated in Figure 2. Table 1 lists the notations used in the proposed protocols.

Initialization Phase
In our mechanism, there are three roles. Each role must be registered and initialized with a certificate authority (CA) to obtain a passcode for verification. In the first phase, the electronic patient record server (EPRS) performs initial registration information with a CA, as seen in the following two stages. Stage 1. The EPRS registers on-site the first time with a CA. The CA generates the identifier IDe for the EPRS. The CA computes the token EC = h (IDe⊕TCA), stores IDe in its CA members database, and sends message tuple {IDe, EC} to the EPRS via a secure channel. Stage 2. The EPRS receives the message tuple {IDe, EC} from the CA, stores IDe and EC in the EPRS database, and then finishes the EPRS initialization phase.

Registration Phase
In the second phase, two roles, namely patients and remote hospital doctors or clinics, need to register at the CA. We describe these two roles separately in the following subsections.

Patients Registration Phase
Patients must register the first time with the CA in the prior EPRS registration phase and create patient accounts on the EPRS in the following three stages. Stage 1. P i keys in onsite his/her identity ID Pi and imprints the fingerprint B i ; then, the CA obtains Stage 2. The CA receives the message {ID Pi , H (B i )} from P i and then calculates the secret token

Remote Hospital Doctors or Clinics Registration Phase
The hospital doctors or clinics must also register the first time with the CA in the prior patient's registration phase by the following two stages. Stage 1. Doctor D j registers on-site the first time with a CA. The CA generates the identifier ID j for the D j and then computes DC j = h (h (ID j ) ⊕ T CA ), stores DC j to a medical card of doctor D j , and then sends back to the doctor D j via a secure channel. Stage 2. D j receives the personal medical card from the CA and keeps the medical card on hand.

Secure Electronic Patient Record Storing, Sharing, and Updating Communication Phase
This phase involves the stages of health medical privacy creation, sharing, and storage. In our iPatient access control model, doctors or clinics have read and updated permissions, while authorized professionals have only read permissions. Only patients themselves can access the encrypted personal privacy of the cloud server. Additionally, all data stored in the cloud are also protected by the patient's private key. All decrypted data must be transmitted in a secure tunnel established through a key agreement. Below, we show six strategies in the iPatient access control model and show the strategy diagram in Figure 3.

Secure Electronic Patient Record Storing, Sharing, and Updating Communication Phase
This phase involves the stages of health medical privacy creation, sharing, and storage. In our iPatient access control model, doctors or clinics have read and updated permissions, while authorized professionals have only read permissions. Only patients themselves can access the encrypted personal privacy of the cloud server. Additionally, all data stored in the cloud are also protected by the patient's private key. All decrypted data must be transmitted in a secure tunnel established through a key agreement. Below, we show six strategies in the iPatient access control model and show the strategy diagram in Figure 3. 1. The privacy of all patients is protected and stored in a cloud database via the patient's private key. 2. Anyone who wants to access patient privacy records must obtain the patient's authorization and obtain the records of the patient via patient downloading from the cloud database. 3. In the case of protecting the privacy of the cloud database, only patients can access via key agreement to establish a secure tunnel. After the tunnel is established, the transmitted data still need to be encrypted with the session key before it can be transmitted securely. 4. Doctors modify, update patient records, and send them to the patient via the session key. After the patient decrypts the updated patient records, s/he will use the personal private key to encrypt them, and then encrypt them with the session key to upload them to the cloud database server. Once the cloud data server receives and decodes them with the session key, it will update them to the patient records database. 5. Other authorized professionals excluding doctors can only read the patient records transmitted by the patient through the secure tunnel after they have been authenticated by the key agreement. They cannot modify or update patient records. 6. Our design for iPatient is personally led and we want to establish a privacy sharing mechanism that is completely patient-led.
Below, we introduce the steps we designed. First, we perform the three-party key agreement process in order to build a secure tunnel, and then decrypt, add, and modify the medical records in a secure tunnel.

1.
The privacy of all patients is protected and stored in a cloud database via the patient's private key.

2.
Anyone who wants to access patient privacy records must obtain the patient's authorization and obtain the records of the patient via patient downloading from the cloud database. 3.
In the case of protecting the privacy of the cloud database, only patients can access via key agreement to establish a secure tunnel. After the tunnel is established, the transmitted data still need to be encrypted with the session key before it can be transmitted securely.

4.
Doctors modify, update patient records, and send them to the patient via the session key. After the patient decrypts the updated patient records, s/he will use the personal private key to encrypt them, and then encrypt them with the session key to upload them to the cloud database server.
Once the cloud data server receives and decodes them with the session key, it will update them to the patient records database.

5.
Other authorized professionals excluding doctors can only read the patient records transmitted by the patient through the secure tunnel after they have been authenticated by the key agreement. They cannot modify or update patient records. 6.
Our design for iPatient is personally led and we want to establish a privacy sharing mechanism that is completely patient-led.
Below, we introduce the steps we designed. First, we perform the three-party key agreement process in order to build a secure tunnel, and then decrypt, add, and modify the medical records in a secure tunnel. Stage 1. P i imprints the biometric B i and then deciphers his/her identity by After the key agreement process is done, the secure tunnel among P i , the EPRS, and D j is established. The three roles can use the same one-time session key for secure communication. Next, the patient privacy history update process under the secure channel is detailed in Stage 8 to Stage 12.
Stage 8. The EPRS uses the secret session key SK to encrypt the privacy record of the ID pi patient, M 6 = {E SK (E K (R i ))}, and then sends M 6 to patient P i . Stage 9. P i receives the encrypted electronic patient record {E SK (E K (R i ))} and decrypts E SK (E K (R i )) using session key SK to obtain E K (R i ). Then, P i applies R Pi old to decipher the original R i = D RPi

Algorithms for Key Agreement, Data Encryption/Decryption, and Updating
In this subsection, we also give another presentation to describe our protocols. We use different roles to divide the algorithms into four independent but concurrent procedures. As described from Algorithms 1-4.

Security Analysis
In this section, we highlight some of the attributes and well-known attack types in the encryption and decryption process of long-distance data transmission and describe, in detail, the reasons why our designed protocol can resist attacks. The defenses of user anonymity, stolen or lost smart card attack, man-in-the-middle attack, replay attack, tamper attack, insider privilege attack, verify table stolen attack, off-line password guessing attack, and known key security are illustrated as follows.

User Anonymity
In our protocol, the patient Pi uses a one-time random number as a key to wrap the patient and the clinician's original ID in each communication. The alias ID of P i is NID Pi = ID Pi ⊕ R Pi new , and the alias ID of D j is NID Dj = ID Dj ⊕ R Pi new . Each time the ID is protected by a random value, it can be ensured that the ID is not derived and the malicious attacker cannot track a specific nickname. Additionally, the CA can check the ID list to verify that the user's nickname is legal. Therefore, the mechanism we proposed can correctly implement user anonymity.

Stolen or Lost Smart Card Attack
When a user's personal smart card is lost or stolen, a malicious attacker accessing the card can retrieve the information stored in the smart card. At this time, if the attacker cannot be detected, the attacker can use the smart card and the information in the smart card to simulate a remote legal user and pass the authentication.
In our proposed mechanism, only three parameters V i , ST i , and S i are stored in the smart card. In our design, the ID is the main secret. If the user's personal biosignal H (B i ) cannot be obtained after obtaining V i , the ID cannot be obtained. ST i and S i use the updated Rp i and CA private information to protect the ID. Therefore, it is impossible to analyze the biological characteristic B i to analyze the ID. Therefore, when a malicious attacker steals the patient's smart card, the attacker still cannot obtain the patient's real identity and CA's private key by verifying V i . Accordingly, there is little likelihood of decryption; consequently, we confirm that the proposed mechanism can prevent a data breach from theft or lost smart card attacks.

Man-In-The-Middle Attack
The person illegally retrieving messages during the communication period is called a man-in-the-middle attack. A middleman will modify or falsify content before it is delivered to the recipient. In our proposed protocol, the key communication messages are M1, M2, and M3. The message M1 that the patient communicates with the CA is protected by the CA's private secret T CA . If the attacker tampers with this message, after receiving the maliciously modified message, the CA's R Pi new will be incorrect. In addition, when the M2 message is modified by a malicious attack, the EPRS cannot resolve the real R Pi new through its privacy token EC. The message M3 transmitted from the CA to the doctor is protected by the doctor's secret value DC j . If the message is modified by a malicious attack, the doctor is also unable to obtain the real R Pi new . Regardless of whether the content of M1, M2, or M3 is maliciously modified, the final session key will be different, and a shared secret tunnel cannot be generated. Our proposed mechanism indeed resists man-in-the-middle attacks.

Replay Attack
Replay attacks can also be viewed as man-in-the-middle attacks. This type of attack does not need to modify or tamper with the communication information, but directly retransmits the original information. If the malicious attacker obtains the message sent from the user to the CA, the malicious attacker can directly replay the authentication without verifying the message. Generally, resolving this issue is offset by a timestamp. In our proposed mechanism, timestamps are replaced by dynamic parameters formed by one-time random numbers. If a malicious attacker replays the user's messages {NIDPi, NIDDj, M1}, sending them to the certificate authority again, s/he may obtain the message M4 from the electronic medical record server. However, the malicious attacker cannot know the one-time random number RP i new generated by the patient and will receive the wrong message to create the wrong session key. Hence, our proposed mechanism can defend against replay attacks.

Tamper Attack
Tamper attacks can also be viewed as man-in-the-middle attacks. In our design, if a malicious attacker tampers with the communication between CA and Pi, the CA will not be able to obtain the real R Pi new , because M1 has been tampered with by a malicious attacker. When the CA uses the wrong IDPi*, the CA is unable to obtain the real IDPi. R Pi new is not actually Pi, because the message has been tampered with by a malicious attacker and the CA will reject the key agreement request. Additionally, when a malicious attacker maliciously modifies the message, {NIDPi, NIDDj, M2} is sent from the CA to the EPRS. If message M2 has been maliciously modified so that EPRS checks the EPR database, the EPRS will not find the real Ri using IDPi. As a result, the EPRS will stop the key agreement request. In short, the mechanism we propose can prevent tampering attacks.

Insider Privilege Attack
Internal privileged attacks mean that malicious attackers deliberately register as legitimate members, so they may obtain relevant authentication information. They impersonate other legitimate users, perform illegal secret authentication, and obtain the keys of certificate authorities. In our proposed protocols, the internal information available to each user will be protected in V i , ST i , and S i . The secret tokens in S i are protected by the patient's biosignal H (B i ) and the one-time random number for updating ST i and S i . Hence, if internal malicious attackers obtain their own V i , ST i , and S i , they cannot know the biological characteristics of the pre-impersonator, and the secret information is updated randomly in each session, so impersonation verification cannot be performed. Additionally, during the patient registration phase, CA's secret token is hash-encrypted by a one-way hash function. Even if an internally privileged malicious attacker can easily obtain h (TCA), s/he cannot obtain the CA's real secret token TCA. Based on the one-way hash function and the security of biological characteristics, it shows that our proposed mechanism can resist internal privilege attacks.

Verify Table Stolen Attack
The verify table refers to the list used to confirm the relevant identity in the authentication server. A malicious person can invade the authentication server. A malicious insider can steal the verification form from the certificate authority through his own authority. Then, they obtain confidential information of other users from the table to impersonate other legitimate identities. In our proposed protocols, the certificate authority only stores a list of legitimate user ID Pi and does not store other linkable messages for the user. It only provides the electronic medical record sharing stage, allowing the certificate authority to verify the user's identity through the ID list. As such, our proposed mechanism will not allow attackers to perform other attacks even if the verification table is stolen.

Off-Line Password Guessing Attack
Generally, for the sake of saving communication costs, the system first verifies the client information and confirms that communication content is correct before communicating with the remote site. As such, malicious attackers often use brute force offline password guessing after obtaining the smart card. In our proposed protocols, patients do not use a password to register with a certification authority during the registration phase. In the medical record sharing stage, there is a patient's personal biometric protection communication message. The biometric signal is unique for everyone, so a malicious attacker cannot obtain the secret B i . Additionally, the CA checks the ID list and rejects the illegal ID Pi , so offline attacks will not obtain the real ID. We confirm that the proposed mechanism can resist offline password guessing attacks.

Known Key Secrecy
Known key secrecy is often mistaken for perfect forward secrecy because malicious users may obtain the session key or any secret information through analysis and predict the next session key or member privacy. In our proposed protocol, the session key used by patients, the EPRS, and doctors in the communication is generated by a one-time random number where the random number R Pi new is generated by the patient randomly. The number R EPRS is generated by the electronic medical record server, and the random number R D is generated by the remote doctor. These one-time random numbers are irregular. Each parameter is randomly regenerated. Consequently, even if the attacker obtains any such confidential information in this session, the attacker cannot calculate the next session key, so the proposed protocol can provide known key secrecy.

Performance Comparisons
In this section, we compare recent electronic medical solutions by their computational and communication costs. Comparisons of Wen et al. [7], Li et al. [12], Jung et al. [13], Wu et al. [17], Lin et al. [28], Lee et al. [29], and our method are illustrated in Table 2, a performance comparison  table, where T H denotes the execution time of the biometric-hash function operation, T h denotes the execution time of the one-way hash function operation, T xor denotes the execution time of the Exclusive-OR (short for XOR) operation, T M denotes the execution time of multiplication operations, and T qr denotes the execution time of computing a square root modulo n. T xor , T h , and T H belong to lightweight operations. According to the description of [15,23], the calculation of the XOR operation is negligible, and the T h ≈ T H time cost is similar.  [29] 6T h + 1T H + 15T xor As lightweight computing has gradually become the main issue of encryption and decryption considerations, more and more articles employ it. As the computing time of lightweight computing is relatively short, the variation in the discrepancy was found to be negligible. Even though the computing time in our paper is slightly shorter than others, this is not our focus. We emphasize that we can still avoid various well-known malicious attacks under nearly differential calculation time, implement a genuine dynamic anonymous mechanism, and employ exclusive one-single-factor input, namely reasonable biometric features, to avoid long strings of memories and inputs.
In Figure 4 and Table 2, we mainly focus on the lightweight operation, which mainly includes XOR and hash operations. Though our proposed mechanism is not the best in XOR operation performance, our hash function operation performance is the best. In the case of total cost, the operation computation time of bitwise XOR has less hash function, so our proposed mechanism uses the least cost and has better performance. As mentioned in Table 2, our login phase computation time is (6T h + 1T H + 22T xor ) ≈ (7T h + 22T xor ) and the total computation time required for our proposed mechanism is (9T h + 2T H + 33T xor ) ≈ (11T h + 33T xor ) relative time.
Appl. Sci. 2020, 10, x FOR PEER REVIEW 11 of 13 we can still avoid various well-known malicious attacks under nearly differential calculation time, implement a genuine dynamic anonymous mechanism, and employ exclusive one-single-factor input, namely reasonable biometric features, to avoid long strings of memories and inputs. In Figure 4 and Table 2, we mainly focus on the lightweight operation, which mainly includes XOR and hash operations. Though our proposed mechanism is not the best in XOR operation performance, our hash function operation performance is the best. In the case of total cost, the operation computation time of bitwise XOR has less hash function, so our proposed mechanism uses the least cost and has better performance. As mentioned in Table 2, our login phase computation time is (6Th + 1TH + 22Txor) ≈ (7Th + 22Txor) and the total computation time required for our proposed mechanism is (9Th + 2TH + 33Txor) ≈ (11Th + 33Txor) relative time. Finally, a security comparison of the proposed solution with related research for different known attacks, user anonymous, man-in-the-middle attack, replay attack, stolen or loss smart card attack, tamper attack, insider attack, verify table stolen attack, off-line password guessing attack, and known key security are shown in Table 3. Based on the security analysis, we observe that the mechanism proposed in this study is to determine that it can resist known attacks, and the results are desirable.

Conclusions
Thanks to the Internet of Things (IoT) and advances in 5G communication, telehealth is expanding and shows no signs of slowing down. It provides patients with convenience and easy access to healthcare services across space and time. However, the continuous real-time transmission of health information over networks also exposes the patients' privacy copyright data to the risk of a data breach. In this paper, we propose a personal electronic medical record copyright storage and transmission protection, authorization, and sharing management mechanism. The patient's electronic medical record is protected by the patient's private key and our protocol provides a real Finally, a security comparison of the proposed solution with related research for different known attacks, user anonymous, man-in-the-middle attack, replay attack, stolen or loss smart card attack, tamper attack, insider attack, verify table stolen attack, off-line password guessing attack, and known key security are shown in Table 3. Based on the security analysis, we observe that the mechanism proposed in this study is to determine that it can resist known attacks, and the results are desirable. healthcare services across space and time. However, the continuous real-time transmission of health information over networks also exposes the patients' privacy copyright data to the risk of a data breach. In this paper, we propose a personal electronic medical record copyright storage and transmission protection, authorization, and sharing management mechanism. The patient's electronic medical record is protected by the patient's private key and our protocol provides a real anonymous design for the patient possessing absolute autonomy over their privacy. Our mechanism ensures that only the certificate authority center knows the real name of the patient and the corresponding transmission location, and no one else knows it; therefore, it may achieve true anonymity. The secret token is updated every time, i.e., the pseudonym is different every time, so patients can individually control their own electronic medical records and use them safely in telehealth environments. In this study, each update of the cloud medical records is patient-led and performed in a secure tunnel. Our proposed mechanism has strict security controls over either in the telehealth process or in the storage and renewal process. As such, our proposed security analysis guarantees comprehensive security and anonymity protection during telehealth data and privacy transmission.
Author Contributions: Y.-J.K. was the principal researcher of this study. She contributed substantially to the conception, the design, the methodology, the analysis, and the interpretation of this study. She drafted the original manuscript, edited the critical revision of the manuscript, and proofread the revised paper. She performed the final approval of the manuscript to be submitted. J.-C.S. performed project administration. All authors have read and agreed to the published version of the manuscript.