# Privacy-Aware Cloud Architecture for Collaborative Use of Patients' Health Information
## 3 Proposed Architecture
### System Instantiation  
The proposed architecture design aims to store healthcare data on the cloud and access it for legitimate purposes while protecting privacy. This section uses a scenario to show how the suggested architecture accomplishes this goal. The instantiation is provided in two parts: the first shows a patient enrolling in the system and storing their information on the cloud, while the second section shows how this information can be accessed for medical treatment. Storing patient information on the cloud--Scenario  
Let us assume that [PERSON] visits a system authorized doctor and requests to enroll in the system. The doctor enters [PERSON]'s information through the user application (UA). The doctor \begin{table}
\begin{tabular}{c c c} \hline \hline
**ID\#** & **Role** & **Access Privilege** \\ \hline
29930894 & Nurse & doc-1 1 doc-2 \\ \hline
29930804 & Doctor & doc-1 1 doc-2 1 doc-3 \\ \hline
29930832 & Receptionist & doc-1 \\ \hline
29930930 & Doctor & doc-1 1 doc-2 1 doc-3 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Example of users list in stored on the CSR. clicks on the **ENROL** button. The process of storing [PERSON]'s information on the cloud involves three stages: information preparation, authentication and authorization, and storage. **Stage 1**: Information Preparation (Searchable Symmetric Encryption): Prior to forwarding the information to the RA, [PERSON]'s information undergoes a number of pre-processing algorithmic operations performed by the UA in preparation for storage. The operations aim to encrypt [PERSON]'s information for storage on the cloud in a searchable manner. 1. A random secret root key (\(\mathsf{S_{\text{\text{\text{\text{\text{\text{\text{\text{\text{\text{\text{ \text  
Sends the encrypted trapdoors to the secret key agent (SKA) for storage. Information sent to the SKA is also labeled by [PERSON]'s system ID. 4. The information sent to both CSP and SKA is deleted from the RA. 5. The RA stores the following information: * [PERSON]'s identification information * [PERSON]'s system ID, * [PERSON]'s \(S_{\text{KR}}\), * Document indexes, * Names of users who have permanent consent to access [PERSON]'s information (if [PERSON] has provided any), * Information required for obtaining [PERSON]'s temporary consent. Below is the state-of-the-art of [PERSON]'s information while stored in the cloud: 1. [PERSON]'s information is stored in encrypted form and labeled by [PERSON]'s system-generated ID. The cloud provider is not able to learn the content of the information. 2. The trapdoors are encrypted using [PERSON]'s \(S_{\text{KR}}\) and stored on the SKA, labeled by [PERSON]'s system ID. The SKA is unable to learn the content of the trapdoors without [PERSON]'s \(S_{\text{KR}}\) which is stored on the RA. 3. The RA is the only entity in the system that can identify [PERSON] and his \(S_{\text{KR}}\). The RA stores all the information that is required to access [PERSON]'s information, as presented in Figure 2.  
Therefore, accessing [PERSON]'s information can only happen through collaborative interactions among the CSP, SKA, and RA. Compromising 1 or 2 of these architectural components will be fruitless for any disparate party in terms of accessing [PERSON]'s information. Having discussed the process of storing [PERSON]'s information on the cloud, the following subsection presents the process of accessing [PERSON]'s information for genuine reasons, such as providing healthcare to a patient. For this reason, the scenario presented in the following subsection involves the same patient ([PERSON]) requiring healthcare assistance from a different medical practitioner who also has access to the system. * Accessing stored patient information--Scenario [PERSON] visits the hospital for urgent medical treatment. He walks into the emergency department and meets one of the nurses in charge. The nurse requires accessing [PERSON]'s information and updating his records to include information about his visit, his medical condition, and other information related to his visit.