
dataPreprocessing(\(\Phi \) ): This algorithm is run by the DO. It begins by classifying and labelling EHRs by identifiable and non personally identifiable information. As an example, identifiable columns may include the patient's NINO and mobile number. Non-identifiable columns include medical condition, gender, symptom and blood pressure. Next, it splits any tokenisable and Non-PII EHRs into blocks with the relationships between blocks linked by a 128-bit pointer (UUID). Instead of using pure numeric IDs that are easily guessed, we generate the Universally Unique Identifier using a cryptographically strong pseudo-random number generator provided in the Apache Commons IO library [1]}. An example of a 128-bit UUID is 9458fdcc-6bed-46ec-b883-0076409e76f. This prevents simple brute-force guessing of the secret relationships because it is impossible to iterate through all random UUIDs. In the end, the preprocessed EHR blocks are output in a random access data structure, referred as electronic tenon structure: \(\mathbb {M} :=\lbrace (\mathfrak {N}_1 ,\Phi _{1} ,\mathfrak {N}_x) ,(\mathfrak {N}_2 ,\Phi _{2} ,\mathfrak {N}_y) ,\cdots ,(\mathfrak {N}_n ,\Phi _{n} ,\mathfrak {N}_z)\rbrace \) . Note that each element in \(\mathbb {M}\)  is a three-tuple containing (1) the UUID of the current EHR block, (2) the EHR block itself and (3) a pointer to the next EHR block.

encryptPointer(\(\mathfrak {pp}\) ,\(\mathbb {M}\) ,\(\mathbb {A}\) ,\(\lbrace k_{l}\rbrace _{l\in \lbrace 1,c\rbrace }\) ): This algorithm is executed by the DO. It extracts the pointers \(\lbrace \mathfrak {N}_i,\mathfrak {N}_j,\mathfrak {N}_k,\cdots \rbrace \)  in \(\mathbb {M}\) , and encrypts them according to a patient-defined access structure \(\mathbb {A}\)  with different security levels \(\lbrace k_{l}\rbrace _{l\in \lbrace 1,c\rbrace }\) , where pointers associated with different security levels require different attributes to decrypt. The ciphertext structure introduced in [2]} is adapted as below:

\(\mathbb {C}:=\left\lbrace \mathbb {A}, \forall k_{l}:\lbrace \mathbb {A}^{\prime \prime }_{i}\rbrace _l, \mathbb {C}_{k_{l}}, \tilde{\mathbb {C}}_{k_{l}},\forall y: \mathbb {C}_{y}, \mathbb {C}_{y}^{\prime }\right\rbrace \\{\left\lbrace \begin{array}{ll}\mathbb {C}_{k_{l}}=g^{\delta \varsigma _{l}}, \ \ \tilde{\mathbb {C}}_{k_{l}}=\mathfrak {N}_i \cdot e(g, g)^{\mathrm {\gamma \varsigma }_{l}} & \\\mathbb {C}_{y}=g^{q_{y}(0)}, \ \ \mathbb {C}_{y}^{\prime }=H(\operatorname{att}(y))^{q_{y}(0)} & \\\end{array}\right.}\) 

where \(g^{\delta }\)  and \(e(g,g)^{\gamma }\)  are extracted from the public parameters \(\mathfrak {pp}\)  generated during the SETUP phase by the CTA. Moreover, we note that the advantage of CP-ABE is that the enciphering secret is built into the relevant ciphertext, rather than being placed in the private key (key management is minimised) [3]}. Here, the enciphering secret \(\varsigma _{l}\)  embedded in each ciphertext with a particular security level \(k_l\)  is computed as \(\varsigma _{l}:=\sum _{i \in \left\lbrace 1,2, \cdots , n_{l}\right\rbrace } q_{r}\left(\operatorname{index}\left(x_{i}\right)\right)\)  where \(q_{r}(x)\)  is the polynomial related to the root node \(r\)  of \(\mathbb {A}\) , \(q_{r}(x)=a_{0}+a_{1} x+\cdots +a_{d_{r}} x^{d_{r}}\)  [2]}.

