According to Agbo et al. [15], the blockchain is beneficial for healthcare applications. In particular, it facilitates decentralization, improves data security and privacy, and ensures health data ownership and verifiability. Moreover, the blockchain supports the development of a robust and transparent healthcare system.

Furthermore, Witchey [17] suggested that existing EMR systems lack proper management of the history of healthcare transactions. The blockchain’s Proof of Work (POW) approach can validate such transactions between various entities.

Conceptually, the blockchain is secure by design [18], and can mitigate many traditional security risks due to the distributed ledger’s decentralization nature [14]. Additionally, it supports decentralized consensus and consistency-building mechanisms, which makes applications resilient to malicious attacks.

Additionally, patients have more control over their medical records in blockchain platforms, and thus data sovereignty is a possibility [2]. Since the changes to the blockchain are visible to all members of the patient network, any unauthorized modifications can be detected easily [18]. With the blockchain, cryptographic functions can be used to ensure the pseudonymity of the patient [19].

According to Hölbl et al. [3], better integration of blockchains is an emerging issue in the healthcare domain. Moreover, many advanced features are not used due to a lack of expertise and investment.

Kassab et al. [14] suggested that the blockchain in its current form cannot resolve all the critical challenges that have emerged in electronic healthcare systems (EHS). Scalability, performance, usability, and interoperability are major challenging issues for viable EHR systems. Currently, blockchain-based systems only play a supplementary role in EHS [20].

The size of healthcare data like imaging and treatment plans is large, but the blockchain was designed to handle transitional data, which are trivial in size. Hence, scaling up is a challenging issue [21] that negatively affects performance. Off-chain storage is a solution to this problem: large files are stored in traditional storage, and related hashes are stored in the blockchain [18].

In general, data in a blockchain are immutable. However, in many countries, healthcare-related privacy laws support the permanent deletion of patient records, which challenges the immutability notion of blockchain [18]. The deletion of records for various reasons is a reality. Data redundancy and filtering mechanisms can be used to support some sorts of record editing options [22]. Moreover, the blockchain supports patients’ ownership and autonomy over personal records, which may negatively affect patient care, especially in emergencies [23].

The interoperability of healthcare systems is a priority in many countries [14]. The blockchain needs to address issues like the resolution of discrepancies and confidence measures for the various sources of information [24]. Zhang et al. [25] proposed some metrics to assess the interoperability of blockchain-based healthcare apps. They categorized interoperability into three categories: foundational, structural, and semantic interoperability.

According to Ribitzky et al. [26], the blockchain is still overly promoted in the healthcare domain. Although it attracts much attention and investment, there is a lack of incentive to adopt it for practical purposes [27].

In a recent study, Kassab et al. [27] suggested that the commercialization of blockchain in healthcare is still far from reality. They state that only 33% of primary studies provided an actual implementation of a blockchain-based healthcare system. Twenty-five percent of studies are on managing healthcare records, which makes this the most popular subdomain. Unfortunately, there has been no real industry-level validation study until now. Therefore, in this subsection, we explore some prominent implemented healthcare applications based on blockchain.

Healthcare Data Gateways (HDG) is an app architecture proposed by Yue et al. [28] to provide data ownership of the patient and facilitate flexible data sharing without violating privacy. If necessary, HDG ensures data anonymization by removing identified personal information. Therefore, HDG supports collaboration between multiple HDG apps.

Azaria et al. [29] developed MedRec, which is a decentralized record management system used to handle EMRs. It gives patients and doctors an immutable log to manage healthcare records by using smart contracts.

BlocHIE is a blockchain-based platform used to exchange healthcare information; it was developed by Jiang et al. [30]. They differentiated healthcare data into two categories (EMR and personal healthcare data [PHD]), and proposed two loosely coupled blockchains to handle them separately. They integrated off-chain storage and on-chain verification techniques to reduce load and improve authenticability.

Griggs et al. [31] developed a real-time patient monitoring system using a private blockchain based on the Ethereum protocol. They utilized blockchain-based smart contracts to perform real-time analysis and log transaction metadata for medical sensors attached to the patients. Meanwhile, Liang et al. [32] used a cloud-based blockchain platform to store real-time data from wearable devices; this ensured self-sovereign data ownership and data integrity.

In the present study, we developed an EMR system based on a private blockchain to manage child vaccination records. Thus, we keep vaccination records as simple transactional records, and there is no need for off-chain data management supports, which is problematic in many blockchain-based EMR systems.

In Tab. 1, we present all the user requirements collected from various stakeholders.

In Tab. 2, we present all the system requirements that we have identified for various stakeholders.

In this section, we present the architecture of VacChain. Fig. 2 shows the major components of VacChain and the interactions between them. The whole system consists of multiple layers, which are described below.

Layer 1: The user interface layer is where the participants can interact with the system via Angular [34] to either read information or send new transactions. Health admins create a new vaccination record. The child’s family is the owner of the vaccination record, and any update of vaccination records requires access permission from the family. Hospitals, schools, and insurance can see the history of vaccination records after getting permission from the family. Hospitals can create a new vaccine detail for each visit, which contains the doctor’s notes about the child’s current status and the physician’s signature.

Layer 2: The cloud middleware layer is an intermediate layer between layers 1 and 3. It ensures that there is no single point of failure as opposed to a centralized setting in which one dedicated server hosts the middleware infrastructure. REST API [35] connects to Angular to receive the data and then stores them to the blockchain by contacting an appropriate API to interact with a relevant smart contract in layer 3.

