# Privacy-Aware Cloud Architecture for Collaborative Use of Patients' Health Information
## 3 Proposed Architecture
### Architectural Design and Components  
The proposed architecture comprises five architectural components that are required for storing healthcare information on the cloud and collaboratively using it in a privacy-preserving manner. These components are Requesting Agent, User Application, Cloud Service Registry, Secret Key Server, and Cloud Service Provider. Each component is responsible for accomplishing certain tasks as a contribution to achieving the main objectives of the proposed architecture. Figure 1 illustrates the architectural design and the relationship among its comprising components. **Requesting Agent**  
The Requesting Agent (RA) is a server that is responsible for receiving requests from users and forwarding them to both the Cloud Service Provider and the Secret Key Agent after authenticating users. It is the point of contact through which users send requests to store or access information stored on the cloud. Users are authenticated and their access rights are identified before requests are forwarded by the RA. In other words, it plays the role of the gatekeeper who does not allow unauthorized users to access the system. The RA has a limited communication channel with the users, a one-way communication channel with both the Cloud Service Provider (CSP) and the Secret Key Agent (SKA), and a two-way communication channel with the Cloud Service Registry (CSR) for users' authorization. The RA receives requests from users and only responds with information that is limited to confirmation of authentication. Figure 1: Proposed architectural design. The RA stores the required information for identifying patients who are registered in the system. Information stored on the RA is important for facilitating secure access to patients' information that is stored on the cloud. Every patient has a unique code referred to as a \"system ID\", which is generated by the RA and used for searching purposes. When a user requests to access patient information, the patient system ID is used to identify the patient's information that is stored on the cloud. The main role of the RA in the proposed design includes receiving requests from users, authenticating users, and forwarding user requests to both the CSP and the SKA. The information stored on the RA for every patient is organized into three sections; every section contains information that is important to facilitate access to patients' information in a secure and privacy-preserving manner. Table 4 illustrates the information stored in the RA. Section 1 includes information that is required to identify patients in the system. Users request to access patients' information by using basic identification information such as name, date of birth, and NHI number. Section 2 includes the patient's system ID, \(S_{\text{tSR}}\), and indexes. The system ID is required to identify patients' information that is stored on both; the cloud and the Secret Key Agent (SKA). The \(S_{\text{tSR}}\) is required to decrypt the trapdoors that are stored on the SKA, and the indexes are needed to identify the documents stored on the CSP. Section 3 includes information that is required by the Cloud Service Registry (CSR) for authorizing users to access patients' information. It includes a list of users who have permanent consent to access the patient's information, as well as the patient's contact details for requesting and obtaining patient consent. There are two types of consents that patients grant to users for accessing their information: permanent consents which are granted by patients to their local GPs or pre-determined medical institutions/practitioners, and temporary consents which patients grant to medical practitioners/institutions for casual incidents or clinical visits. Patients optionally grant permanent consent to users to access their information. Temporary consent is granted to a user who does not have permanent consent and requires access to a patient's information.