Development of an Internet-of-Healthcare System Using Blockchain

The Internet-of-Healthcare Systems is a highly distributed special emulation of the Internet of Things technology. Patient medical data sourced from the participating hospitals are integrated with a decentralized storage system using blockchain technology to provide the highest level of storage and access security possible, overcoming the security and data administration problems that may occur at the local hospital level where the patient data is stored within the hospital’s central server, especially if that data is subjected to external threats. The Internet-of-Healthcare Systems, currently implemented in over 350 hospitals, utilises software agents, accessed using the Message Queueing Telemetry Transport protocol, which efficiently handles potentially thousands of participating local systems without loss of network timeliness. Also, the system works with the wide variety of health information systems used in the participating hospitals. This makes the system a worthwhile candidate for a nationwide integrated health records system, and is an exemplar for many different types of secure networks that could be generically called an Internet of Special Things; a network of software agents programmed for a special purpose. Mobile device apps enable secure direct access to patient data in a central blockchain with download capability to a mobile device, under strict and fully managed access control using Amazon Web Services, with permissions controlled by the Key Management System. Feedback from participating medical staff indicates a high level of satisfaction with all aspects of the system: ease of use, ease of installation, maintenance and update, and, importantly, the security of the system.


I. INTRODUCTION
Electronic Health Care Systems, generally termed eHealth systems, are now seen as being very important in national public health administration systems. The World Health Organization (WHO) has highlighted the importance of, and motivation for, Electronic Health Care Systems (eHCSs) [1]. The system presented in this paper was developed within the broader national development strategy promulgated by the Thai Government Ministry of Public Health, termed Thailand 4.0 [2], the overall intention of which is to digitally create a national, fully integrated, public health information system. The associate editor coordinating the review of this manuscript and approving it for publication was Wenbing Zhao . For simplicity of reference, the terminology of Electronic Health Record (EHR) will be used to refer to the data package elicited by the web agents from the participating medical institution; hospitals, medical clinics and so forth. The patient information systems used internally by participating hospitals are termed Hospital Information Systems (HIS) and the terminology of e-Health Care Systems (eHCS) is used to refer generally to any electronic health information system in use or available, however referred to in the literature.
Traditionally, health service providers, even large hospitals, kept medical records of patients in manual form in card indexes or manually updated folders. There has been a significant move towards computerized patient information systems which have replaced the manual systems, which were error-prone and time-consuming to manage and to VOLUME 9, 2021 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ retrieve patient information, and both the manual systems and the computerized systems that replaced them are discrete bounded systems local to their location. The variety of these systems also presented an obstacle to overall, national, integration. Acknowledging the strategic public health administration policy of the Thai Ministry of Public Health, researchers and medical practitioners, and academics at the Naresuan University (NU) Faculty of Medicine and Naresuan University Hospital, together with researchers and developers in the Faculty of Computer Engineering at NU, collaborated on the development of a sophisticated system whose purpose was to provide an e-consultation facility to enable specialist medical, surgical and ICU personnel to virtually participate in crises at remote hospitals and medical centers where such specialist knowledge was unavailable. This prior work has been presented in previous publications [3]- [5].
The system previously developed also enabled the networking of health services providers, hospitals, and medical centers, which allowed full patient medical histories to be available on an Anywhere / Anytime / Anydevice basis, thereby providing information continuity and, importantly, continuity of patient care when patients move between medical service providers. Enhancements to this system to strengthen the security and privacy aspects regarding patient medical data are the central focus of this paper. These enhancements have resulted in a highly secure distributed system with sufficient network timeliness to be able to be promulgated nation wide to the thousands of medical facilities in the nation.
Medical records have a special status requiring confidentiality, privacy protection, and secure storage and handling. Any system designed to network patient data must be designed, developed, and promulgated with this in mind. This was the first of three major factors that confronted the researchers in this project.
The second major factor was the variety of these local patient information systems, with different application software suites from different providers, with different DBMS and database schemas, different languages, different hardware, and different utility software. A way needed to be found to enable these diverse systems to have a single, canonical network interface for data accessing to seamlessly networking them together.
Thirdly, inherent in the intentions of the researchers for the ultimate use of the system as a nationwide network linking all hospitals, health clinics, and medical practitioners, the system requirements demanded high-speed, ultra-efficient processing and networking connectivity able to network potentially thousands of medical facilities nationwide while maintaining a high level of timeliness and response times. As well, given the intended extent of the system in the future, the aspects of ease of implementation and ease of maintenance required appropriate attention.
In this paper, we elaborate on, first, the new architecture which we have termed the Internet-of-Health-Care-Systems (IoHCS) that securely manages the historical patient records gathered from all participating hospitals in a network. This was achieved by applying blockchain technology as a method for recording patient data, where sharing, distribution, communication, and agreement protocols can be applied to make the gathered patient data highly secure and immutable.
Second, we describe the way that the hospital Health Information Systems (HIS) of all of these hospitals have been networked together using software agents via Message Queueing Telemetry Transport (MQTT) protocol. This is a central aspect of the IoHCS as each hospital has its own HIS, each of which may have different system and data structure characteristics that are opaque to the network.
As well, we discuss our efforts at ensuring ease of installation and maintenance, and useability and ease of use, or the system.
While achieving these required factors, the security of access to, and storage of, patient medical data, wherever held, was always considered to be of the highest order. Responses from medical personnel from all participating hospitals and health centers, indicated that the security issue is the most important aspect of concern, and the privacy and confidentiality of patient data must be maintained. Data integrity and veracity is essential, and the data must be protected against being tampered with in any way. The central cloud server is potentially a solution to the safe and secure storage of data in an integrated network but is still subject to threats from bad actors. This is particularly relevant to systems based on local servers, or managed locally, at hospitals where technical services are lacking.
Changes to data that may have been tampered with may not be noticed, and, if noticed, may not be recoverable. As well, the integrity of the providers of cloud servers and services is also not guaranteed, and the misuse, monitoring and even sale, of data, is still a likelihood of concern. Patient data must be stored in a manner that provides high reliability and fault tolerance, and ensures the immutability of the data. Blockchain technology is a way to overcome these problems. The distributed or decentralized network and data structures characteristic of blockchains makes tampering with stored data extremely difficult, if not impossible.
Historical data can be recovered from the blockchain intact and unchanged because of the distributed peer-to-peer network characteristics of blockchains that guarantees data integrity throughout the network. Furthermore, a blockchain network has a consensus mechanism that requires the agreement of all participants in the blockchain for all changes to the blockchain.
An Application Programming Interface (API) for reading and writing data for each hospital on the blockchain was also developed, as well as a mobile app that can access patient data with a secured channel using a Key Management System (KMS). This app was then included in the existing HIS of the 350 participating hospitals.
So the system and research being presented here builds on previous research and development in the electronic health systems dimension, introduced above as a collaborative development between researchers at Naresuan University and major local tertiary care hospitals. The interface to this system is illustrated in Figure 1. This system, termed the NUMED System and 'The Doctor Knows You' system app, was specifically developed for the 2 nd Health Region in central Thailand, with the assistance and cooperation of the Administrator of that Health Region, which encompasses 5 provinces in Upper Central Thailand, an area stretching from the eastern border with Laos, to the western border with Myanmar.
With that system and suite of apps, 350 or so hospitals and medical facilities are currently networked for the purpose of integrating their patient medical information records such that their medical staff has full availability of patient medical histories regardless of the service provider for each or any of these services, and individual patients can download their individual medical history into storage on their smartphone or mobile device and carry that data with them, disconnected from the Internet.
The previously developed apps included significant information gathering and communication abilities linking the lowest level of health care involvement; village health volunteers, who number quite literally in the millions, to the highest levels of the Health Region Administration, as well as being a patient history and information-sharing network to support the public health administrative tasks at all levels within the community and the health practitioners.
Prominent in these systems was the use of HoloLens technology, and haptics, enabling the remote control of medical devices and enabling virtual specialist consultations in remote hospitals. Information regarding these systems has been published previously in journals and at international conferences. [3]- [5] op. cit.
The subsequent system development that is the subject of this current paper, builds on that previous system and apps to achieve improvements particularly in the security of the patient data and prevention of unauthorized access to patient data and information tampering. This was successfully achieved by the application of blockchain technology in a central data repository, and the development of software agents that provide the canonical interface to the many diverse hospital patient information systems. These software agents are implemented as front-ends to the hospitals' patient information systems.
The extensions to those apps, incorporating blockchain technology, have been done independently of the 2 nd Health Region administration, and the extended system is now installed, at the time of writing, in 350 hospitals in 3 provinces in the Central North region of Thailand. However, during the development of the blockchain extensions, data from the original 157 participating hospitals were used.
The rest of this paper is organized as follows: Section II discusses the related work on blockchain, electronic health records, and the Internet of Things (IoT). Section III presents the architecture of the IoHCS and also presents the details of the technology used by this system and the implemented system. General discussion is presented in Section IV, security analysis in Section V, and Conclusions in Section VI.

