# Privacy-Aware Cloud Architecture for Collaborative Use of Patients' Health Information
## 3 Proposed Architecture
### Architectural Design and Components
**Cloud Service Registry**  
The proposed cloud architecture in this research employs the concept of the user identity management protocol for the cloud computing paradigm (U-IDM) proposed in [63]. U-IDM was initially proposed for cloud computing customers and cloud service providers. The main objectives of U-IDM were to achieve a set of global security objectives in cloud computing environments, which include user authentication, authorization, and accounting. It aimed to protect customers and cloud providers' infrastructures by preventing unauthorized users from gaining access to services or facilities delivered by cloud providers. The main component of the U-IDM paradigm is the Cloud Service Registry (CSR). The CSR plays a vital role in the proposed architecture. CSR provisions access information according to users' privileges in the form of service level agreements (SLAs). Services in the context of the proposed architecture include the provision of access to patients' information that is stored on the cloud. There are three information categories that require access rights from the CSR, which are All_V, Em_V, and OutP_V. As discussed earlier, each information category contains one or more documents. The CSR grants access to information categories by providing access to the documents that form these categories. Repeating the example of the Em_V category, it is a combination of doc-1 and doc-2. Therefore, granting access to the Em_V category requires the CSR to include the name of documents or their identifying tags with the user authentication confirmation. The CSR stores the names of categories and their comprising documents' tags. A list of registered users is stored on the CSR. Each user has a record of information related to the information that they can access. Users are listed under the names of their organizations. Searching for a user requires knowing the organization he/she belongs to. Table 5 shows an example of users' lists who are affiliated with an organization. Nevertheless, an important task of the CSR in the proposed architecture is to obtain patients' consent for accessing their information. The CSR does not authorize users to access patients' information without the patients' consent. As mentioned earlier, when a user requests to access patient information, the RA authenticates the user and forwards the request to the CSR for authorization. Part of the information included in the RA's forwarded request includes a list of permanently authorized users to access the patient's information. This list enables the CSR to find out whether the user is granted permanent consent to access the patient's information or not. If the user is not included in the list, the CSR promptly sends a request for temporary consent to the patient, and the patient can promptly grant consent or reject it. **SecretKey Agent**  
The Secret Key Agent (SKA) resides on a server that stores the required information for decrypting information stored in the cloud. As explained earlier, for every patient, there are three secret keys (S\({}_{\text{k}}\)) listed under a secret root key (S\({}_{\text{k}\text{R}}\)) which are used to decrypt three documents. All secret keys are stored together with trapdoors for all documents related to one patient (under one S\({}_{\text{k}\text{R}}\)). The main functionality of the SKA is to receive requests from the RA and send the required trapdoors directly to the user. SKA has a one-way communication channel with the RA, which is to receive requests, and a one-way communication channel with users to send secret keys, encrypted indexes, and trapdoors. **CloudService Provider**  
The cloud service provider (CSP) holds information related to patients' health. The main goal of the proposed architecture is to store all patients' information in one place, which is the cloud. The CSP serves by storing and releasing encrypted information related to patients upon users' requests. The CSP has a one-way communication channel with the RA, and a one-way communication channel with users.