## 3 Proposed Method
### Architecture and Flow Chart of the Whole System  
Figure 4 describes the interaction among medical entities (cured patient, doctor, insurance company) of the proposed blockchain-based collaborative medical decision gathering scheme. If a patient needs collaboration, a request is made to the cured patient, doctor, and insurance company through PoF. Then, cured patients return past treatment experience, doctors return their medical verdict, and insurance companies return their policy back to the PoF. After calculation, PoF returns a successful collaborative medical decision to the patient. During the process, a successful collaborative medical decision and decision providing stakeholder's identities are also recorded. The PII of participating entities is stored in associated local databases. The collaborative medical decision and the hash of locally stored PII are stored in the blockchain (Figure 4). Four major entities are expressed as patient, P; cured patient C\({}_{\text{p}}\); doctor, D; and insurance company, I\({}_{\text{c}}\) (Figures 4 and 5). All major entities hold a local database (DB\({}_{\text{loc}}\)) and connected blockchain database (DB\({}_{\text{bc}}\)). Finally, an application programming interface (API) poses by four major entities as a communication interface (Figures 4 and 5). \begin{table}
\begin{tabular}{l c c c c c c} \hline \hline
**FeaturesSchemes** & **[PERSON] [69]** & **[PERSON] [61]** & **[PERSON] [28]** & **[PERSON] [70]** & **[PERSON] [65]** & **Proof of** \\ \hline Blockchain architecture & Public & Public & Public & Private & Public & Consortium \\ Off-chain data & No & No & No & No & No & Yes \\ Proposed new consensus & No & Yes & Yes & No & No & New \\ Implementation cost & High & High & High & Medium & Low & Low \\ Purpose of use & Data & Data & No & Drug supply & Data & Decision-making \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Comparison of blockchain-based medical and healthcare architecture. To adopt core blockchain architecture, the major entities (P, D, I\({}_{\text{c}}\), and C\({}_{\text{P}}\)) are considered as a node. In PoF based scheme, all nodes are assumed to be located within a consortium blockchain network and connected via the internet. Node structure and functional properties are discussed here:  
* Patient (P): Patient, [PERSON] might be deprived and located in a distressed area without ample medical facilities. By this scheme, [PERSON] achieves a decent treatment (medical decision) by collaborating with D, I\({}_{\text{c}}\), and C\({}_{\text{P}}\). [PERSON] is equipped with a DB\({}_{\text{loc}}\), an API, and a DB\({}_{\text{bc}}\) to manage identities and decisions. * Doctor (D): Doctor, [PERSON] collaborates with D, I\({}_{\text{c}}\), and C\({}_{\text{P}}\) through PoF to help [PERSON] with an expert decision. [PERSON] has a DB\({}_{\text{loc}}\), an API, and a DB\({}_{\text{bc}}\) to manage identities and decisions. * Cured patient (C\({}_{\text{P}}\)): Cured patient, C\({}_{\text{P}}\) represents patients already treated with a similar disease. C\({}_{\text{P}}\) collaborates with D, I\({}_{\text{c}}\), and C\({}_{\text{P}}\) and helps [PERSON] with the experience C\({}_{\text{P}}\) gathered during diagnosis. A C\({}_{\text{P}}\) also uses a DB\({}_{\text{loc}}\), an API, and a DB\({}_{\text{bc}}\) to manage identities and decisions. Figure 4: The system model of the collaborative medical decision gathering scheme (proof-of-familiarity (PoF) consensus). Figure 5: Stakeholders (participating entities) collaborating for medical decision gathering in PoF. * Insurance company (I\({}_{\rm C}\)): Insurance company, I\({}_{\rm c}\) deals with health-related financial strategies of a P I\({}_{\rm c}\) uses a DB\({}_{\rm bc}\), an API, and a DB\({}_{\rm loc}\) to manage identities and decisions. Data categorization and storing: PII, PPII, and NPII are data types and DB\({}_{\rm bc}\) and DB\({}_{\rm loc}\) are database types used in PoF based scheme.