II. RELATED WORK
Blockchain is a shared database storage technology also known as Distributed Ledger Technology (DLT). Data is recorded in such a way that guarantees the safety, security and veracity and immutability over time of that data, including the full recording of changes, edits and deletions. This means that original data 'blocks' in the blockchain remain intact and verifiable, and the blockchain also acts as an unchangeable complete journal or log of data updates separate from the original entry. The beginnings of blockchain technology were in 2008, with the presentation of Satoshi Nakamoto (apparently an alias, but irrelevant to the discussion) in a seminal paper regarding the cryptocurrency Bitcoin where ultra-secure data storage is imperative [6]. In that paper, the author presented the idea of creating a platform that can secure the exchange of cryptocurrency of Bitcoin using the theory of Cryptography and Distributed Computing.
Since its inception in 2008, blockchain technology has been of great interest to developers and researchers for use in various fields, of which medical systems and associated health-related systems are examples [7]. MEDShare [8] was developed to protect the privacy of patients and reduce the risk of misuse of patient medical records. The developers of MEDshare applied blockchain-based data storage for the control and auditing of shared medical data in the Cloud. MEDshare records all operations and data in the system in a tamper-proof manner and can monitor the entities that access data from their data custodian system. A cloud storage system, reported in [9], proposed patient privacy protection for electronic patient records by distributing partial components of electronic patient records amongst several cloud servers and an efficient process for reconstruction of those records. This novel cloud storage system fully ensured data privacy. by employing the Shamir's Secret Sharing algorithm, which is an algorithm in cryptography created by Adi Shamir [10]. This was essentially an Internet of Things (IoT) based system. VOLUME 9, 2021 Another design of a cloud-based Electronic Health Record (EHR) system was proposed by Xhafa et al. [11] which included attribute-based encryption. The system enabled the combining of the separated components of the data from each remote cloud server for easy access and viewing by a physician, preserving the privacy of the patient information using attribute-based encryption. The system structure included components for Physician Authorization and Access and Patient Health Record Storage and Access which allowed patient health records to be shared among physicians.
An Internet of Things (IoT) based system proposed by [12], which the researchers termed HealthChain, was an application of IoT technology for remote patient data monitoring. However, it was recognized that the data retrieved from the IoT device and stored in a centralized data store was not guaranteed to be secure and therefore there was the possibility of leakage of patient information and loss of patients' privacy. As well, there was always the possibility of the irretrievable loss of patient data in the event of a server failure. These researchers overcame these problems by collecting patient health information using the blockchain, thus the name HealthChain. In the HealthChain system, connections between the blockchain and IoT devices were designed to prevent data deletion or correction in order to prevent medical disputes. This is, of course, the primary characteristic of blockchain technology: the immutable aspect of data once in the blockchain so the stored data is never changed, but changes to the data are included in the blockchain as a record or log of changes which, themselves, are immutable.
As reported in [13], health data-sharing on the permissioned blockchain from HyperLedger Fabric was proposed and developed, together with a mobile application that enabled the data owners to control access from other healthcare providers and health insurance companies. Wearable devices were also integrated with the system to collect user's health data. The health data would be synced to the cloud server and was processed before storing it on the blockchain. Due to the size of the health data collected from wearable devices, the Merkle tree was adopted to store only the Merkle root on a blockchain transaction to ensure the scalability and efficiency of the system. (A Merkle root is a simple mathematical way to verify the data on a Merkle tree and are used in cryptocurrency ensure that the data blocks passed between peers on a peer-to-peer network are whole, undamaged, and unaltered. They are central to the computation required to maintain cryptocurrencies like Bitcoin and Ethereum).
The blockchain also stored medical treatment data, insurance claims, and other activities such as data requests, etc. Channeling was also proposed with the scheme to ensure privacy protection.
Cloud-assisted EHR consortium blockchain was proposed in [14]. The blockchain was developed on the Ethereum platform with Proof-of-Authorization as the consensus mechanism. They proposed searchable encryption and proxy re-encryption for the security of data. The system enabled the storage of encrypted patient EHR on the cloud server. The shared EHR must be authorized by their data owner first. The blockchain was for storing keyword ciphertext along with the data owner's account address in order to grant permission for accessing data from the data requester. The data requester could search for keywords in the blockchain and ask for permission from the data owner. If the permission was granted, the data would be encrypted again using the data owner's re-encrypted key before sending it to the data requester which could be a government department, hospital, laboratory, clinic, etc. The scheme achieved security goals and had high computational efficiency.
A proposed framework from [15] could be a role model for the implementation of blockchain technology for EHRs. They also provide a scalable solution with the off-chain storage by implementation from Inter-Planetary File System (IPFS) technology. Each file uploaded in the system contains lab results or other medical records. The IPFS technology uses a peer-to-peer network to store data and to disallow any data alteration and redundancy: the technology will generate a unique cryptographic hash for each file as an identifier. These hashes are used to store the uploaded data in the blockchain together with the patient's ID, name, co-morbidity data, and blood group. Only authenticated users can access the blockchain data due to the smart contract functionality. The security was ensured on many levels with the blockchain characteristics along with the IPFS, and the role-based access functionality on the smart contract etc. Transactions were also performed faster because detailed medical records are stored in the IPFS rather than the blockchain. The proposed framework was developed on the Ethereum platform with Proof-of-work as the consensus mechanism.
A further blockchain-based eHCS was proposed in [16]. In this system, blockchain technology was applied to securing patient data that were shared in a mobile Cloud-based eHCS. The collaboration between mobile applications and cloud computing facilitated data sharing between patients and health care providers, but patient privacy and security of the patient data stored in the Cloud could not be guaranteed. Therefore, to reduce the risk of these problems occurring, the solution proffered in that paper was to share the data in the blockchain with a decentralized interplanetary file system (IPFS) (a protocol and a peer-to-peer network for storing and sharing data in a distributed file system 1 ) on a mobile cloud platform. The implementation used the Ethereum 2 blockchain which is a public blockchain that also works with Amazon Web Services (AWS). This approach enables safe, controlled and efficient access to patient information, and was a significant step towards efficient management of electronic patient health records in a secure eHCS.
In the Internet-of-Health-Care-Systems (IoHCS) discussed in this paper, we store encrypted patient data in a special format which we refer to as the patient's Electronic Health Record (an EHR) on a blockchain per user. Only patient-ofinterest information will be stored on the blockchain in the central location rather than storing all available patient information which can cause tremendously high storage volume.
The main usage of the IoHCS is for medical personnel to view patient EHR for further diagnosis and treatment. A doctor/nurse/medical staff can retrieve a patient's EHR in nearly real time if the EHR is already stored on the blockchain. If they meet a new patient, it would take less less than 10 seconds, depending on how many records would be stored on the blockchain for the patient, up to a maximum of 10 of the most recent medical incidents for that patient (stated in TABLE 2). This process is possible because of the MQTT protocol which can retrieve the patient information from all available participating hospitals without consideration of the number of hospitals. This ensures that the doctor/nurse/medical staff can retrieve and view patient EHRs as required at or by the time that they meet the patient.

