## 3 Methodology
### EPR Data  
The EPR data in this study use a unique hierarchal relationship data structure (for this reason, the data cannot be queried directly and extracted). Instead, they are hard-coded into the EPR to push these data to storage on a daily basis at 04:30 AM. Specifically, these data are combined into to a shared data file in pipe-delimited format (comma-delimited may cause issues with certain fields such as name, or routine). EPRs integrate many aspects of care into a single system, which are audited. Each encounter with patient data results in an audit footprint, which is stored in the data warehouse. This process is detailed in Figure 1.  
These data remain in.txt format until they are synthesised into a single.csv data file using the command prompt, as presented in Figure 2. This, however, is unusual. Many EPRs (and other medical systems) use a relationship data structure; therefore, these data can instead be extracted using an SQL query and the.csv file will be created. A sample of the EPR data used in this research is presented in Table 2. Each User ID, Patient ID and Device ID reading is tokenised to anonymise the data, as outlined in Algorithm 1.  
Figure 1: Electronic patient record (EPR) data.  
```
1. Function: Sort (values into alphabetical order)
2. Set: x\({}_{1}\) a tokenised value of 1
3. IF next value is same as previous value
4. Assign same tokenised value
5. ELSEIF
6. Assign a value +1 to the previous tokenisation value
7. ELSEIF
8. Check: All values have been tokenised
9. Return END
10. END
```  
**Algorithm 1** Tokenisation algorithm  
The algorithm isolates unique entries and assigns each value an incrementing number. In the dataset used in this research, there are 1515 unique User IDs, 72,878 unique Patient IDs, 2270 Device IDs and 13,722 Routine IDs. Therefore, there are 90,385 unique IDs in the dataset in total (user, patient,  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Time** & **Device** & **UserID** & **Routine \({}^{*}\)** & **PatientID** & **Duration** & **Admission** & **Discharged** \\  & & & & & & **Date** & **Date** \\ \hline
00:00 & 362 & 865 & PHA.ORDS & 58,991 & 54 & 28/02/2016 & 29/02/2016 \\
00:02 & 923 & 199 & REC REC:(DRP) UK.OE & 17,278 & 77 & 15/02/2016 & 15/02/2016 \\
00:02 & 103 & 677 & ASF & 4786 & 13 & 22/07/2008 & 22/07/2008 \\
00:02 & 103 & 677 & ASF & 4786 & 54 & 22/07/2008 & 22/07/2008 \\
0:04 & 923 & 199 & REC UK.OE & 62,121 & 147 & 08/02/2016 & 08/02/2016 \\ \hline \hline \multicolumn{8}{l}{\({}^{*}\) The routine descriptors are outlined in Table 3. This displays only a sample of the many different routine activities that are present in the dataset.} \\ \end{tabular}
\end{table}
Table 2: EPR audit sample data.  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Routine** & **Descriptor** \\ \hline PHA.ORDS & Pharmacy Orders \\ REC REC:(DRP) UK.OE & Recent Clinical Results:(Departmental Reports) UK.View Orders \\ ASF & Assessment Forms \\ REC UK.OE & Recent Clinical Results UK.View Orders \\ \hline \hline \end{tabular}
\end{table}
Table 3: Routine descriptors.  
Figure 2: EPR data push process.  
device and routine combined). The Routine ID is not tokenised as it denotes the tasks performed by the user on the EPR for the interaction.  
The data snapshot presented in Table 1 shows, for example, that User 865 accesses the _Pharmacy Orders_ function of the EPR on Patient 58,991 whilst using Device 362. As such, the premise of this research is to leverage the granularity of data within EPR for the development of internal-focused security application.