Layer 3: Lastly, we have the blockchain network layer, which contains ledger and smart contract services. Data are encoded during transactions, and transactions are bundled into blocks. Each block contains a hash of the previous block to verify and validate the whole data set. Each new block is considered as an update to the state of this network. Transactions can contain computational steps that influence or create a new smart contract. All transactions are generated by the smart contracts, which are subsequently distributed to every peer node in the network [36].

There are two components in the ledger: a world state, and a blockchain [37]. The world state is a database that holds a set of current values of the ledger states. Moreover, it allows the program to directly access the current values of a state instead of calculating them by traversing the entire transaction log. The world state can be changed frequently, as the states are created, updated, and deleted. The second component is a blockchain that is an append-only database. Once added, information cannot be deleted or changed, and thus it is immutable. All the changes that occur in the current world state are recorded in the blockchain.

In this subsection, we present various process models based on the user and system requirements of VacChain. We present sequence diagrams to show important scenarios related to the vaccination process; for instance, Fig. 3 illustrates the processing of a vaccination visit. In VacChain, we have seven participants: health admin, family, hospital, doctor, physician, school, and insurance company. When a baby is born, a new vaccination record (VR) is created by a health admin, who links the VR with the infant’s family ID. Therefore, the family becomes the owner of a VR. For every vaccination visit, the family must give access permission to the hospital to view or update the VR. If a hospital has access permission, it can create a new vaccine detail (VD) and write the details of the visit, such as vaccine name, child name, child age, and the doctors and physicians names who supervise the process. Linking health professionals’ names in the vaccine detail ensures that the respective professionals gain access permission to the VD. In the next step, the family goes to a designated doctor to check the status of the child, and he writes a note about this visit in the VD. The doctor can read all previous notes related to the VD. Finally, the family goes to another designated physician to give the child a specific vaccine, and a signature is added to the VD to confirm this visit. At the end of a visit, the hospital links the current VD to the child’s VR. This process repeats for each visit. Later, when a school or insurance company asks for a child’s vaccination records, they can obtain access permission from the family to allow them to see all vaccine details of the vaccination record.

To clarify internal transactions within VacChain, we present an example using a sequence diagram in Fig. 4. This figure depicts how a physician’s signature is stored in the blockchain database. Whenever a physician requests signing on a VD, it is considered as a transaction and submitted to a smart contract. This transaction is recorded in the blockchain as a new block, and the ledger is updated.

The health admin page contains three forms under three different tabs. These forms are “Participant,” “Record,” and “History”. These forms can be filled in by the health admin only. The "Participant” tab is for creating a new participant. In this tab, the health admin fills in the required information of the participant, which are participant type, username, full name, and ID number. If the participant is a doctor or a physician, there is an additional field for their hospital name.

The second form, “Record” is for creating a new vaccination record by entering the child’s family username and the child information, such as their name, gender, birth date, and family’s file number.

Lastly, the “History” tab is where the health admin can see the history of all modifications in a specific record. After searching by the family username, this specific record is selected so that the admin can view all vaccination records for each child of that family. For example, we searched for the “Ali” family to display the family’s children’s records. Ahmad is a child of the Ali family; by clicking on Ahmad, the admin can see all of Ahmad’s vaccination records and related details, such as vaccine names and his age when he received a given vaccine.

The hospital page has two main tabs: one for creating a new detail, and the other for displaying the history of a specific record. For each vaccine visit, the family gives permission for the hospital to access the child’s vaccination record. After obtaining access permission, the hospital can access the child’s record by searching for the family’s username. All children’s records of this family will be shown with the child’s name. Clicking on the child’s name will open a form to collect the required information for each visit. The following information needs to be provided: vaccine name, doctor name, physician name, and some information about the child (such as weight, height, and body temperature). Now a new vaccine detail is created and added to the child’s record. Moreover, the hospital displays hospital forms for viewing all modifications in a specific record of the child’s vaccine details.

After creating a child’s vaccine detail, the doctor will have permission to access the child’s record. That is, he can now search by the child’s family username to find the record of the child and see all vaccine details. Then, the doctor adds his notes about whether the child can take a vaccine, depending on the child’s status.

The family goes to a physician after the doctor decides the child’s status. Like the doctor, the physician can also access the child’s record by searching the family’s username, and can see all vaccine details of that particular child. The physician reads all of the child’s information and the doctor’s notes, gives the child the recommended vaccine, and then signs on the vaccine detail. In the case where vaccines are not available, the physician will write them in the remaining vaccine field; during the child’s next visit, the physician will read this last vaccine detail and know which vaccines have not yet been given.

Our application allows the child’s family to see all their children’s records and vaccine details. The family page consists of two tabs: one for viewing their children’s records and their vaccine details, and the other for giving access permission to other providers. Moreover, selecting one of the vaccine details will show a dialog box that contains all the information related to a particular record, such as the physician signature. In the permissions tab, the family can give access to selected vaccination records to other providers such as hospitals, schools, and insurance companies.

Schools and insurance companies have similar privileges. The school (or insurance company) can find the child’s record by searching by the family’s username after getting permission to access the child’s record from the family. The school and insurance company can check vaccine details for the specific child and see all detailed vaccine information in a dialog box (Fig. 7).