III. SYSTEM MODEL
Since the inception of the Internet, new terminology for various usages of the Internet has evolved. Prominent among these is The Internet of Things (IoT) which refers to the addressing of devices of many kinds by their IP address, ranging from 'intelligent' household appliances to individual communication devices on soldiers in the field, and to machinery in remote railway and mining operations. We have taken this terminology and extended the concept to create a more specific term, The Internet-of-Health-Care-Systems (IoHCS) comprising specifically the patient medical information systems located at participating hospitals and other medical facilities, connected in an integrated network of web services.
The obvious difference between the IoT and the IoHCS is that IoT devices are addressed by an IP, and usually exchange a single interaction or single command or item of data whereas the IoHCS presents a canonical interface to the Internet by software agents, or web agents, which have an IP address, and exchange complex data. As previously acknowledged, in our system, we refer to that set of data as an Electronic Health Record (EHR), the format of which is discussed below. Figure 2 shows a schematic of the system that we developed. We achieved this integration of the variety of local hospital information systems and successfully promulgated the system to the original 157 hospitals and other medical service providers, a user base that has now grown to over 350. The IoHCS guarantees the secure and verifiable storage of immutable data by applying blockchain technology.
This data is added to by the downloading of new data, the EHR, from the hospitals and other medical service providers via Internet software agents that present a canonical network-facing structure in front of the wide variety of different patient information systems in the participating hospitals which are based on the different operating systems (Windows, Linux), the many different DBMSs with different schema, different application suites, and so forth.
As can be seen in the diagram, each participating hospital has its own patient information system, the structure and content of which is essentially hidden from the network. Embedded in each of those systems is the software agent that presents a canonical view of each hospital's patient information system. The network of these software agents, also termed web agents, comprises the Internet-of-Health-Care-Systems, the IoHCS. These software agents, which are addressed by their IP address, are accessed using the MQTT protocol. The function of the software agents is to transmit a complex set of patient data in a package, which has a defined structure and content, in response to the network request. We term this complex data package as the Electronic Health Record (EHR) to differentiate it from the Hospital Information System (HIS) of the participating hospital.
We discuss the various components of the overall system including the purpose, the processes, and technology applied in each component.

