# Efficient and Secure EMR Storage and Sharing Scheme Based on Hyperledger Fabric and IPFS
## 6 Scheme Analysis
### Performance Analysis
#### 6.2.2 Time Overhead
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Phase** & **Time Overhead** & **Result (64 KB/256 KB/1 MB)** \\ \hline Data generation & \(t_{pk}^{ent}+t_{md_{new}}+t_{sign}\) & 87/295/1061 \\ Data uploading & \(t_{ulPFS}+t_{td}+t_{cai}\) & 127/136/148 \\ Data sharing & \(t_{pp}+t_{qtd}+t_{dIPFS}+2t_{vi}+t_{sk}^{de}+t_{as}^{en}+t_{gsk}^{en}+t_{psk}^{ de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk} ^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{ de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}+t_{gsk}^{de}\) \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Time overhead for major phases in this scheme (ms). In combining the results from Tables 5 and 6, it can be concluded that the impact of data size on time overhead is primarily evident in the encryption and decryption processes, with some impact also seen during the IPFS upload and download processes. When the data size exceeds 1 MB, the time overhead for zero-knowledge verification is extremely low, significantly less than 1%. These results demonstrate that the blockchain-based scheme proposed in this paper maintains high computational efficiency and low resource utilization even when handling large-scale data. Conditional querying is an important part in implementing EMR sharing, and the efficiency of conditional querying affects the efficiency of the whole sharing process. We propose a method for creating composite keys to improve the efficiency of system conditional querying. To demonstrate the feasibility of the method and evaluate the advantages of the optimization scheme, we conducted a separate time overhead test specifically for this functional module. We used the scenario of conditional querying described in Section 5.4 as an example for the subsequent tests. In this scenario, we only need two attributes, hospital name and diagnosis result, to construct composite keys. Then, we use the hash value of the EMR's number as the value corresponding to this composite key. For this purpose, we simulated 1479 records and divided the records into five groups based on the ratio \(P\) as shown in Equation (13):  
\[P=\frac{m}{n}. \tag{13}\]  
where \(n\) in Equation (13) represents the total number of EMRs for a certain diagnosis result \(DR_{i}\), and \(m\) represents the number of EMRs containing \(DR_{i}\) in hospital \(H\). The grouping results are shown in Table 7.  
We compared the query time overhead of our proposed method with the general method that does not use composite key. We repeated the query multiple times for each group of data in Table 7 using both methods and took the average of the query time for each group as the experimental result. As shown in Table 8, with decreasing \(P\), the query time overhead of the general method gradually increases. This is because as the \(P\) decreases, the total number of EMRs corresponding to the given diagnosis result in the conditional query increases, leading to an increase in the number of records that need to be filtered, thus resulting in a decreased query performance. In contrast, the query time spent by the proposed method based on the composite key is significantly less than that of the general method. This is because using the method of creating composite keys can accurately locate the data that satisfy all query conditions, requiring only the retrieval of the data that meet the conditions, thereby highlighting the superiority of the composite key-based method in terms of the query time performance. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Data** & \(t_{ctd}\) & \(t_{qtd}\) & \(t_{cad}\) & \(t_{qud}\) & \(t_{cai}\) & \(t_{qai}\) & \(t_{vp}\) \\ \hline
64 KB & 44.47 & 1.27 & 43.56 & 1.28 & 43.46 & 1.21 & 36.04 \\
256 KB & 47.37 & 1.23 & 46.81 & 1.23 & 42.71 & 1.28 & 37.21 \\
1 MB & 44.90 & 1.30 & 44.61 & 1.26 & 43.37 & 1.22 & 37.87 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Time overheads of the main functions of the chaincodes in this scheme (ms).