# Privacy-Aware Cloud Architecture for Collaborative Use of Patients' Health Information
## 3 Proposed Architecture
### Architecture Implementation
#### 3.4.2 Testing the Architecture
For example, information about a sexual disease may not be needed for urgent medical treatments such as car accidents or minor incidents such as skin wounds and cuts. This was derived from the findings of the case study data analysis and supported by the literature. Nevertheless, the designed architecture requires obtaining patients' consent whenever accessing their information is required. The user identity management protocol (U-IDM) preserves the confidentiality of the information that is stored on the cloud and grants patients a means of control over who can access their information. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Test** & **Description** & **Result** & **Pass/Fail** \\ \hline \multirow{4}{*}{Unauthorized System Access} & Unauthorized user & \multirow{4}{*}{Access Denied} & \multirow{4}{*}{Pass} \\  & made request to & & \\  & download a trapdoor & & \\  & that is stored on the & & \\  & cloud & & \\ \hline Getting access to & A document & Document was & \\ documents stored on & downloaded without & & viewed in its & Pass \\ the cloud & having the secret key. & & encrypted form & \\ \hline \multirow{4}{*}{Unauthorized operations} & Attempt made to & \multirow{4}{*}{Access Denied} & \multirow{4}{*}{Pass} \\  & access the server or & & \\  & the database by & & \\ \cline{1-1}  & sending queries & & \\ \hline \multirow{4}{*}{Unknown users} & Unregistered user & \multirow{4}{*}{Login failed} & \multirow{4}{*}{Pass} \\  & attempted to log in to & & \\ \cline{1-1}  & the system & & \\ \hline \hline \end{tabular}
\end{table} 
Table 8: Summary of architecture test results. ### Security Analysis

The proposed system design prioritizes privacy and security when storing and sharing healthcare data on the cloud. The proposed system design includes several security approaches at different levels of the architecture. **User Application Level**

The user application in the real implementation of the system design allows only certain operations to be performed by the user. Users in the proposed system design are given accessibility to the system that is controlled by the enabled features and functions of the user application. For example, a nurse's log-in credentials enable certain functions on the user application to access the system, meaning that a nurse cannot perform operations to modify the way information is stored on the system. Moreover, the encryption and decryption processes are not controlled by the user; they are performed internally by the user application. The user application in the real implementation of the system may have the characteristic of hiding all information that is related to the encryption and decryption of information. **Access control**

The proposed system design employs the concept of user identity management (U-IDM), which is the Cloud Service Registry (CSR). The CSR is a component that is not located at the user's side, meaning that users cannot attempt to add or modify access rights to the system. Moreover, accessing the system can happen through requests that are sent from the user application to the Requesting Agent (RA), who authenticates and authorizes users before their requests are processed further in the system. The collaboration between the RA and the CSR is the only way to forward users' requests to access the system. Therefore, there are three security stations in the system that the user must go through to access the system, as presented in Figure 12.

The first station is on the user side, which involves entering the user's credentials to access the system. Users' credentials in the real implementation can be through information entered by the system (user ID and password) or other forms of credentials such as figure prints. The second station is on the cloud side, which involves authenticating the user. The user must be authenticated by the RA component before the authorization process takes place. The third station involves the authorization process. Once a user is authenticated by the RA, the authorization process happens through the CSR.