A. HOSPITAL INFORMATION SYSTEM (HIS)
This component is not part of the IoHCS but it is very important and needs to be considered for designing the interface (an agent) for interacting with patient data. The designed agent has to support the different patient information systems in different hospitals, which we term their Hospital Information System (HIS). Each participating hospital HIS is potentially a different software package, such as iMed in Windows Server with SQL Server, HosXP in Linux (CentOS) with MySQL, and PatientInfo in Windows Server with SQL Server.
Because of these many and various HIS configuration, it was necessary to provide a common interface to the network to 'front' these systems. We refer to this common interface as a 'canonical' interface. This means that, essentially, the particular hospital patient information system itself is not part of our system but is viewed through a web agent, or software agent, that was defined and developed by the research team. The web agents will be discussed in detail below.

B. THE CENTRAL SERVER
The patient data that is stored in a variety of ways in each HIS, and is opaque to the network, must be converted into a single format for storage on the blockchain. The EHR returned from a hospital via the web agent comprises all of the available information about that patient which is then stored in the Central Server, which acts as a data buffer. That data is then sorted in the Central Server and the 10 most recent records of the patient are then selected and inserted into the blockchain which resides on a dedicated system, located, in fact, at Naresuan University. The Google Database-as-a-Service (DBaaS) technology is used here. Only authenticated users can access the information on the server.

1) MESSAGE QUEUEING TELEMETRY TRANSPORT (MQTT) BROKER
The MQTT protocol is implemented in the web agents which return all of the patient's records from the HIS to be stored on the Central Server.
MQTT technology is used for communicating between machines or machine to machine (M2M). For developing the system, 2 main components were required: • Clients • Publisher -publishes the PID of patients to the MQTT broker • Subscriber -or listener, receives the PIDs published and queries patient records for each PID • MQTT Broker -a medium for queueing and communicating between devices (clients). The process of MQTT is illustrated in Fig. 3. In our case, publishers are mobile phones and API, and subscribers are agents. A web agent (termed a subscriber), is installed in the computer system of each participating hospital.

2) WEB/SOFTWARE AGENTS
For the process, the patient's national ID number is used as the globally unique Patient ID (PID). The PID is the key for retrieving patient records from the different hospitals that they have visited. Patients will also have a local ID allocated by each hospital that they have visited, for identification in the HIS, but this is irrelevant for our purposes as no updates to an HIS are made from our system, so the HIS is a read-only system for our purposes.
Each HIS has a query module installed, written by the developers of the IoHCS for this purpose, that can retrieve and format the patient information that has been requested via the web agent, for the specific patient of interest. This is a read-only process that does not update or modify the patient's data in the HIS. These web agents request the patient information after receiving the PID via MQTT protocol, and the data is retrieved and returned to the web agent by the query module mentioned.
Agents are software processes developed in Python that are either installed as embedded processes in the hospital's system or run on a Raspberry Pi computer-on-a-board that can be installed as a front-end and are connected to the hospital's server machine via their Local Area Network (LAN). The installation and maintenance of this hardware and software were handled by the development team.
One process carried out by each Agent is to format and restructure the extracted patient information data to form the EHR. and encrypt that data before sending it to the Central Server.
The EHR is formatted by the Agent by separating the data into different parts i.e. patient, visit, laboratory, diagnosis, and drug order information, and all parts are encrypted by the Advanced Encryption Standard (AES) 256 Algorithm for each field and transmitted to the Central Server Database in JSON format. The overall structure of the network is illustrated in Fig. 4.