multiSign(\(\mathcal {SK}_i\) ,\(\mathbb {V}\) ,\(\mathfrak {msg}\) ): This algorithm requires several rounds of communication between sigining parties (e.g., DO and SPs). A compact multi-signature \(\sigma \)  is generated if all participants are honest, which means that the multiSign algorithm terminates immediately whenever one signer is dishonest. It takes as inputs a message \(\mathfrak {msg}\) , the current signer's signing key \(\mathcal {SK}_i\) , and a set of verification keys \(\mathbb {V}:=\lbrace \mathcal {VK}_1,\mathcal {VK}_2,\cdots ,\mathcal {VK}_n\rbrace \)  of all participants. The multi-signature \(\sigma :=(\mathcal {RC} \leftarrow \prod _{i=1}^{n} \mathcal {RC}_{i}, \mathcal {MS} \leftarrow \sum _{i=1}^{n} \mathcal {MS}_{i} \bmod p)\)  is produced as a two-tuple containing the aggregated partial signatures \(\mathcal {MS}\)  and the nonce commitment \(\mathcal {RC}\) . It is generated based on the signing algorithm presented in Bellare and Neven's Multisig scheme [5]}, and the adapted version is shown in Fig. [fig:multisig]5.
In our system, there are two forms of data that need to be multi-signed: the EHR blocks per se and the ciphertext containing the secret relationships between them. Hence, we define \(\sigma _{\Phi _{i}}\)  as \(\sigma _{\Phi _{i}}\leftarrow multiSign(\mathcal {SK}_{i} ,\mathbb {V} ,\mathfrak {msg}=H( \Phi _{i} \Vert  \mathfrak {N}_{i} \Vert  \mathfrak {pp} \Vert  t))\)  to represent the multi-signature for a given EHR block, and we define \(\sigma _{E_{i}}\)  as \(\sigma _{E_{i}}\leftarrow multiSign(\mathcal {SK}_{i} ,\mathbb {V} ,\mathfrak {msg}=H( E_{i} \Vert  \mathfrak {pp} \Vert  t))\)  to represent the multi-signature of the secret relationships. These ensure that DOs and SPs cannot refute their responsibility for the EHRs provided and allow TDB and DUs to verify the integrity and authenticity of the EHRs when necessary.

verify(\(\sigma \) ,\(\mathbb {V}\) ,\(\mathfrak {msg}\) ): This deterministic algorithm is the last key algorithm in the ACCUMULATION phase. It can be executed by the TDB and DUs to verify the multi-signature \(\sigma \) . It starts by gathering the challenge numbers: \(ch_{i} \leftarrow H_{1}\left(\langle \mathbb {V}\rangle \Vert  \mathcal {VK}_{i}\Vert  \mathcal {RC} \Vert  \mathfrak {msg}\right)\)  for \(\forall i\in \lbrace 1,2,\cdots ,n\rbrace \)  as in the third round of the signing process via an ideal cryptographic hash function \(H_1:\lbrace 0,1\rbrace ^* \rightarrow \lbrace 0,1\rbrace ^{m\in \mathbb {N}}\) . These challenge numbers are then applied to the final validation expression: \(g^\mathcal {MS} \stackrel{?}{=} \mathcal {RC} \ {\prod _{i=1}^{n}} \mathcal {VK}_{i}^{ch_{i}}\) . According to MS-BN, the verification fails (\(\bot \leftarrow \)  verify\((\sigma ,\mathbb {V},\mathfrak {msg})\) ) if the above equation does not hold. The whole ACCUMULATION phase will also fail, and the data cannot be stored at this point. Therefore, legitimate EHRs can only be saved to the TDB if all the accompanying signatures \(\sigma \)  are validated by the TDB.

