MRBSChain, a new scalable health records binance smart chain framework enabling a paradigm shift in health records management

0

This section initially begins with the existing centralized EMR framework. The likely constraints of the centralized architecture are presented and the rationale for the blockchain-based decentralized framework is presented in this section.

Centralized EMR framework

The creation, update and storage of EMRs are usually managed by doctors or administrators in a centralized database server, internal to hospitals, which poses the problem that patients leave information scattered in different hospitals. It should be noted that these records are created in the local databases of various hospitals after patients visit them. In this sense, patients lose access to past information, whether or not it belongs. At the time when they visit different hospitals, they do not have access to their past records to give the specialist their final past prescription records.15.16. Interoperability, security, and privacy challenges between different hospital settings present extreme barriers to information sharing. It is difficult for individuals to get the information they need due to the lack of interlinked information. Thereby; in the traditional facility-centric and centralized approach, patients are entities external to the existing EMR system. On the other hand, doctors or administrators being internal entities of the system, they have complete access and control over the sensitive medical records of patients. Figure 2 shows the traditional centralized EMR framework.

Figure 2

Traditional centralized EMR framework.

Proposed Decentralized MRBChain DME Framework

In order to solve the challenges and problems of traditional centralized EMR frameworks, this paper proposes a new decentralized MRBSChain EMR framework for medical records management as shown in Fig. 3. The proposed system is designed with a patient-centric approach by keeping patients, doctors and administrators all as internal entities under the blockchain. Each new entity in the proposed framework has to go through different levels of phases which start with the creation of a new block with the registration of a new entity in the system. Initially, a new entity has a private hash key and a unique block wallet address. If the entity already exists, an error is generated, otherwise once successfully saved, a new block on the chain is added with a private SHA256 hash key and a global unique identifier. In the next phase, each entity is approved and verified by the system administrator if the approval fails, no further access is allowed to the new entity, but once the administrator is approved, he assigns a role of physician or patient to the entity. This role is again inherently a private hash key generated using the Keccak256 encryption algorithm. The next phase differs for patients and physicians, as the patient can continue to add their medical issues and other details; doctors must have access to patient records, but this is done by the administrator only. The administrator can only approve and revoke access to the medical record.

picture 3
picture 3

Proposed Decentralized MRBChain DME Framework.

Privacy Preserving Identity Model

For each new entity, a new wallet block address (BWA) is assigned using the private hash key (PK) and Metamask Account (MMA) as shown in Eq. (1) where i represents each entity that can vary from i = 1…n.

$$left{ {{text{P}}_{{{text{K}}({text{i}})}} ,{text{MMA}}_{{({text {i}})}} } right} Rightarrow {text{BW}}_{{{text{A}}({text{i}})}}$$

(1)

Each Metamask account contains BNB tokens in the Metamask wallet. After deployment by the administrator; the patient and doctor entity using their blocked wallet address can register and create their records on the BSC. If the record creation transaction is successful and validated by the validators on the BSC network, a new block is added on the BSC.

For each new block, a unique SHA256 private hash key (SHK) and the global unique identity (gUId) is generated as shown in the equation. (2) where i represents each entity that can vary from i = 1…n.

$${text{BW}}_{{{text{A}}({text{i}})}} Rightarrow left{ {{text{SH}}_{{{text {K}}left( {text{i}} right),}} {text{gUId}}_{{({text{i}})}} } right}$$

(2)

Authentication role mapping (ARM)

To enforce security and access control, an improvised consensus is implemented in the proposed work called ARM in research. It is a process of assigning authentication roles to patients or physicians and mapping their BWA with each other for secure EMR access. Once a new entity, the patient or physician registers successfully; a new SHA256 private hash key (SHK) and the global unique identity (gUId) is assigned as shown in the equation. (2). Each new entity is approved by the administrator, without approval, neither the patient nor the doctor can perform any operation in the system. Once the administrator has approved, each entity is assigned a role (Patient/Doctor). This role is a unique private hash key generated using the Keccak256 hash algorithm and represented by KHOUR as shown in Eq. (3) where i represents each entity that can vary from i = 1…n.

$$left{ {{text{SH}}_{{{text{K}}left( {text{i}} right),}} {text{gUId}}_{{ ({text{i}})}} } right} Rightarrow {text{K}}_{{{text{HR}}({text{i}})}}$$

(3)

After the approval process, the patient entity can add medical issues to the existing record and can view, access their EMR anywhere and anytime as they are recorded on a decentralized network. The administrator assigns access to patient records to the doctor for the consultation process. The proposed framework internally implements encrypted hash mapping where to block wallet addresses (BWA) for the patient and doctor entity are mapped as shown in the equation. (4) where i represents each entity that can vary from i = 1…n. For this mapping to be successful, each Patient and Physician entity must be successfully registered and approved. Each entity must have a private SHA256 hash key, a globally unique identifier, a Keccak256 hash role (SHK, guide, KHOUR).

$${text{BW}}_{{text{A}}} left( {{text{Patient}}_{{({text{i}})}} } right) Leftrightarrow {text{BW}}_{{text{A}}} left( {{text{Doctor}}_{{({text{i}})}} } right)left{ {{text{SH}}_{{{text{K}}left( {text{i}} right),}} {text{gUId}}_{{({text{i }})}} ,{text{K}}_{{{text{HR}}({text{i}})}} } right}$$

(4)

Upon successful mapping, the physician can conditionally access the patient’s EMR only if assigned to the patient by the administrator. To maintain patient security and control over their personal records, access is revoked for that particular physician by the administrator once the goal is met.

Share.

Comments are closed.