3) BLOCKCHAIN ARCHITECTURE DESIGN
The blockchain system was introduced to increase the data security levels and safety and security of the EHR data retrieved from the participating hospitals. By storing that data in a blockchain at the Central Server, the level of security was raised to the highest level possible. By adopting the hash algorithm for linking the data in each block of the blockchain, and the consensus mechanism, to the distributed peer-to-peer network, the data is stored at a super-secure level.
In a blockchain, each block of data contains a hash of its previous block which can link all blocks together to form a chain of blocks in the order of their arrival in the blockchain. Any change to the data in a block will result in a different hash value being generated. This will immediately indicate that change and the original data is retrieved from the original block. So the hashing concept is a change flagging mechanism. Fig. 5(a) shows a blockchain node with its block data and Fig. 5(b) shows several connected blockchain nodes with the hash value propagated from one block to the next.
As cited previously [14], the blockchain was developed on the Ethereum platform. The Proof-of-Stake concept was implemented as a consensus mechanism to replace the traditional Proof-of-Work concept in which all the mining nodes had to solve a cryptographic puzzle to generate a new block. This required substantial computational power to solve the problem and thus higher electricity consumption, which became a significant cost of processing. Proof-of-Stake, however, acknowledges accounts with a higher priority, or stake, to create a new block without having to solve any puzzles, thus being a faster process at a lower cost.  The blockchain interface API for connecting and interacting with the Ethereum blockchain was developed using the web3.js library. This library is a JavaScript library that provides multiple functions for interacting with the blockchain. While the nodes of the blockchain could be deployed on physical servers located at each hospital, in our system we have constructed four blockchain nodes, each deployed on separate servers located at a physically central location, currently located in a special facility at Naresuan University.

4) THE DATA LAYER
At the data layer, the data is recorded and shared in a consortium blockchain via its block producer node. Based on the blockchain's features, once data has been recorded in the blockchain, it will be immutable forever.
To unify the data and to have a better authorization mechanism and control of access to the data layer, the application layer manages the authentication and interaction with the data layer by its Data Sharing Module.
The information reader and writer need to interact with the data layer via the application layer. The read and write interfaces in the application layer will be post/get, and the Data Sharing Module will convert them into the data structure required for the blockchain.
The Amazon Web Services (AWS) Key Management Service (KMS) is used to create and manage the encryption of the data. The Master Key that is used to encrypt the Data Key and the encrypted data generated from the Data Center, which will then be stored in the blockchain, never leaves the KMS environment.

5) THE DATA SHARING MODULE
The Data Sharing Module is the interface to control the receipt of the data input from the Application Logic layer as well as controlling the transmission of data sent to the Smart Contract mobile phone app (discussed next).
The Smart Contract library is the template for controlling writing the data into the blockchain and the Ethereum Virtual Machine (EVM) and has an Interpreter compatible with the Solidity language. The blockchain is a full stack of services, including a web service, with access management, a data monitoring service, transaction verification, and block validation. VOLUME 9, 2021

6) SMART CONTACT
The Smart Contract is a software module for reading data from, and writing data to, the blockchain. The Smart Contract provides information to the mobile device as a 10 record patient information list.
The patient information is structured in 6 parts, which are personal information, visit information, laboratory tests information, drug order information, and a hash value created by the encryption module. The smart contract for our Ethereum blockchain platform is developed with Solidity language.
When the system wants to access patient information for a specific PID, the mapping object will be used to store patient information in the form of a dictionary which requires the PID to access the patient information. For the patient information creation function, the system will check the hash constructed for the new visit and compare it to the hash of the latest existing visit information for the patient. If that hash value exists, the new visit information will not be written in the system storage as that implies the new data is a duplicate.

C. APPLICATION PROGRAMING INTERFACE
The Application Programming Interface (API) is for connecting to and interacting with the blockchain. The API functions can read or write patient data from the mobile application. The API is developed in Node.js, integrated with the Amazon Web Service: Key Management System and Simple Storage Service (AWS KMS and S3), to encrypt 2 keys which are the hash-keys (salt) used for searching and the encrypt/decrypt key used to encrypt/decrypt patient data retrieved from an HIS. This data is forever encrypted and cannot be accessed by any means unless specifically authorized to be decrypted with the AWS KMS. As illustrated in Figure 8, in the system, 2 master keys will be generated from the Amazon Key Management System (Amazon KMS). These keys are stored in the Amazon server with a very high-security system. These keys will be used to encrypt the hashing and encrypting/decrypting of the data keys of our application. The hashing key is used for searching patient information in the blockchain system, and the encrypting/decrypting key is used for encrypting/decrypting the information from the Data Center blockchain for the API Server and the mobile application.

