## 4 Investigation
### DBSCAN Outlier Detection Results  
The DBSCAN calculation process is implemented using the _dbscan_ ([[https://cran.r-project.org/web/packages/dbscan/index.html](https://cran.r-project.org/web/packages/dbscan/index.html)]([https://cran.r-project.org/web/packages/dbscan/index.html](https://cran.r-project.org/web/packages/dbscan/index.html))) R package. Table 5 presents a sample of five rows of the DBSCAN results for User ID, Patient ID, Device ID and Routine ID. DBSCAN does not apply a weighted score to the results, and therefore the results are classified as one of three point types. A core point is classified as a point that belongs to a cluster. A boundary point is within the epsilon of a core point but does not meet the criteria of min_points to be considered a core point. Finally, noise points are not assigned to any cluster. A visualisation of the DBSCAN output is implemented in Figure 7 using the _factoextra_ ([[https://cran.r-project.org/web/packages/factoextra/index.html](https://cran.r-project.org/web/packages/factoextra/index.html)]([https://cran.r-project.org/web/packages/factoextra/index.html](https://cran.r-project.org/web/packages/factoextra/index.html))) R library package, which show cluster plots of the predictions. The cluster against the noise identification is outlined in Table 5. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**User** & **User ID** & **Patient** & **Patient ID** & **Device ID** & **Device ID** & **Routine ID** & **IOD Type** \\ \cline{2-7}
**ID** & **Type** & **ID** & **Type** & **Row\_Id** & **Type** & **Routine ID** & **IOD Type** \\ \hline
**119** & noise & **803** & noise & **1** & noise & **MPI ZCUS.UK.SCH** & noise \\
**126** & noise & **804** & noise & **2** & noise & **ZCUS.UK.LETTER VH SPC OE** & noise \\
**144** & noise & **805** & noise & **3** & noise & ASF & core \\
**203** & noise & **806** & noise & **4** & noise & ASF MPI & core \\
**226** & noise & **807** & noise & **5** & noise & ASF NOTE ZCUS.UK.LETTER & core \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Density-Based Spatial Clustering of Applications with Noise (DBSCAN) output. Figure 6: \(K\)-nearest neighbour (KNN) eps calculation plot. In Table 5, the User ID is displayed, which is the identification code of the user accessing the data record, the patient record being accessed (Patient ID), the device being used (Device ID) and the action (Routine ID) being conducted. The data displayed in Table 5 outline which point type (as previously outlined) the classifier predicts the data point as belonging to for its corresponding class. For example, the first row shows that DBSCAN considers that User 119 does not belong to a cluster and classes the data point as noise. The data point for Patient ID 803 is also considered noise, as is Device ID 1. As previously demonstrated in Tables 2 and 3, the routine action is abbreviated. These tasks are often unique to the infrastructure, so defining the full list is not possible within the constraints of this paper. However, some actions, such as assessment forms (ASF), are common actions. In this case, the ASF routine has been classed as a core data point. The results achieved are visualised in Figure 7.  
The clusters are identifiable by the coloured areas, with the black dots classed as outliers or anomalous points. The visualised results are summarised in Table 6. The table displays the number of objects (data points) for each class, the number of assumed clusters and the number of noise points. The total number of anomalies is calculated by adding the noise total. As the results show, due to the lack of a weighted score, DBSCAN does not allow a patient privacy officer to prioritise their investigation into potentially inappropriate behaviour. Once the officer has investigated the noise points, there is the 'needle-in-a-haystack' problem of investigating border points relating to it. As such, the anomaly total provided is misleading and may be considerably higher if