1) MOBILE DEVICE SYSTEMS
The Mobile Device Systems are for clients (medical personnel) to access patient information from the blockchain. We developed the mobile application using the XCode framework and the Swift language. This application sends requests for data from the blockchain and receives responses via the blockchain API.   9(b) is the patient search screen, and 9(c) is the patient information display. Fig. 9(d) to 9(f) show detailed patient information.
The main menu ( Fig. 9(a)) has 2 main tasks which are writing or updating and reading patient information from the blockchain system. The app was tested by running on an iOS iPhone emulator, and the actual iPhone device.
The PID is entered on the top of the mobile application page and searching is performed by pressing the ''Search'' button. The patient information will be returned in the form of a list object containing information up to the last 10 visits. This limit of 10 was considered sufficient to allow a physician to have all necessary patient history to aid in their diagnosis. Each visit contains information on the visit, laboratory work, diagnoses, drug orders, and other general information. All visits are displayed on one page and a user can scroll through the list, if necessary.
The various information sections are displayed in a form of tabs, but the general information will be displayed in the form of a popup after pressing the ''. . . '' button. These are illustrated in Figure 10 which shows the patient information pages.  ). The laboratory information will be displayed if the patient needs to provide a blood sample. The diagnosis is as described by the attending doctor. The drug order covers all medications and drugs prescribed by the doctor. Blood type and drug allergies are also shown. The general information for each visit, shown in the popup, contains the PID, date of birth, age, address, home telephone number, and mobile phone number, together with the hospital name.
Amazon Key Management System (KMS), and Amazon S3 (Simple Storage Service) provide a stack of security levels that we have integrated into our system, assuring an extremely high level of data and process security.
If the patient information does not exist in the blockchain, the blockchain API will perform the process of writing the patient information from the Data Center where the patient's data is temporarily buffered after being downloaded from the hospitals and writes that data into the blockchain system. The data is then sent to an appropriate mobile device by the Smart Contract app.  The data is from more than 8,500 patients from the original 157 hospitals that were stored in the blockchain when the system was being tested and verified. (This number had significantly increased from that time with more than 350 hospitals now participating) With that number of patients, and with each block in the blockchain containing the information for the 10 most recent visits for the PID, there were 221,269 blocks in the system, in 194GB of storage space. The average elapsed time for writing each patient record to the blockchain is about 3.245 seconds per record (visit), or 3.245 s/block. Each block has an average of 0.89MB per block.
For the real-time data, if there is no patient record for a specific PID in the blockchain, the system will retrieve data from all agents to be stored in the data center, which acts as a data buffer, and the data will then be formatted before uploading it to the blockchain. Thus, the patient information is updated as and when required. If the patient information for a specific PID exists, the system will then return the latest 10 visits at most, and a user can also update the patient information in the blockchain system via the mobile application.

2) IMPLEMENTATION WITH A REAL CASE SCENARIO
As indicated previously, an application that implements these technologies, had been developed in a joint effort by the Faculties of Medicine and Engineering of Naresuan University. The application is targeted for a mobile application, and is called the NU Medical system. Medical and nursing staff from 157 hospitals in Thailand are using the application VOLUME 9, 2021 for consultation on patient cases, which mostly are not very urgent. The application also helps medical staff, located in rural and remote areas, to virtually consult specialist surgical, medical or ICU nursing staff who are located at a major tertiary hospital.
When the medical staff need to consult, they need permission to access the patient medical information and patients also need to sign an official document if they want to permit their medical information to be accessed.
The patient's medical information will be attached to the case initiated by the medical or nursing staff, allowing the doctor to read and analyze the data prior to further diagnosis.
The doctor will respond in the case by writing instructions to the local staff on appropriate treatment procedures and drugs to be prescribed for the patient. If the staff is not clear with the doctor instruction and feel that they should not immediately proceed with the case, they can directly contact the doctor from the application.
A medical staff member searches for and retrieves a patient's medical information to present to the consulting doctor. This information includes any prior consultation cases in the consult list menu. They can also contact doctors directly via an online messaging app, or by phone, or video call. They can also change appropriate settings regarding the online/offline status, profile, and login/logout. The staff can search by taking a photo of a patient/ citizen PID card or entering the patient PID directly and if the staff is permitted to search and access the patient information, they will be prompt with the alert for the staff to confirm. The staff needs to accept and confirm the privacy policy. The first page of the search result is the patient general information page and the staff can take a look for more medical information via the Medical Information menu button.
The staff can check the visit, laboratory, diagnosis, and drugs order information for further diagnosis.
1) For MQTT system, the patient data is queried and retrieved from all hospitals. This data is then updated  in the data center. To ensure that all data is updated, we set the time for 10 seconds  2) For Retrieving and Formatting data from the Data Center, the time depends the number of visits by the particular patient, but the average time is 3.089 seconds 3) For Actual writing to blockchain, the average time to write 1 block is 0.156 second and n is the number of visits for that particular patient. Table 3 shows a comparison between the technology applied in the IoHCS and that of related work. This shows the differences in capabilities of each system. Citations in the comparison include: [8] formulation of a data-sharing mechanism used by the blockchain-based data sharing among untrusted parties for data security and provenance. [9] employs Shamir's secret sharing concept where the EHR is divided into multiple segments by a healthcare center, and the segments are distributed to numerous cloud servers. When retrieving the health record, the healthcare center captures segments from partial cloud servers and reconstructs the EHRs.

IV. GENERAL DISCUSSION
[11] designed a secure cloud-based EHR system, which guarantees security and privacy of medical data stored in the cloud, relying on cryptographic primitive but not the full trust over cloud servers. [12] Healthchain, a large-scale health data privacy preserving scheme based on blockchain technology, where health data are encrypted to conduct fine-grained access control. [13] Permissioned blockchain for storing users' wearable device data via the mobile application synced to the cloud server. The Merkle Tree is adopted to ensure scalability and efficiency. The blockchain also stores data from healthcare providers and health insurance companies. Users (data owners) can control access from the organizations with channeling. [14] Storing encrypted keywords on Ethereum blockchain for searching their related EHR on the cloud server. The data provider encrypted EHR before storing it on the cloud server. The cloud server will re-encrypt the EHR before sending it to the data requester after getting the patient (data owner) authorization. [15] proposed a framework developed from Ethereum blockchain with role-based access mechanism integrated with off-chain storage developed from IPFS technology to solve the blockchain scalability problem. [16] presents an implementation using Ethereum blockchain in a real data sharing scenario on a mobile app with Amazon cloud computing. From [13], the blockchain type was permissioned blockchain which with some additional configurations was similar to the type of consortium.
From the comparison stated in Table 3, the other previous research systems have some limitations. Our system provides more aspects which are consortium blockchain-based, using actual medical data, accessible via the mobile application, and decentralized access.
Below we summarize the contribution of our work to this area of research under the headings Actual Medical Data, Mobile Application, and Decentralized access.

3) ACTUAL MEDICAL DATA
During the development of the blockchain extensions to the NU-MED system, we used real data from 157 hospitals to develop the blockchain system for patient EHR storage. We used real data because we were aware of the real problems of data collection from various sources with its high risk of data error. Collecting the data storage formats of each hospital enabled us to appropriately modify our data collection structure and enabled us to write the data into the blockchain system in a consistent and correct format.

4) MOBILE APPLICATION
The Mobile Application is designed to be used by all the parties to a patient visit: the patient, perhaps the triage nurse, and the consulting doctor, all of whom can immediately retrieve patient information via the Mobile Application. Also, patients can do the same independently. This is the flexibility provided by the system for simplifying contacts between patients and hospitals and enables continuity of medical information and continuity of medical service, both highly desirable factors.

5) DECENTRALIZED ACCESS
Our objective was to provide a decentralized storage structure to ensure the safety and security of patient information. This was achieved by the implementation of the blockchain system with multiple nodes. As indicated above, those blockchain nodes could be both physically and virtually stored at each hospital, but in our system, we have 4 blockchain nodes stored on separate physical servers.

6) BLOCKCHAIN TYPE AND BLOCKCHAIN-BASED
The decision to use blockchain technology was based on our perception of the need for a high level of security and safety for medical data, processed with a robust and efficient system that was available to appropriate interested parties on an Anywhere / Anytime / Anydevice basis with inherent safeguards to protect patient privacy. Prior work, such as cited above, that demonstrated blockchain technology as a highly secure technology, suitable to meet high-level data storage security requirements, convinced us that a blockchain solution was required. With the consortium blockchain, the data will be distributed to their trust authorities which enables more tamper-proof data storage and a high level of data integrity.

7) ESSENTIAL FACTORS FOR A NATIONWIDE ROLL-OUT
It is our hope and ambition that this system will one day be rolled out as the nationwide eHCS in Thailand. This implies the possibility of more than 3,000 hospitals and medical centers participating in the network. We are confident that the technology used in this would be fully able to handle that number of hospitals and ensure fast, error-free communications and data transmission.
However, the technology is only part of the requirements for such a system. Basic factors such as ease of implementation, ease of installation of the web agent, the ease with which the web agent can be configured for a new installation, the ease of providing updates to the web agent software, and the ease with which decisions by any hospital to change their internal patient information system to other hardware or another software package, can be accommodated, must be considered.
For installing the web server, The Raspberry Pi computeron-a-board with the appropriate software would be installed on systems in smaller hospitals with less IT expertise, and so can be couriered to the hospitals for a simple 'plug-in' action. For larger hospitals with more sophisticated IT configurations and more expert IT personnel, the implementation can be done remotely as a software package installation process. One simplifying factor is that some 60% of hospitals in Thailand run the HosXP package in Linux (CentOS) so the same web agent can be remotely installed on that majority of systems. A further 25% run the JHCIS open source The users' evaluation was collected from 143 medical, nursing and paramedical personnel, including 2 specialist physicians, 7 family medicine physicians, 28 nurses from different hospitals, 82 nurses from sub district health promotion hospitals, and the other 24 medical personnel.

V. SECURITY ANALYSIS A. ACCESS CONTROL FROM SYSTEM ADMINISTRATORS
This can be considered as the very first level of security. All of the participants (medical personnel) have to sign a formal document with the policy for registering in the system.
The administrators take care of the registration process. They check through each individual and each participant has to be with the administrators throughout the process of registration. This ensures only authenticated participants can join the system.

B. PRIVACY OF DATA
The medical personnel need permission to access patient data and patients have to sign an official document if they want to authenticate them to access their data.
Also with the help of the Smart Contract, only authenticated users can access the data on the blockchain. All transactions will be checked or validated. If there is an invalid or malicious transaction from unknown sources or any third parties, the system will reject this transaction and not perform any further processes. Furthermore, no one can change the smart contract stored in the EVM within the decentralized network.

C. CONFIDENTIALITY OF DATA
All patient data in the blockchain is stored in encrypted form using the AES256 encryption algorithm, and never leaves the blockchain system unencrypted. The data key for encryption/decryption is stored in the AWS KMS with S3. This increases the security levels of the system.

D. MANAGING CRYPTOGRAPHIC KEYS WITH AWS KMS AND S3
The data key is stored in the AWS KMS along with the S3. Those services are governed by hardware security modules validated under the Federal Information Processing Standard (FIP) 140-2. The key is stored securely in the AWS environment and can only be accessed by the AWS credentials. The key is also trackable on its usage.

E. INTEGRITY OF DATA
The patient data needs to always be intact throughout the decentralized system. Data Integrity is one of the blockchain characteristics due to its data structure with the hash algorithm that creates all blocks cryptographically linked and its distributed peer-to-peer network of nodes and consensus mechanism to maintain the data integrity.

F. SECURE SEARCHING
The primary key for searching patient information from the blockchain is stored in a cryptographic hash form. The personnel who performs searching only knows the original value of a patient's PID. The salt key is also combined with the PID to make the resulting hash value to be more complex and unpredictable because the hash(PID) is already extremely complex and if the salt is added, the hash(PID+salt) will be even more complex. The salt key is also stored securely in the AWS KMS. The hash makes the patient data unidentifiable. This combination of unidentifiable data and encryption of the data increases the complexity and security levels.

VI. CONCLUSION
The Internet of Health Care Systems (IoHCS) integrates the blockchain concept to tackle problems that are inherent in centralized storage systems, and to ensure secure sharing of patient data among participating hospitals in the network. There were 3 primary factors that needed to be considered in the development. First, data transmission and processing must be secure at the highest level along with data storage. Second, the variety of different internal hospital patient information systems must be supported by our proposed system. Third, our system must efficiently cater for a large number of participants in the network.
The Central Server has been designed for storing patient information as a buffer before sending it to the blockchain via the Application Programming Interface (API). For each participating hospital, we have an agent installed in order to retrieve patient data from their internal hospital information system. Message Queueing Telemetry Transport protocol (MQTT) is adopted for communication between machines (internal hospital information systems and agents). The blockchain has been developed on the Ethereum platform with the Proof-of-Stake as the consensus mechanism. The blockchain is for storing the 10 most recent records as a summary derived from all information retrieved from all hospitals at which the patient has presented, in fully encrypted form. The blockchain Smart Contract has been developed in the Solidity language to ensure that only authenticated medical personnel can access the data on the blockchain. The Smart Contract is accessible via the API with help from web3.js JavaScript library. The Amazon Web Service: Key Management System (AWS KMS) is adopted for storing data key and salt key for data encryption and indexing. Only authenticated users can access these keys via AWS credentials. The mobile application has been developed for medical personnel to access patient data for diagnosing and performing a further treatment.
From comparison with some related works and users' evaluation in the GENERAL DISCUSSION section, our proposed system provides greater functionality than any other eHCS identified. From the SECURITY ANALYSIS section, our system has achieved the first factor of the 3 primary factors of concern in the development specification that addressed the security of data transmission, data processing and secure data storage. The other two specified requirements, that of handling the variety of Hospital Information Systems (HIS), and maintaining network timeliness with a large number of participating hospitals, the software agent meets these requirements, with the help of MQTT protocol.
Furthermore, computerised HIS have increasingly replaced the traditional method of storing patient information which relied on paper-based records stored locally at the health provider's premises. Notwithstanding this move towards computerisation, information retrieval remains challenging, systems are prone to data loss and are often insecure with VOLUME 9, 2021 no backup data in the case of loss, and subject to long-term storage issues such as physical deterioration and physical damage although CD and DVD storage has solved this problem, if used.
In the IoHCS, patient information is maintained in electronic form, secured in the blockchain, and able to be accessed on mobile devices and shared among participating hospitals. In the development activity enhancing the original eHCS, the EHRs for 8,578 patients were received from 157 hospitals using Message Queueing Telemetry Transport or MQTT protocol: the completed system has been installed at 350 hospitals at the time of writing.
The technology was integrated with the mobile application to enable easier access to the patient information. offering simple and fast searching on an Anytime / Anywhere / Anydevice basis by the patient or authorized hospital staff. In addition, Key Management Service (KMS) from Amazon Web Services (AWS) was used for securing the search through the mobile application.
The blockchain technology, has overcome the challenges to confidentiality, privacy protection and secure storage and handling faced in eHCSs reported in other published systems. The requirement for a high-speed, ultra-efficient processing system with universal networking connectivity has also been met, as has the need for a 'canonical' interface to the wide variety of HISs.
We are confident that all three challenges have been met by our use of imaginative, State-of-the-Art blockchain and internet communications technology and, when called upon in the future, would perform efficiently as a nationwide integrated health care system. Applying the terminology of an Internet of Health Care Systems also implies the use of the terminology of an Internet of Special Things as an enhancement to the existing concept of the IoT.
This system is ready to be rolled out nationwide given the technical sophistication coupled with ease of installation and use, able to network the thousands of hospitals and medical centers that this implies.
SUPARAT YONGJOH received the B.Eng. degree in computer engineering from Naresuan University, Phitsanulok, Thailand, in 2016, where she is currently pursuing the Ph.D. degree in computer engineering. She has experienced in mobile application development. She is interested in the integration of the IoT and blockchain, augmented reality, virtual reality, and mixed reality, A.I., and game development. ROY I. MORIEN received the bachelor's degrees in business (corporate law and corporate administration, and management and accounting), the M.I.S. degree (Hons.), and the P.G.Dip. degree (information systems). He had more than 25 years of experience as a Teaching Academic in the areas of computer science, business computing, and information technology, teaching database development, programming, systems analysis and design, and software project management, usually from an agile development/agile programming perspective, and extensive system consulting experience. He has taught extensively in Australia, Singapore, Jakarta, and Hong Kong, as well as in Thailand, since 2006. He is currently an English Language Specialist, an Academic Editor, and a Language Teacher with Naresuan University Graduate School. He has presented at over 40 international conferences and has published eight articles in international journals, two book chapters, a textbook on programming, and an unpublished textbook on agile database development. VOLUME 9, 2021