Applications of Blockchain in Healthcare [1st ed.] 9789811595462, 9789811595479

Citation preview

Studies in Big Data 83

Suyel Namasudra Ganesh Chandra Deka   Editors

Applications of Blockchain in Healthcare

Studies in Big Data Volume 83

Series Editor Janusz Kacprzyk, Polish Academy of Sciences, Warsaw, Poland

The series “Studies in Big Data” (SBD) publishes new developments and advances in the various areas of Big Data- quickly and with a high quality. The intent is to cover the theory, research, development, and applications of Big Data, as embedded in the fields of engineering, computer science, physics, economics and life sciences. The books of the series refer to the analysis and understanding of large, complex, and/or distributed data sets generated from recent digital sources coming from sensors or other physical instruments as well as simulations, crowd sourcing, social networks or other internet transactions, such as emails or video click streams and other. The series contains monographs, lecture notes and edited volumes in Big Data spanning the areas of computational intelligence including neural networks, evolutionary computation, soft computing, fuzzy systems, as well as artificial intelligence, data mining, modern statistics and Operations research, as well as self-organizing systems. Of particular value to both the contributors and the readership are the short publication timeframe and the world-wide distribution, which enable both wide and rapid dissemination of research output. The books of this series are reviewed in a single blind peer review process. Indexed by zbMATH. All books published in the series are submitted for consideration in Web of Science.

More information about this series at http://www.springer.com/series/11970

Suyel Namasudra · Ganesh Chandra Deka Editors

Applications of Blockchain in Healthcare

Editors Suyel Namasudra Department of Computer Science and Engineering National Institute of Technology Patna Patna, Bihar, India

Ganesh Chandra Deka Directorate General of Training Ministry of Skill Development and Entrepreneurship Government of India New Delhi, India

ISSN 2197-6503 ISSN 2197-6511 (electronic) Studies in Big Data ISBN 978-981-15-9546-2 ISBN 978-981-15-9547-9 (eBook) https://doi.org/10.1007/978-981-15-9547-9 © The Editor(s) (if applicable) and The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2021 This work is subject to copyright. All rights are solely and exclusively licensed by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations. This Springer imprint is published by the registered company Springer Nature Singapore Pte Ltd. The registered company address is: 152 Beach Road, #21-01/04 Gateway East, Singapore 189721, Singapore

Preface

Nowadays, there are many hackers and malicious users over the internet. So, confidential and sensitive data face security and privacy issues. Blockchain is a novel technique to solve these issues, which allows a radical way of transaction among several entities, such as businesses, individuals and machines. Blockchain can be defined as a Distributed Ledger Technology (DLT) that secures and records transactions in a Peer to Peer (P2P) network instead of using single or many servers. Here, each record is saved on many interconnected systems, which keep the identical information. In Blockchain, numerous transactions of value exchange are grouped into several blocks, and each block is linked to the previous block and information is immutably recorded across a P2P network by each block. Bitcoin is one of the well-known applications of Blockchain. Blockchain has many applications, such as healthcare, finance, Internet of Things (IoT), data storage and many more. Health information about any patient is very critical, and currently, health records are saved in the databases controlled by individual user or organization or large groups of organizations. As there are many malicious users, these information are not shared with other organizations due to security issues and chance of the data being modified or tampered. Blockchain can be used to securely exchange healthcare data, which can be accessed by organizations sharing the same network, allowing doctors and practitioners to provide better care for patients. The key properties of decentralization, such as immutability and transparency improve healthcare interoperability. As estimated by BRSofTech (www.brsoftech.com), the healthcare market of DLT will be worth $829 Million by 2023. This book discusses the core concepts of Blockchain as well as its applications in healthcare. Chapter 1 discusses healthcare data management by using Blockchain technology. Chapter 2 is an analytical study to modernize the healthcare industry by using Blockchain technology, while Chap. 3 deliberates upon security, privacy, trust management and performance optimization of Blockchain Technology. Chapter 4 discusses securing healthcare data by using Blockchain. Chapters 5–7 deal with the case studies of Blockchain in healthcare by using different novel technologies, such as IoT. Chapter 8 represents a supply chain process to detect fake drug by using Blockchain technology. Chapter 9 is a study on Blockchain technology to accelerate v

vi

Preface

research in life sciences. Finally, Chap. 10 concludes the book by discussing challenges and future work directions in healthcare data management using Blockchain technology. Patna, India New Delhi, India

Suyel Namasudra Ganesh Chandra Deka

Contents

1

Healthcare Data Management by Using Blockchain Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Soeren Bittins, Gerhard Kober, Andrea Margheri, Massimiliano Masi, Abdallah Miladi, and Vladimiro Sassone

2

Modernizing Healthcare by Using Blockchain . . . . . . . . . . . . . . . . . . . . Mario Ciampi, Angelo Esposito, Fabrizio Marangio, Mario Sicuranza, and Giovanni Schmid

3

Security, Privacy, Trust Management and Performance Optimization of Blockchain Technology . . . . . . . . . . . . . . . . . . . . . . . . . Mayank Swarnkar, Robin Singh Bhadoria, and Neha Sharma

1

29

69

4

Securing Healthcare Data by Using Blockchain . . . . . . . . . . . . . . . . . . Meenu Gupta, Rachna Jain, Meet Kumari, and Gaurav Narula

93

5

Secure and Decentralized Management of Health Records . . . . . . . . 115 Subramanian Venkatesan, Shubham Sahai, Sandeep Kumar Shukla, and Jaya Singh

6

IoT-Based Healthcare Monitoring Using Blockchain . . . . . . . . . . . . . . 141 Monireh Vahdati, Kamran Gholizadeh HamlAbadi, and Ali Mohammad Saghiri

7

Healthify: A Blockchain-Based Distributed Application for Health care . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Pratima Sharma, Rajni Jindal, and Malaya Dutta Borah

8

Blockchain in Pharmaceutical Sector . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Meet Kumari, Meenu Gupta, and Chetanya Ved

9

Accelerating Life Sciences Research with Blockchain . . . . . . . . . . . . . 221 Wendy Marie Charles

vii

viii

Contents

10 Challenges and Future Work Directions in Healthcare Data Management Using Blockchain Technology . . . . . . . . . . . . . . . . . . . . . . 253 Denis A. Pustokhin, Irina V. Pustokhina, and K. Shankar

Editors and Contributors

About the Editors Dr. Suyel Namasudra is an Assistant Professor in the Department of Computer Science and Engineering at the National Institute of Technology Patna, Bihar, India. Prior to joining the National Institute of Technology Patna, Dr. Namasudra was an Assistant Professor in the Department of Computer Science Engineering at the Bennett University, India. He has received Ph.D. in Computer Science and Engineering from National Institute of Technology Silchar, Assam, India. His research interests include Cloud Computing, Information Security, DNA Computing and Blockchain. Dr. Namasudra has edited 1 book and 25 publications in refereed journals, book chapters and conference proceedings. He has participated in many international conferences as an Organizer and Session Chair. Dr. Namasudra is a member of the Editorial Board and Reviewer of many journals.

ix

x

Editors and Contributors

Ganesh Chandra Deka ISDS is Deputy Director at Regional Directorate of Skill Development and Entrepreneurship, Assam under the Directorate General of Training, Ministry of Skill Development and Entrepreneurship, Government of India. His research interests include NoSQL Database, Blockchain Technology and Bigdata Analytics. He has authored 2 books on Cloud Computing published by LAP Lambert, Germany. He is the Co-author of 4 text books on Fundamentals of Computer Science (3 books published by Moni Manik Prakashan, Guwahati, Assam, India and 1 IGI Global, USA). Till now, he has edited 22 books (7 IGI Global, USA, 7 CRC Press, USA, 4 Elsevier and 4 Springer including 1 International Conference proceeding) on Big data, NoSQL, Blockchain Technology and Cloud Computing in general and authored 10 Book Chapters. He has published 8 research papers in various reputed journals including Elsevier (1) and IEEE (2) and already published around 47 research papers in various IEEE conferences. He is the Editor-in-Chief of the International Journal of Computing, Communications and Networking. He has published 4 Special Issues as Guest Editor in different International Journals, which are indexed in SCI and SCOPUS. Deka has organized 08 IEEE International Conferences as Technical Chair held in India.

Contributors Robin Singh Bhadoria Computer Science and Engineering, Birla Institute of Applied Science, Bhimtal, India Soeren Bittins Fraunhofer FOKUS, Berlin, Germany Malaya Dutta Borah Department of CSE, National Institute of Technology Silchar, Silchar, Assam, India Wendy Marie Charles Life Sciences Division, BurstIQ, Denver, CO, USA Mario Ciampi Institute for High Performance Computing and Networking of the National Research Council of Italy, Naples, Italy Angelo Esposito Institute for High Performance Computing and Networking of the National Research Council of Italy, Naples, Italy

Editors and Contributors

xi

Kamran Gholizadeh HamlAbadi Young Researchers and Elite Club, Qazvin Branch, Islamic Azad University, Qazvin, Iran; Faculty of Computer and Information Technology Engineering, Qazvin Branch, Islamic Azad University, Qazvin, Iran Meenu Gupta Department of CSE, Chandigarh University, Punjab, India Rachna Jain Department of CSE, Bharati Vidyapeeth’s College of Engineering, Delhi, India Rajni Jindal Department of CSE, Delhi Technological University, Delhi, India Gerhard Kober Tiani “Spirit” GmbH, Vienna, Austria Meet Kumari Department of ECE, Chandigarh University, Punjab, India Fabrizio Marangio Institute for High Performance Computing and Networking of the National Research Council of Italy, Naples, Italy Andrea Margheri University of Southampton, Southampton, UK Massimiliano Masi Tiani “Spirit” GmbH, Vienna, Austria Abdallah Miladi Tiani “Spirit” GmbH, Vienna, Austria Gaurav Narula Department of CSE, Bharati Vidyapeeth’s College of Engineering, Delhi, India Denis A. Pustokhin Department of Logistics, State University of Management, Moscow, Russia Irina V. Pustokhina Department of Entrepreneurship and Logistics, Plekhanov Russian University of Economics, Moscow, Russia Ali Mohammad Saghiri Computer Engineering and Information Technology Department, Amirkabir University of Technology (Tehran Polytechnic), Tehran, Iran Shubham Sahai Department of Computer Science and Engineering, Indian Institute of Technology, Kanpur, India Vladimiro Sassone University of Southampton, Southampton, UK Giovanni Schmid Institute for High Performance Computing and Networking of the National Research Council of Italy, Naples, Italy K. Shankar Department of Computer Applications, Alagappa University, Karaikudi, India Neha Sharma Computer Science and Engineering, IPS College of Technology & Management, Gwalior, India Pratima Sharma Department of CSE, Delhi Technological University, Delhi, India Sandeep Kumar Shukla Department of Computer Science and Engineering, Indian Institute of Technology, Kanpur, India

xii

Editors and Contributors

Mario Sicuranza Institute for High Performance Computing and Networking of the National Research Council of Italy, Naples, Italy Jaya Singh Department of Information Technology, Indian Institute of Information Technology, Allahabad, India Mayank Swarnkar Computer Science and Engineering, Indian Institute of Technology (BHU), Varanasi, India Monireh Vahdati Young Researchers and Elite Club, Qazvin Branch, Islamic Azad University, Qazvin, Iran Chetanya Ved Department of Information Technology, Bharati Vidyapeeth’s College of Engineering, Delhi, India Subramanian Venkatesan Department of Information Technology, Indian Institute of Information Technology, Allahabad, India

Chapter 1

Healthcare Data Management by Using Blockchain Technology Soeren Bittins, Gerhard Kober, Andrea Margheri, Massimiliano Masi, Abdallah Miladi, and Vladimiro Sassone

Abstract Electronic healthcare solutions permit interconnecting hospitals and clinics to enable sharing of electronic medical records according to interoperability and legal standards. However, healthcare record data is siloed across hospitals and data sharing processes are unsuccessful in providing accountable audit of the data. Blockchain technology has been successfully applied to support the management of distributed data. Its decentralisation and immutability features can underpin the development of next-generation services for health data sharing. This chapter positions recent blockchain research outcomes within the healthcare legal and technical standard frameworks (e.g. IHE and FHIR). It then presents how blockchain can be applied to healthcare data sharing practices in order to enhance trust with automated provenance tracking and accountable credential verification. The data sharing practices related to international organ transplant processes are used as motivating and application case study. Keywords Blockchain · IHE · eHealth · Provenance · SSI · Organ donation

S. Bittins Fraunhofer FOKUS, Berlin, Germany e-mail: [email protected] G. Kober · M. Masi (B) · A. Miladi Tiani “Spirit” GmbH, Vienna, Austria e-mail: [email protected] G. Kober e-mail: [email protected] A. Miladi e-mail: [email protected] A. Margheri · V. Sassone University of Southampton, Southampton, UK e-mail: [email protected] V. Sassone e-mail: [email protected] © The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2021 S. Namasudra and G. C. Deka (eds.), Applications of Blockchain in Healthcare, Studies in Big Data 83, https://doi.org/10.1007/978-981-15-9547-9_1

1

2

S. Bittins et al.

1.1 Introduction The healthcare domain is one of the pillars of critical infrastructure, as signified through the European NIS directive (European Parliament and the Council (2016)) or the American (Health Insurance Portability and Accountability Act (HIPAA) security rule (Scholl et al. (2008)). Healthcare services are indeed highly regulated in terms of accessibility and cybersecurity. Paired with complementary regulations, for instance the right of access of Art. 15 GDPR or the principle of patient ownership of health data in public health insurance systems, the healthcare domain has to embrace innovative technology to fulfil its obligations towards society. It is therefore not surprising that, for instance, the European Commission prioritises health care for the adoption of an artificial intelligence-based approach (European Commission 2020d) and recognises the need of a common European health data space, focussing on extending and reusing the current exchange of health data aiming at enabling health authorities to take evidence-based decisions (European Commission 2020a). All of this is yet to be achieved, but initial results should be expected by 2022 (European Commission 2020b). What has been materially achieved in the European context is the execution of patients’ rights, such as a comparatively seamless access to their health data throughout the member states ELGA GmbH (2017); Niaksu et al. (2017). However, following the letter of the many applicable laws, the implementation of basic data access tools does not guarantee all health information being available electronically or instantly. The overwhelmingly uncoordinated number of access channels and means of access to health data, such as many health portals, complicate obtaining a complete set of medical information as well as moving health information from one data controller to the next. Consequently, a massive drive of innovation is imposed on the digitalisation of healthcare records and its explicit international interoperability; these innovations can have immediate impact on our lives: we are all patients. Some rapid growth areas of investment in new technology in the electronic health (eHealth) include: (i) treatment of rare diseases (Gulhan 2020), where a fully interoperable health passport (Royal College of Physicians of Ireland 2019) among European Reference Networks would have a tremendous impact on the way patients are treated across the union; (ii) establishment of traceable clinical pathways (Xia et al. 2019), where the analysis of health record data can enhance patient treatment procedures; and (iii) clinical research (Benchoufi and Ravaud 2017), via the application of blockchain technology, can pave the way to a transparent and accountable enforcement of data regulation by enabling secure sharing of clinical data. Blockchain technology is an innovative yet sufficiently established mechanism. It has already proven itself to be able to support the need of heterogeneous sectors with disparate stakeholders through cryptocurrency. Given its pioneering approach, blockchain technology has been object of academic and industrial research,1 with multiple efforts in eHealth (Hardin and Kotz 2019). Initially, the eHealth applications of blockchain have targeted the creation of new data management use cases to 1 See

the HIMSS blockchain in healthcare page (HIMSS 2020).

1 Healthcare Data Management by Using Blockchain Technology

3

start crowdfunding (i.e. creating a financial ecosystem over the selling of cryptocurrencies). The variety of such eHealth cases (Shoeb 2018) has not yet led to a clear impact on the eHealth industry. Blockchain data management solutions are instead emerging to deal with the integration of data silos. In fact, despite many established eHealth interoperability initiatives,2 medical record data is still siloed within hospitals (Miriam 2017). Those silos may increase in dimensions (e.g. encompassing the whole EU continent (European Commission 2019), or the USA (The Sequoia Project 2019)), but interoperability at global scale is not yet a reality. In such a context, the application of blockchain can support the development of sharing practices to overcome the challenges posed by the distribution of data. At the same time, blockchain-based management of healthcare data poses compelling privacy-related questions (Staff 2019). This chapter reports the analysis and design of a blockchain-based architecture for healthcare systems. By building on established international standards for healthcare data sharing (e.g. Fast Healthcare Interoperability Resources (FHIR) and Integrating the Healthcare Enterprise (IHE)), the requirements to drive the development of a blockchain-based architecture for health data exchange are discussed. These requirements are put in practice on a blockchain data sharing architecture featuring automated data provenance and credential verification. The presented high-level architecture is then applied to organ transplant scenario in order to enhance transparency and accountability of current practices. The current legal frameworks are discussed to contextualise the blockchain challenges and opportunities with respect to the emerging needs of the health sector. Structure of the Chapter. Section 1.2 introduces the technology underpinning the management and sharing of health information. Section 1.3 reports on how blockchain complements and innovates such foundational technology. Section 1.4 outlines a healthcare case study on organ transplant. Section 1.5 presents the blockchain architecture for enhanced healthcare services, its specialisation on the case study and an implementation roadmap. Section 1.6 discusses upon legal aspects and patient centricity in deploying blockchain-based services. Section 1.7 touches upon future work and concludes.

1.2 Electronic Health Records Research on innovative and more efficient ways to share medical data among clinics and hospitals started in the 1960s (Kim et al. 2019). After several decades of research efforts and results, techniques and technologies have been consolidated. Hence, standardisation organisations started to build interoperable services for the exchange of medical data. However, after many years of standardisation efforts, we 2 See the IHE (Integrating the Healthcare Enterprise 2020), HL7 (Health Level 7 2020), DICOM (The

Digital Imaging and Communications in Medicine (DICOM) 2020), SNOMED (SNOMED CT 2020) standardisation organisations.

4

S. Bittins et al.

are far from achieving global Electronic Health Record (EHR) sharing: data is still locked in silos (Miriam 2017). It is also worth noting that healthcare return of investments is typically over a multiyear period. For example, the design of the European sharing of patient summary started in 2008, with first production deployment in 2018. Indeed, the healthcare context requires incremental innovation so not to affect already existing services. In the following, the EHRs and relevant standards are introduced (Sect. 1.2.1). Then, the main challenges of dealing with data silos are discussed (Sect. 1.2.2), followed by the main international initiatives in this context (Sect. 1.2.3).

1.2.1 Interoperability and International Standards Integrating the Healthcare Enterprise (IHE) (Integrating the Healthcare Enterprise 2020) is an initiative by healthcare professionals and major industries to improve the way computer systems in health care share information. IHE promotes the coordinated use of established standards to address specific clinical needs in support of optimal patient care. In the 1990s, electronic health care was a set of technologically isolated areas. Professionals started to cooperate and build international standards for information encoding. Initiatives such as Digital Imaging and Communications in Medicine (DICOM) (The Digital Imaging and Communications in Medicine (DICOM) 2020) and Health Level 7 (HL7) (Health Level 7 2020) were launched to define the standards for radiological images and electronic medical records, respectively. Despite the global adoption of these standards, the development of infrastructures for sharing healthcare information among hospitals, clinics and laboratories did not begin until 2001, when IHE was established. With the support of industry, academia and public bodies, IHE aimed to provide a governance model for building the infrastructure to securely share medical records. Notably, IHE does not provide standards. Yet, it selects standards using specific criteria (e.g. market penetration, security, support, specific use cases) and further profiles the standards to establish interoperability and security by-design. Like any other software assets, standards have to be maintained, improved and patched. The worldwide span of IHE permits governing the adoption of the standards by different vendors and within different countries, therefore preventing the lack of interoperability among organisations from hindering patients’ safety. Figure 1.1 illustrates the IHE governance model (Integrating the Healthcare Enterprise 2020). For each domain,3 clinical use cases focussed on interoperability problems are submitted to a cohort of technicians which, after public discussions, select the standards that could potentially address the problems. These standards are constrained into a profile, a specific set of functionalities and their implementation details. 3A

domain is an application context of IHE profiles. At the moment of writing, IHE is composed by 11 domains, including eye care, cardiology, quality, research and public health.

1 Healthcare Data Management by Using Blockchain Technology

5

Fig. 1.1 IHE process

The profiles are grouped according to their domain into technical frameworks and, when published, are implemented by vendors. Connect-a-thons events are organised by IHE to experimentally validate the interoperability of the implementation of the profile between vendors’ products. Information on successfully integrated products is released to the public and typically used by health sector policymakers, IT architects and project managers to use and create tenders. The IHE methodology is endorsed by (i) the European Commission (Decision 2015/1302 and Recommendation 2019/800) as the European Electronic Health Record Exchange Format; (ii) the World Health Organization with the guideline: “Recommendations on Digital Interventions for Health System Strengthening” (World Health Organisation 2019); and (iii) the USA by the Department of Health and Human Services Interoperability Standards Advisory (Official Website of The Office of the National Coordinator for Health Information Technology (ONC) 2020). Cross-Enterprise Document Sharing. The core of the IHE IT infrastructure is the Cross-Enterprise Document Sharing (XDS) model. Logically, the XDS model defines (i) a registry containing searchable meaningful (meta)data of documents; (ii) a repository of where the documents are physically stored; and (iii) consumers and sources of the (meta)data and documents. Figure 1.2 shows the interactions between the XDS profile actors. Interactions, known as transactions, define the messaging between actors of the architecture. XDS is an IHE profile upon which secure medical document exchanges can be defined. XDS, together with the IHE security architectures, defines the technical and integration requirements for laboratories and hospitals, for both facility and

6

S. Bittins et al.

Fig. 1.2 Healthcare document sharing with XDS

national document exchanges. The key concept pursued by XDS is the so-called affinity domain (IHE 2019): all enterprises participating in the document exchange have agreed to work together using a common set of policies and share a common infrastructure.

1.2.2 Challenge: Integrating Data Silos Despite the results achieved in providing technological interoperability, the management of EHRs is characterised by numerous data silos distributed across organisations (e.g. hospitals and laboratories). This is mostly caused by the variegate legislations and policy requirements. In Europe, with the introduction of the European Interoperability Architecture (European Interoperability Reference Architecture (EIRA) 2020) that takes into account legal and political interoperability aspects as well, this problem is mitigated and a process towards a continental interoperability is in place (Electronic cross-border health services 2020). The USA has a similar initiative (The Sequoia Project 2019). However, patients have the right to move in order to seek, e.g., optimum treatment or different working conditions. Therefore, the sharing of EHRs is a key requirement to cope with the mobility of patients while offering the expected level of health services. The definition of data silos varies from hospitals to regions. The higher the request of mobility is, the more the eHealth infrastructures have to evolve to support the demand. Mobile devices are increasing this tendency, as patients may access their data in different legal and technical contexts. IHE, together with the Personal Connected Health Alliance (Personal Connected Health Alliance 2020) (a standardisation development organisation devoted to the creation of standard methods for medical devices), is applying XDS-based scenarios also to mobile devices. Technically speaking, a silo is usually identified as a single XDS affinity domain. In order for organisations located in different affinity domains to communicate, IHE

1 Healthcare Data Management by Using Blockchain Technology

7

introduced the concept of community: an identifiable set of federated healthcare facilities that cooperate to share data exposing a single point of contact, i.e. the CrossCommunity Access (XCA) community gateway (IHE 2019). The gateway is in charge of implementing the functionalities to achieve syntactic and semantic interoperability across domains. The principled use of gateways allows communities to securely share medical records. It however increases the complexity required to follow the secondary use of data and to enforce data quality. Challenge 1 Discovering the origin, and the full chain of custody of a medical data handled by clinics spread across different siloed communities In such distributed scenario, establishing trust across communities is a complex issue. At the same time, outsourcing medical analysis (e.g. tissue and blood analysis) to other laboratories is a common task for hospitals. Third-party accreditation can guarantee trust on the medical processes carried out by each party. However, to trust document sources and exchanged identities and credentials, a set of validation processes must be in place. Challenge 2 Recognising and validating the credentials of the parties originating or exchanging medical data across different siloed communities As it is will be illustrated, the principled application of blockchain, together with IHE standards, allows to address these challenges.

1.2.3 Healthcare Initiatives Worldwide Several national initiatives worldwide use IHE, including XDS and XCA, to manage and exchange healthcare information. Some of them are outlined below. The Austrian nationwide electronic health record sharing programme, ELGA (Elektronische Gesundheitsakte) (ELGA GmbH 2017), is built upon IHE profiles and connects regions across the country. Each hospital, doctor, pharmacy and care facility having treatment relationships are connected and share medical data electronically. ELGA is a distributed system, where each region is identified by an XCA gateway acting as trust broker (Masi and Maurer 2010). The Albanian Nationwide Electronic Health Record programme started in 2014 (Niaksu et al. 2017). Starting from a fragmented existing health information system of poor quality and with no IT expertise, it successfully delivered a productionstate implementation in 2016. Similarly to the Austrian project, Albania uses XDS and XCA over the public Internet to share records from the centralised data centre located in the premises of the Ministry of Health, with other 79 organisations over the country. It is worth noting that in this model the centralised data centre has a view of different communities, including the European Space: Europe is seen as yet another community to share data with, enabling Albanian patients to travel across Europe potentially having access to their health data.

8

S. Bittins et al.

Seamless support for patient mobility across Europe is the aim of the panEuropean exchange of patient summaries. The European Commission started a plan to establish the cross-border exchange of patient summaries and e-prescriptions among member states (including Albania, Turkey, Switzerland and other stakeholders) in the early 2000s. The first project that laid down the technical specifications was the European Patients Smart Open Services (epSOS) project. With 25 member states participating and more than 50 beneficiaries (Cross-border health project epSOS 2014) (mostly governmental), epSOS was carried out between 2008 and 2014 and set up 16 pilots that exchanged test data. In detail, the European architecture works similarly to the systems illustrated above: each member state has an XCA gateway, named National Contact Point for eHealth (NCPeH) (OpenNCP Community Home 2020). The trust is direct and brokered: each hospital trusts only its own NCPeH, and every NCPeH is trusted against the others. By using the NCPeH-to-NCPeH communication channels, the member states can locate the data of a patient in their home country and use them in a remote member state. The NCP network is under production, and it is governed by the eHealth Digital Service Infrastructure (European Commission 2019) to coordinate activities among member states. In the USA, the introduction of the Healthcare Insurance Portability and Accountability Act(HIPAA) (Centers for Medicare & Medicaid Services 1996) of 1996, and the Health Information Technology for Economic and Clinical Health (HITECH) (HITECH Act Enforcement Interim Final Rule 2009) Act of 2009, established the legal foundation for eHealth services. Many initiatives started to address the data silos challenges; e.g. the BlueButton (Mohsen and Aziz 2015) had the aim to allow patients to download all their medical history onto removable media. Despite the remarkable innovation, the solution was error-prone and lacking usability (i.e. patients are required to bring the removable media along). In 2011, the first implementation of the Nationwide Health Information Network (NwHIN) was made available (Bouhaddou et al. 2012; Kuperman et al. 2010) to enable seamless healthcare document sharing across the USA. Similarly to the European Architecture, it is a fully distributed network where each NwHIN community is an XCA community. Given the similarities among the two projects, the European Commission and the Department of Homeland Security started the Trillium Bridge project (Trillium Bridge II 2020), whereby two gateways implement the necessary semantic translations to achieve interoperability between the European and North American healthcare systems.4 Therefore, IHE is a set of worldwide technical and organisational guidelines widely applied in production in many countries and unions.

4 This

is now achieved by using the International Patient Summary (IHE Developing Integration Profile for the International Patient Summary 2020).

1 Healthcare Data Management by Using Blockchain Technology

9

1.3 Managing Distributed Health Data with Blockchain Blockchain technology has been successfully employed in scenarios with highly distributed data (Chang and Chen 2020; Hardin and Kotz 2019; Krishnan et al. 2020; McGhin et al. 2019; Bhabendu et al. 2019; Namasudra et al. 2020; Wang et al. 2019). The integrity and immutability guarantees are ensured by decentralised blockchain systems and allow building trust in data exchanged between distributed parties, without requiring any centralised entity. Blockchain builds such trust relying on decentralised means that permit addressing the challenges of health data exchange across siloed communities: assessing data quality and certifying data sources. Decentralised Data Provenance (Margheri 2018; Margheri et al. 2020) offers blockchain-based functions to collect, store and retrieve annotations on data creation and manipulation, e.g. describing how EHR data has been produced. Self-sovereign identity (SSI) (Mühle et al. 2018; Andrew and Drummond 2018) is a blockchain application that enables entities (either users or applications) to securely control identity claims over any number of authorities, e.g. multiple organisations from different countries.

1.3.1 Assessing Data Quality with Provenance Provenance is a wide field of data management, focussing on the collection, storage and usage of metadata describing, e.g. creation, exchange and update of some data of interest. Therefore, the role of provenance in data management lies in supporting the assessment of the quality of data, e.g. presenting semantically connected metadata for the attribution of sources. The definition of provenance standard has been the target of substantial efforts in the last decades. The W3C standard PROV (Missier et al. 2013) is a widely accepted standard for provenance management. Its development started in the Web Science community, but it is nowadays applied in multiple contexts, including health care.5 PROV follows an ontological approach to represent concepts, and it allows the creation of highly expressive provenance annotations, e.g. based on casual and temporal relationships of the activities on the monitored data, in a convenient way. In practice, tracking the provenance of some data corresponds to building a graph of semantically connected concepts that describe entities (i.e. the data of interest), activities (i.e. the operation carried out on the data) and agents (i.e. who performed that operation) involved in the monitored business process. Data provenance is of paramount importance in ubiquitous and federated systems (Chang and Chen 2020; Bhabendu et al. 2019; Wang et al. 2019)—e.g. IoT, supply chains and health care— where data created or modified by a logically stand-alone entity (e.g. a hospital in a siloed community or a local sen5 See

the HL7 FHIR standard that uses a mapping to PROV to embody provenance information in FHIR resources.

10

S. Bittins et al.

Fig. 1.3 Decentralised health provenance

sor in distributed sensor network) is key assets for offering a trustworthy service by other system entities. In healthcare, provenance is defined by the US Office of the National Coordinator for Health Information Technology, “attributes about the origin of health information at the time it is first created and tracks the uses and permutations of the health information over its lifecycle” (Data Provenance Glossary 2016). Thus, provenance can offer the means to reconstruct the clinical context within which medical documents were created or updated. Figure 1.3 illustrates how blockchain can be applied and integrated with existing healthcare systems to introduce a transparent provenance management (Margheri et al. 2020). The architecture integrates with XDS to annotate all XDS transactions (i.e. all exchanged medical documents) with provenance documents written in PROV. The creation and retrieval of the provenance documents are fully transparent and automated. By introducing the so-called PROV Proxy, all the XDS read (Query and Retrieve) and write (Provide and Register) document transactions are intercepted and manipulated. When PROV Proxy intercepts write transactions (i.e. the “Provide and Register” arrow in Fig. 1.3), it collects the metadata of the document (e.g. author, hash, locality, action performed) and triggers the creation of the corresponding PROV document. The PROV documents so generated are based on standard templates compiled by a smart contract and stored on the blockchain. The use of templates is advocated to tailor provenance annotation to the needs of each project (Curcin et al. 2017), e.g. to enable ontology-based processing and reasoning. The provenance documents stored on a blockchain do not contain any patientrelated medical information. Instead, the blockchain smart contract only uses hash indexes that correspond to the canonicalised signatures of the medical documents. It follows that when the PROV Proxy intercepts a read transaction (i.e. the “Query and Retrieve” arrow in Fig. 1.3), it computes the hash index of the contained document

1 Healthcare Data Management by Using Blockchain Technology

11

and uses it to query the blockchain to retrieve the corresponding PROV document. Notably, these provenance functionalities are controlled and regulated by patientinformed consent authorisation policies of XDS. In this way, provenance documents can be linked to a patient’s medical document only if the consumer of the document (say a doctor) is entitled to retrieve the said document. Therefore, this blockchain architecture enhances siloed communities with automated creation and retrieval of provenance information to attach clinical context to exchanged patients’ records. These functionalities contribute to addressing Challenge 1 above by reconstructing the full medical documents’ custody chain.

1.3.2 Leveraging Self-sovereign Identity Self-sovereign identity (SSI) is a novel paradigm which allows organisations and users to create and share identity traits in a controlled and interoperable way. Blockchain facilitated the realisation of SSI by implementing so-called (DID), a persistent, immutable “globally unique identifier that does not require a centralised registration authority because it is registered with distributed ledger technology” (Reed et al. 2020). DIDs are used to refer uniquely to Verifiable Identity Claims (e.g. a diploma, a university degree or the affiliation to an organisation) that are linked to a subject (i.e. a verifier). By using cryptographic techniques, the issuer of a claim (e.g. a university) certifies on the blockchain the claim with the verifier (i.e. the claim is hashed and linked to the subject’s identifier). This allows any authorised users to assess the integrity of the claim by checking the list of verifiable claims stored on the blockchain (Windley 2016). The concepts of SSI and DID are the basis of the European Blockchain Service Identifier (EBSI) (European Blockchain Service Infrastructure 2020). EBSI, together with other specifications—such as eID, eSignature and eDelivery—forms the European Commission “Building Blocks”: reusable set of specifications, software and services aimed at facilitating the delivery of high-quality, interoperable and secure digital public services across the EU borders (European Interoperability Reference Architecture (EIRA) 2020; Pavleska et al. 2019). Figure 1.4 shows the architecture overview of the EU SSI framework. The EBSI blockchain is composed with the eID block which implements the electronic IDentification, Authentication and trust Services (eIDAS).6 Regardless of the country, any EU identity can use the EBSI via the eIDAS bridge. Connecting the EBSI with eID creates the required trust among issuers and verifiers. Verifiers’ credentials are certified as signed DID documents which contain the public keys of the issuer and the verifier’s eID identity. Therefore, in the healthcare context, by building on the SSI infrastructure, the deployment of community-wide eHealth services relies on standard subjects’ information (i.e. identity traits) that ease the administrative burden of credentials and 6 See

the eIDAS regulation EU 910/2014.

12

S. Bittins et al.

Fig. 1.4 European self-sovereign identity

source validation for healthcare bodies and patients. More specifically, integrating SSI with XCA gateways allows to address Challenge 2 by introducing a distributed mechanism to verify, in an automated manner and with confidence, the credentials of, say, laboratories and professionals across communities.

1.4 A Healthcare Data Sharing Case Study: Organ Transplant Data sharing has become fundamental to enable new and innovative healthcare services. Data sharing has indeed enabled ubiquitous care services, from remote monitoring to multi-country healthcare networks. Development of such networks for organ donation and transplant processes are recent and prominent initiatives. Organ donation is when a person consents to remove legally organs of theirs, either lively (by donating a portion of an organ like liver or kidneys), or in case of death (deceased donation), by the next of kin. Donated organs are given to someone in the need of transplant, eventually saving their lives. Organs are donated mostly from deceased donors (4 out of 5). In case of a deceased donor died of accidental causes (e.g. a car accident), a prompt response is required:

1 Healthcare Data Management by Using Blockchain Technology

13

the first responder shall immediately inform the social services about a potential organ donation, so that they can organise a safe donation without having the risk to deteriorate the tissue or the organ. Efficiency is therefore crucial. Determining whether someone is a candidate for organ donations depends on a multitude of factors. The purely medical indicators are well documented with robust procedures in place, backed by a stable legal framework and frequent significant legal adjustments to assure a transparent, fair and successful transplant. However, before the medical procedures can be properly invoked, first responders have to quickly and safely identify someone’s qualification and determine authorisation for organ donation. Although organ donation is an essential treatment, it suffers from severe challenges (Reza and Kenari 2014), in particular organ shortage. Indeed, transplant waiting list is outstanding; e.g. in Germany (EurotransplantWeb Page 2020), more than ten thousand patients were in a transplant waiting list in 2017, and only one-third of them received an organ donation, and similarly in 2018 (Weigand 2018). In order to maximise the possible match between donors and receivers, international organisations such as Eurotransplant (EurotransplantWeb Page 2020) and BaltTransplant (Rosental et al. 1997) were started. For instance, the Eurotransplant network coordinates organ transplants across Austria, Belgium, Germany and other East European countries. Continuous interactions between accredited laboratories dramatically help reducing the receiver’s waiting list. However, laboratories face organisational challenges: they have to show continuous compliance with the standards, and they have to demonstrate transparency on their operations, to maintain trust in the process (Almassi et al. 2014; Schulte et al 2018). On the other hand, the development of such pan-European data sharing initiatives has magnified interoperability and privacy challenges. Enabling secure, yet accountable and transparent exchanges of healthcare data across facilities located in different countries can support the improvement of the current transplantation processes. Transplant Standards: the European Federation for Immunogenetics (EFI)/ American Society for Histocompatibility and Immunogenetics (ASHI). The basic rules for coordination and cooperation of transplant laboratories are set by international standards. In Europe, the European Federation for Immunogenetics (EFI) identifies “minimal criteria, which all histocompatibility laboratories must meet if their services are to be considered acceptable” (EFI 2017), which are then used for laboratory accreditation and enrolment in transplantation networks, e.g. the Eurotransplant. Similarly, in the USA, the American Society for Histocompatibility and Immunogenetics (ASHI) defines analogous rules. For the sake of presentation, only the EFI rules are commented. The EFI guidelines are paper-based, and the laboratory accreditation programme consists of on-site and documental inspection of conformity with the guidelines. At the time of writing, over 260 laboratories are accredited in 36 countries. Furthermore, as organs and stem cells are exchanged across national boundaries (Harmer et al. 2018), a continuous improvement programme is in place across the transplant network. Such regulatory requirements prompt the need to have full control on the

14

S. Bittins et al.

custody chain of documents, even during interactions and collaboration with third parties located in different countries. Organisation part of multi-country transplant networks must meet all these requirements. This requires high coordination and cooperation to share data with all network members. These processes are complex and contain aspects which are not yet digitalised: attesting trust and reviewing paper- and electronic-based documents, showing compliance to the standards and sharing audit results. These are examples of tasks that can be automatised by using blockchain technology as a trustworthy mechanism to securely share results without the intervention of any trusted third party, yet guaranteeing the necessary transparency and accountability. In Sect. 1.5.2 is shown how these case studies can be implemented by relying on a blockchain architecture for enhanced data sharing.

1.5 Blockchain for Health Data Sharing To overcome the distribution of healthcare data across data silos, data is made available through the EHR approach. The use of IHE profiles enabled an interoperable health information exchange, from the syntactic to the semantic level. It is not only the preferred approach to share data among the different actors of a community, but it became also the de facto solution to integrate distant communities. In addition, many countries rely on it to build their national infrastructure. Built upon well-established IHE Integration Profiles, these infrastructures are on production and allowed to create secure and resilient nationwide healthcare exchanges. The usage of these Integration Profiles, which rely on mature technical standards, ensures the architecture sustainability. However, the advent of blockchain technology allowed to envision new possibilities. More specifically, blockchain can provide the decentralised means to enable secluded healthcare organisations operating in data silos to achieve not only interoperable but also trustworthy exchanges of medical documents. Blockchain acts as a decentralised, yet controlled repository of information to build trust in the interactions among organisations, e.g. in collaborative cooperation across countries such as the Organ Donation European networks. Our proposal of a healthcare blockchain integrates provenance tracking and SSI credential management. The solution is offered ‘as-a-service’ and can be deployed in multiple healthcare contexts, because of its transparent integration with the XDS document management systems. Below, it is reported the main requirements that should steer the design and deployment of a blockchain system for health care (Sect. 1.5.1). Then, it introduced our blockchain architecture (Sect. 1.5.2) and commented on its application to organ transplant (Sect. 1.5.3).

1 Healthcare Data Management by Using Blockchain Technology

15

1.5.1 Requirements for an Healthcare Blockchain Blockchain is being explored for healthcare applications by both academia and industry (Hardin and Kotz 2019; Krishnan et al. 2020; McGhin et al. 2019). When dealing with exchange of medical documents, the set of legal and technical requirements is substantial. Therefore, in order to address the need of enhancing document exchanges across siloed communities, it is needed to set precise requirements that take into account the key challenges and stakeholders: the role of privacy, the patients and the systems already deployed. • Privacy-aware: The data managed by the blockchain should provide tamper-proof evidence of the integrity of the represented healthcare concept (e.g. credentials or documents), yet it must avoid any personal data to be stored on the blockchain. • Patient Centricity: The enforcement of the blockchain-enhanced functionality must be completely transparent and accountable for the patients. The system must be integrated with patient privacy tools to perform enquires on each data access (e.g. read and write), either by exploiting an existing healthcare system (e.g. with the help of a hospital’s administrative clerk) or by using a mobile application (e.g. a smartphone access). • Modularity and Interoperability: The blockchain architectural design must pursue a modular approach to cope with the distribution of data and to favour seamless interoperability with existing legacy systems. Vendor-neutral architecture must be created so to ensure that the quality of a specific software solution does not depend on the vendor, i.e. preventing the so-called vendor lock-in effect. Implementing these requirements enables healthcare blockchain technologies to be smoothly and transparently integrated with already deployed document exchange systems, as well as by being compliant with the current legal and technical frameworks of the healthcare industry.

1.5.2 Blockchain Architecture The blockchain architecture for health data sharing is composed of two modular blocks: provenance management and SSI blockchain. Figure 1.5 reports the highlevel architecture. The EBSI and provenance blockchains provide the means to enhance the trust relationships established by the XCA communities. The EBSI, via the eIDAS bridge, permits notarising and verifying credential claims (e.g. accreditation and qualifications), while provenance allows via the PROV Proxy to create provenance documents to validate the quality of the exchanged medical data. These blockchain functions are designed to be modular and interoperable with legacy systems. The integration with XDS and its Security Assertion Markup Language (SAML)/eXtensible Access Control Markup Language (XACML) (IT Techni-

16

S. Bittins et al.

Fig. 1.5 Healthcare blockchain high-level architecture (trust among XCS communities is enhanced by using the blockchain systems)

cal Committee 2009) authentication and authorisation frameworks allow the enforcement of patient-informed consent. In particular, consent declaration (e.g. opt-in/optout or advance directive) can be enforced to regulate the application of blockchainbased services. Therefore, the integration of blockchain functionalities in routine document exchanges enables to increase the trust among communities’ members on the credentials (via SSI) and documents (via provenance) of their counterparts.

1.5.3 Towards an Healthcare Blockchain for Organ Transplant In this section, it presented the application of the blockchain architecture described above to the organ transplant case study. First, it is outlined how the accountability and transparency requirements mandated by the EFI standard can be implemented

1 Healthcare Data Management by Using Blockchain Technology

17

Fig. 1.6 Blockchain architecture functions at work on organ transplant processes (between brackets the references to the corresponding EFI standard sections)

through blockchain functionalities (Sect. 1.5.3.1). Then, it introduced an implementation roadmap, highlighting technical and deployment activities (Sect. 1.5.3.2).

1.5.3.1

Addressing Transplant EFI Rules with Blockchain

The rules set by the EFI standard can be fulfilled by blockchain-enabled functionalities—i.e. provenance and SSI. Figure 1.6 summaries the relationships between EFI rules and the functionalities. Laboratory Accreditation. The EFI section A contains the General Policies for accreditation of laboratories performing tests, either as primary laboratory (rules A11) or subcontracting (A12.1.1 and A13.2.1). The policies prescribe that all laboratories involved must be EFI accredited. In order to easily validate the credentials of laboratories, the blockchain SSI schema can be used. Specifically, the EFI auditor (i.e. the credential issuer) will register with the eIDAS-compatible identity of the laboratory the certificate of compliance. Any laboratory will then be able to verify the accreditation of other laboratories with accountable and interoperable guarantees. Personnel Qualifications. The EFI section B contains the requirements for the personnel qualifications. Similarly to section A, laboratories must ensure that all the working personnel is accredited. For instance, the director of the laboratory must hold a qualification approved by EFI, relevant experience in immunogenetics, etc. These rules can be addressed with blockchain SSI as well. In this case, the EFI

18

S. Bittins et al.

laboratories submit personnel (identified using eIDAS) experience reports to the blockchain. Notably, adopting a permissioned blockchain allows credential holders to maintain control on the disclosure of their credentials. Quality Assurance. The EFI section C is about quality assurance. It is required for a laboratory to implement quality controls on all activities and to maintain documentation adequate to international standards. In particular, compliance must be guaranteed with national laws on management of chemical and biological material (C1.4). Similarly to previous sections, credentials on compliance can be managed via the SSI blockchain. All documentation related to laboratory analysis must also be collected according to quality requirements. These requirements specifically focus on adverse events, where fully fledged investigations must be conducted (C3). As laboratory activities may involve multiple parties and rely on multiple actors, this rule can be addressed by using blockchain provenance. The enhancement of XDS transactions with provenance—integrated with the IHE profiles from the laboratory domain, e.g. the Laboratory Barcode Labelling (Laboratory Barcode Labeling 2020)—allows the creation of tamper-proof ledgers of the documentation (e.g. content creators and consumers). Testing Processes. The remaining EFI sections D, E and F address the testing processes with focus on laboratory data quality, analysis and post-analysis, respectively. The External Proficiency Testing is set of rules to ensure that all analysis activities meet the expected quality (D1). These rules are defined by the Eurotransplant Reference Laboratory (ETRL) (Reference Laboratory 2020). Credentials to witness the ETRL certification can be managed and made available via the SSI blockchain. All laboratory analysis and post-analysis processes must be described and documented (E and F). Besides the chemical and biological requirements, it is required to control adequately the whole supply chain (e.g. for reagents and incubators). Many standards already exist (Boyens et al. 2015; Cadzow et al. 2015), as well as innovative blockchain applications (Allen et al. 2019; Chang and Chen 2020). By relying on XDS document management, the blockchain provenance functionalities can be used to enable the full auditability of the laboratories’ supply chain.

1.5.3.2

An Implementation Roadmap

Below, it is commented the deployability at the time of writing of the blockchain architecture and the integration of the XDS systems with organ transplant organisations. Blockchain Platform. Blockchain technology platforms are nowadays widely available off-the-shelf. Multiple blockchain implementations exist, and therefore the technological building block for this aspect of our architecture is ready for immediate deployment.

1 Healthcare Data Management by Using Blockchain Technology

19

The blockchain provenance management has been prototyped with an Hyperledger Fabric deployment (Fabric 2020) and integrated with production eHealth systems. Fabric enables the development of updatable smart contracts (named chaincode) written in a high-level general-purpose language named Golang. Provenance smart contracts are ready to be deployed (Masi 2018) and integrated with industriallevel PROV Proxy, with performance of the blockchain that can scale up to 3.500 transactions per second (Behind the Architecture of Hyperledger Fabric 2018). However, this implementation targets application at country level. To move towards multicountry deployments, international communities (e.g. the eHealth DSI (European Commission 2019)) or organisations (e.g. the Eurotransplant) should lead the development process so to ensure absence of vendor lock-in and to better take into account all stakeholder requirements (e.g. how blockchain is geographically distributed and to who). The EBSI building block, at its core, is based on Hyperledger Fabric and Ethereum (European Commission 2020c). At the moment of writing, 19 blockchain nodes are running in the European member states, still on testing stage. The implementation of the fully functional eIDAS bridge is yet to be concluded, with planned released for new use cases in 2021 (European Blockchain Service Infrastructure 2020). eHealth Standards. To deploy the EFI rules based on blockchain functionalities, it is necessary for organ transplant organisations to adopt IHE-enabled document management. With the focus on laboratories, IHE defines the necessary profiles to build a Laboratory Information System which is used to share observations and results through standardised documents (e.g. HL7 messages of the type Observation Reporting). These messages can then be converted and serialised into structured medical documents (Boone 2011). Multiple formats are available (e.g. HL7 Clinical Document Architecture (CDA) (Health Level 7 2020) and FHIR (HL7 2018)) which, in turn, can be managed via XDS and hence by our blockchain system. Based on the document structure thus identified, the provenance and SSI credential templates can be defined and properly configured on the blockchain smart contracts. All in all, although the technology is fundamentally ready and at production level, the design of a multi-country blockchain platform has first to overcome legal and organisational issues. As per the IHE community experience, a large-scale deployment should be driven by clear organisation and semantic interoperability guidelines. The approach followed by the EU to implement, consolidate and integrate reusable building blocks should have as target objective to design a multi-country, generalpurpose blockchain that can be tailored to the specific needs of many application contexts, e.g. healthcare use cases such as organ transplant.

20

S. Bittins et al.

1.6 Addressing Legal Requirements for Healthcare Data Sharing The deployment of blockchain systems just presented can offer many opportunities in multiple healthcare scenarios. Due to the sensitivity of the health data, the deployment of blockchain in such data-intensive applications must take into account legal requirements related to patient centricity when exchanging data. In this section, it presented the role of patients in health data exchanges (Sect. 1.6.1), then the outstanding privacy challenges to address for responsible design and deployment of blockchain-based healthcare services (Sect. 1.6.2).

1.6.1 On the Patient Role in Health Data Exchange One fundamental issue of health data exchange is the lack of immediate patient involvement and focus. Although health systems are claiming to embody the principle of patient centricity throughout the entire life cycle of medical data, all industry standards and best practices focus exclusively on health providers (for instance, hospitals and laboratory), rather than meaningfully including patients. The patientfacing health data exchange landscape is scattered and inherently incompatible in itself. Recent developments in health frameworks, in particular the FHIR-based electronic health records of Google Fit (Google Fit 2020) and Apple Health Kit (Apple HealthKit 2020), address this issue and move towards re-integrating the patient into established data exchanges. However, additional regulatory, statutory and ethical challenges remain to be addressed. Patient Authorisation for Health Proceedings. In too many cases, healthcarerelated activities require patients’ notarised or certified documents (e.g. patient declarations, informed consents and authorisations). Capturing and making such documents available electronically suffer from the continued need to be primarily paperbased and necessitate a third party—such as a notary public or a health professional— to acknowledge form, circumstances and validity of the patient’s assertion. There are several means of stating ones wishes electronically, for instance the qualified electronic signature, that are regulated by public authorities such as the European Union. Their practical usability and cost are disfavourable compared to readily available smartphone applications already integrated with health records. These applications enable fine-grained sharing of medical data, as well as easing the access and use of electronic health services. Patient Remote Monitoring. Governments and health authorities have widely investigated the application of remote monitoring of patients to maintain and improve public health. Several factors related to the (privacy) law and ethics have hindered wide deployment of healthcare tracing applications. In the light of the COVID-19 pandemic, all these factors have been effectively devoid of any applicability.

1 Healthcare Data Management by Using Blockchain Technology

21

The entirely new category of health applications for contact tracing has spawned new cooperation between governments, health authorities and private telecommunication services to create, manage and share patients’ medical properties. For instance, these applications enable management of immediate, current and authenticated evidence about being either immune or non-contagious (so-called immunity passport (Robert and Lukasz 2020), which are requested by authorities as a prerequisite for being authorised to continue with regular life activities. The latter is not only a fundamental potential infringement of human rights, but also a principal shift of how health information is consumed, from infrequent access in very narrow circumstances to the need of being available at any given moment with a very short “best before” date. This challenge has been even magnified with the development of healthcare solutions integrated into social media (Bock et al. 2020) and mobile devices (Apple 2020). This poses an even bigger challenge to the public health systems (Georgetown University Medical Center 2020): How to transport a particular compilation of medical data authenticated, promptly, legitimately, reliably, transparent and fully traceable throughout all relevant stakeholders for legitimate purposes? Therefore, smartphone applications may become the next-generation health passport for patients that can be used to promptly present health credentials. However, they require privacy-aware, fully digital system to rely on. Blockchain health data platform can be leveraged to offer this service. Its decentralised platform is devoted to digitally represent with tamper-proof guarantees physical artefacts, e.g. national health insurance cards, immunisation attestation, etc. More importantly, the close coupling with the EBSI SSI infrastructure provides reliable yet almost anonymous proof of someone’s identity trait while retaining full control by the data subject. One’s attributes, e.g. non-contagious attribute of the immunity passport, can be proved without releasing the whole passport.

1.6.2 Outstanding Privacy Challenges for Healthcare Blockchain The development of novel blockchain-based services, especially in health-related domains, must embody by-design the enforcement of individual privacy rights in order to target a responsible design and deployment of blockchain services. In the following, it commented the key non-functional requirements to take into account • Anonymity versus Public Health: When tracing patients, all geolocation information and specific proof are collected and processed under the assumption of full anonymity. As emergent public health needs can arise (e.g. the COVID-19 pandemic), the need for more exhaustive information rises exponentially. Applications like the contact tracing ones are fundamentally incompatible with a truly anonymous data collection. Similarly, businesses and organisations need to demonstrate sufficient compliance with imposed restrictions, for instance, occupancy limits

22

•

•

•

•

S. Bittins et al.

or spot checks of immunity verification, which practically disqualifies the use of anonymous records. Voluntary Adoption: As stated bluntly in (Bock et al., 2020), the truly voluntary adoption in such functions is plainly illusory, as long as participating in regular life activities depends on providing the right proof in the right form from the right authority at the right time. For most functions, the collection, processing and communication of the complete identity of the natural person are not required, as usually only a single property is actually requested, such as a proximity to a certain location at a certain time. Transparency: Even with the available guidance of the national and international supervision bodies, it is almost impossible for the regular person to assess which personal information is communicated whom to, what for and under whose authority. For instance, the guidance provided by the European Data Protection Board specifically names (i) electronic communication service providers, and applications of (ii) information society service providers whose functionality requires the use of such data as the two principal sources of location data (Guidelines 04/2020 on the Use of location data and contact tracing tools in the context of the COVID19 outbreak 2020). What applications and providers actually encompass is rather debatable. For instance, neither Apple nor Google clearly fall under either category despite offering operating system-level API functions to facilitate contact tracing as well as geolocation. End users may not be able to easily determine whom a consent is given to, who is originally collecting what data and what low-level functions their consent includes. Verifiability and Authenticity: Both private organisations and businesses, as well as public health systems, do hold a valid and currently vital interest in the verifiability and authenticity of data. Being able to present a forged immunity passport or to manipulate location data erodes the purpose and justifying benefit of such functions. Consequently, a sufficient degree of reliability needs to be provided, such as certifying through a mutually trusted entity that a singular property of a laboratory report states a negative infection at a certain point in time for an identity linked irrefutably to the natural person bearing and presenting it. Robustness of Authenticity: Many declarations regarding health require advance statements in written form, and sometimes even notarised. Picking the example of one’s willingness to donate organs, traditional means of stating such decision are incompatible with today’s expectation of immediacy. Furthermore, carrying a physical card or an additional physical property on a driver’s licence to signify being an organ donor potentially restricts better participation because any change of mind is usually tied to a significant amount of effort and cost. There is no streamlined and fully digital means of exercising the right to change one stance and to communicate the effect immediately.

Generally speaking, according to the Fundamental Rights Study (European Union Agency for Fundamental Rights 2020), “41% of the of respondents reveal that they do not want to share any personal data with private companies"; hence, there is a general negative belief on how personal data is managed for highly innovative

1 Healthcare Data Management by Using Blockchain Technology

23

health applications. The development of specific anchor points and understandable guidelines to co-develop privacy-enhancing functionalities and technologies must be defined in the technology and adequately reflected in law.

1.7 Conclusions and Future Works The blockchain-based architecture presented in this chapter aims at enhancing the trust of current data exchange solutions based on IHE technical profiles. This architecture, which can be seamlessly integrated with legacy healthcare systems, includes (i) the automatic creation of provenance annotations based on the W3C PROV standard for patients’ medical documents, and (ii) SSI credential verification based on the EBSI infrastructure. This principled integration permits enhancing the trust of the data interactions among communities. Presenting an organ donation and transplant use case, it is illustrated how our architecture addresses the EFI rules for transplant processes. By commenting on the role of patients in emergent healthcare services, such as mobile healthcare and patient tracing, it described the legal requirements that should be embodied in the design and deployment of next-generation blockchain healthcare services. In the near future, the aim is to integrate the presented blockchain functionalities into new healthcare use cases, with the focal objective of empowering the patient centricity and usability of the sharing practices of medical data. The automatic provenance management can support the creation of reproducible clinical research (McGhin et al. 2019). Such problem has been amplified by the urgency posed by the COVID-19 pandemic: poorly assessed clinical data resulted in inaccurate published and then retracted research (Mehra et al. 2020) which could have endangered patients’ safety. The integration of SSI within multiple healthcare contexts can lead to more flexible and usable services for patients. From fine-grained consent verification to immediate validation of certifications, SSI can pave the way to implement the “Once Only Principle” for all healthcare services.

References Allen, D., Berg, C., Davidson, S., Novak, M., & Potts, J. (2019 May). Asia and the Pacific Policy Studies: International policy coordination for blockchain supply chains, p. 6 Almassi, B. (2014). Trust and the duty of organ donation. Bioethics, 8(28), 275–83. Apple (2020, April). Apple and Google partner on COVID-19 contact tracing technology. https:// www.healthit.gov/topic/health-it-initiatives/blue-button. Apple HealthKit. (2020). Apple. https://developer.apple.com/health-fitness/. Behind the Architecture of Hyperledger Fabric. (2018). IBM. https://www.ibm.com/blogs/research/ 2018/02/architecture-hyperledger-fabric/.

24

S. Bittins et al.

Benchoufi, M., & Ravaud, P. (2017, July). Blockchain technology for improving clinical research quality. Trials, 18(1), 335. ISSN: 1745–6215. https://doi.org/10.1186/s13063-017-2035-z. Bock, K., Ricardo, C., Kühne, R., Mühlhoff, M. R. Ost, J. P., & Rehak, R. (2020 April) Datenschutzfolgenabschätzung (DSFA) für eine corona-app. Boone, K. W. (2011). The CDA TM book (1st ed.). London: Springer-Verlag. Bouhaddou, O., Bennett, J., Teal, J., Pugh, M., Sands, M., Fontaine, F., et al. (2012). Toward a virtual lifetime electronic record: The department of veterans affairs experience with the nationwide health information network. In: AMIA. Annual Symposium proceedings/AMIA Symposium, 2012 (pp. 51–60). Boyens, J., Paulsen, C., Moorthy, R., & Bartol, N. (2015). Supply chain risk management practices for federal information systems and organizations. Cadzow, S., Giannopoulous, G., Merle, A., Storch, T., Vishik, C., Gorniak, S., & Ikonomou D. (2015). Supply chain integrity. An overview of the ICT supply chain risks and challenges, and vision for the way forward. Centers for Medicare & Medicaid Services. (1996). The Health insurance portability and accountability act of 1996 (HIPAA). Online at http://www.cms.hhs.gov/hipaa/. Chang, S. E. & Chen, Y. (2020, March). When blockchain meets supply chain: A systematic literature review on current development and potential applications. IEEE Access 1–1. Cross-border health project epSOS: What has it achieved? (2014). EU commission. https:// ec.europa.eu/digital-single-market/en/news/cross-border-health-project-epsos-what-has-itachieved. Curcin, V., Fairweather, E., Danger, R., & Corrigan D. (2017). Templates as a method for implementing data provenance in decision support systems. Journal of Biomedical Informatics, 65, 1–21. ISSN: 1532-0464. Data Provenance Glossary. (2016). S & I framework. http://wiki.siframework.org/ Data+Provenance+Glossary. EFI. (2017). Standards for histocompatibility and immunogenetics testing. European Federation for Immunogenetics: Tech. rep. Electronic Cross-Border Health Services. (2020). EU Commission. https://ec.europa.eu/health/ ehealth/electronic_crossborder_healthservices_en. ELGA GmbH. (2017). Gesamtarchitektur. Technical Report ELGA. https://www.elga.gv.at/ fileadmin/user_upload/Dokumente_PDF_MP4/Technisches/ELGA_Gesamtarchitektur_2.30a. pdf. European Blockchain Service Infrastructure (EBSI). (2020). EU commission. https://ec.europa.eu/ cefdigital/wiki/display/CEFDIGITAL/EBSI. European Commission. (2020a). Communication from the commission to the European parliament, the council, the European economic and social committee, and the committee of the regions—a European strategy for data. European Commission. (2020b). Communication from the commission to the European parliament, the council, the European economic and social committee, and the committee of the regions— shaping Europe’s digital future. European Commission. (2020c). EBSI technical details. https://ec.europa.eu/cefdigital/ wiki/display/CEFDIGITAL/Minimum+Technical+Requirements+for+an+EBSI+v1. 0+NODE+Deployment. European Commission. (2020d). White paper on artificial intelligence—A European approach to excellence and trust. European Commission. DG SANTE (2019). The eHealth digital service infrastructure (eHDSI). https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS. European Interoperability Reference Architecture (EIRA). (2020). EU Commission. https://joinup. ec.europa.eu/solution/eira. European Parliament and the Council. (2016). Directive (EU) 2016/1148 of the 6th July 2016 concerning measures for a high common level of security of network and information systems across the union.

1 Healthcare Data Management by Using Blockchain Technology

25

European Union Agency for Fundamental Rights. (2020). How concerned are Europeans about their personal data online? https://fra.europa.eu/en/news/2020/how-concerned-are-europeans-abouttheir-personal-data-online. EurotransplantWeb Page. (2020). Eurotransplant. https://www.eurotransplant.org/. Fabric. (2020). Hyperledger. https://www.hyperledger.org/use/fabric. Georgetown University Medical Center. (2020). Immunity passports to vaccination certificates for COVID-19: Equitable and legal challenges. https://fra.europa.eu/en/news/2020/how-concernedare-europeans-about-their-personal-data-online. Google Fit. (2020). Google. https://www.google.com/fit/. Guidelines 04/2020 on the use of location data and contact tracing tools in the context of the COVID-19 outbreak (2020, April). European Data Protection Board. http://edpb.europa.eu/sites/ edpb/files/files/file1/edpb_guidelines_20200420_contact_tracing_covid_with_annex_en.pdf. Gulhan, I. (2020). A unique e-health and telemedicine implementation: European Reference Networks for rare diseases. Journal of Public Health, 28, 223–225. Hardin, T., & Kotz, D. (2019). Blockchain in health data systems: A survey. In 2019 sixth international conference on internet of things: Systems, management and security (IOTSMS), pp. 490–497. Harmer, A., Mascaretti, L., & Petershofen, E. (2018). Accreditation of histocompatibility and immunogenetics laboratories: Achievements and future prospects from the European federation for immunogenetics accreditation programme. HLA, 92(2), 67–73. Health Level 7. (2020). HL7 https://www.hl7.org. HIMSS. (2020). Blockchain in healthcare. https://www.himss.org/resources/blockchainhealthcare. HITECH Act Enforcement Interim Final Rule. (2009). Department of health and human services. https://www.hhs.gov/hipaa/for-professionals/special-topics/hitech-act-enforcementinterim-final-rule/index.html. HL7. (2018). FHIR: Fast healthcare interoperability resources. https://hl7.org/fhir. IHE. (2019). The IHE IT Infrastructure (ITI) Technical Framework, Volume 1. Technical Report IHE. https://www.ihe.net/uploadedFiles/ IHE Developing Integration Profile for the International Patient Summary. (2020). IHE. https:// www.ihe.net/news/ihe-developing-integration-profile-for-the-international-patient-summary/. Integrating the Healthcare Enterprise. (2020). IHE. https://www.ihe.net. IT Technical Committee. (2009). IHE IT-infrastructure white paper: Access control. https://ec. europa.eu/eip/ageing/standards/ict-and-communication/data/ihe-it-infrastructure-white-paperaccess-control_en. Kim, E., Rubinstein, S. M., Nead, K. T., Wojcieszynski, A. P., Gabriel, P. E., & Warner, J. L. (2019). The evolving use of electronic health records (EHR) for research. Seminars in Radiation Oncology, 29(4), 354–361. ISSN: 1053-4296. Krishnan, S., Balas, V. E., Julie, E. G., Robinson, Y. H., Balaji, S., & Kumar, R. (eds.) (2020). Handbook of research on blockchain technology. Elsevier. Kuperman, G. J., Blair, J. S., Franck, R. A., Devaraj, S., & Low, A. F. H. (2010). Developing data content specifications for the nationwide health information network trial implementations. Journal of the American Medical Informatics Association: JAMIA, 17, 6–12. Laboratory Barcode Labeling. (2020). IHE. https://wiki.ihe.net/index.php/Laboratory_Barcode_ Labeling. Margheri, A. (2018, May). Decentralised provenance for healthcare exchange services. https://medium.com/cybersoton/decentralised-provenance-for-healthcare-exchange-servicesb900cd96136c. Margheri, A., Masi, M., Miladi, A., Sassone, V., & Rosenzweig, J. (2020). Decentralised provenance for healthcare data. International Journal of Medical Informatics, 141, 104197. ISSN: 1386-5056. Masi, M. (2018). Chaincode for the provenance tracking. https://github.com/mascanc. Masi, M., & Maurer, R. (2010). On the usage of SAML delegate assertions in an healthcare scenario with federated communities. In M. Szomszor & P. Kostkova (Eds.), Electronic Healthcare-Third

26

S. Bittins et al.

International Conference, eHealth 2010, Casablanca, Morocco, December 13–15, 2010, Revised Selected Papers (Vol. 69, pp. 212–220). Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering: Springer. McGhin, T., Raymond Choo, K.-K., Liu, C. Z., & He, D. (2019). Blockchain in healthcare applications: research challenges and opportunities. Journal of Network and Computer Applications, 135, 62–75. ISSN: 1084-8045. Mehra, M. R. Ruschitzka, F., & Patel, A .N. (2020). Retraction-hydroxychloroquine or chloroquine with or without a macrolide for treatment of COVID-19: A multinational registry analysis. The Lancet, 395(10240), 1820. ISSN: 0140-6736. Missier, P. Belhajjame, K., & Cheney J. (2013). The W3C PROV family of specifications for modelling provenance. Mohanta, B. K., Jena, D., Panda, S. S., & Sobhanayak, S. (2019). Blockchain technology: Asurvey on applications and security privacy Challenges. Internet of Things, 8, 100107. ISSN: 2542-6605. Mohsen, M. O., & Aziz, H. A. (2015). The blue button project: Engaging patients in healthcare by a click of a button. Perspectives in health information management, 12. Mühle, A., Grüner, A., Gayvoronskaya, T., & Meinel, C. (2018). A survey on essential components of a self-sovereign identity. Computer Science Review, 30, 80–86. Namasudra, S., Deka, G. C., Johri, P., Hosseinpour, M., & Gandom, A. H. (2020, May). The revolution of blockchain: State-of-the-art and research challenges. Archives of Computational Methods in Engineering. Niaksu, O., Kodra, P., Pina, M., & Grabenweger, J. (2017). Implementation of nationwide electronic health record in Albania: A Case Study. Studies in health technology and informatics, 236, 111– 120. Official Website of The Office of the National Coordinator for Health Information Technology (ONC). (2020). Appendix I - sources of security standards and security patterns. http://www. healthit.gov/isa/ISA_Document/Appendix_I. OpenNCP Community Home. (2020). EU commission. https://ec.europa.eu/cefdigital/wiki/ display/EHNCP/OpenNCP+Community+Home. Pavleska, T., Aranha, M.M., Grandry, E., & Sellitto, G. P. (2019). Cybersecurity evaluation of enterprise architectures: The e-sens case. In J. Gordijn, W. Guédria, & H. A. Proper (Eds.), The Practice of Enterprise Modeling—12th IFIP Working Conference, PoEM 2019, Luxembourg, Luxembourg, November 27-29, 2019, Proceedings. Vol. 369. Lecture Notes in Business Information Processing, (pp. 226–241). Springer. Personal Connected Health Alliance. (2020). PCHA. https://pchalliance.org. Reed, D., Sporny, M., Longley, D., Allen, C., Grant, R., Sabadello, M., & Holt, J. (2020). Decentralized identifiers (DIDs) v1.0. Reference Laboratory. (2020). Eurotransplant. https://www.eurotransplant.org/professionals/etrl/. Reisman, M. (2017). EHRs: The challenge of making electronic data usable and interoperable, P & T (42). Riemann, R., & Olejnik, L. (2020). TechDispatch #1/2020: Contact tracing with mobile applications. European Data Protection Supervisor: TechDispatch. ISSN: 2599-932X. Rosental, R., Dainis, B., & Dmitriev, P. (1997). BaltTransplant: A new organization for transplantation in the Baltic States. Transplantation Proceedings, 29(8), 3218–3219. ISSN: 0041-1345. Royal College of Physicians of Ireland. (2019). Model of care for rare diseases—The national clinical program for rare diseases. Saidi, R., & Kenari, S. (2014). Challenges of organ shortage for transplantation: Solutions and opportunities. International Journal of Organ Transplantation Medicine, 5, 87–96. Scholl, M. A., Stine, K. M., Hash, J., Bowen, P., Johnson, L. A., Smith, C. D., & Steinberg, D. I. (2008). SP 800-66 Rev. 1. An introductory resource guide for implementing the health insurance portability and accountability act (HIPAA) security rule. Technical Report Gaithersburg, MD, USA: NIST.

1 Healthcare Data Management by Using Blockchain Technology

27

Schulte, K., Borzikowsky, C., Rahmel, A., Felix, K., Polze, N., Fränkel, P., et al. (2018). Decline in organ donation in Germany: A nationwide secondary analysis of all inpatient cases. Dtsch Arztebl International, 115, 463–468. Shoeb, S. (2018). ICOs in Healthcare industry | Detailed Healthcare ICO sector analysis. https://hackernoon.com/icos-in-healthcare-industry-detailed-healthcare-ico-sector-analysisdd73766e809. SNOMED CT (2020). SNOMED. https://www.snomed.org/. Staff, C.-A. C. M. (2019). Access controls and healthcare records: who owns the data? Communications of the ACM, 62(7), 41–46. The digital imaging and communications in medicine (DICOM) standard (2020). DICOM. https:// www.dicomstandard.org/. The Sequoia Project. (2019). Sequoia. https://sequoiaproject.org. Tobin, A., & Reed, D. (2018). The Inevitable Rise of Self-Sovereign Identity. The Sovrin Foundation: Technical Report. Trillium Bridge II. (2020). EU Commission. https://cordis.europa.eu/project/id/727745/it. Wang, X., Zha, X., Ni, W., Liu, R. P., Guo, Y. J., Niu, X., & Zheng, K. (2019). Survey on blockchain for internet of things. Computer Communications, 136, 10–29. ISSN: 0140-3664. Weigand, K. (2018). Organspende in deutschland: Wollen wir nicht? Können wir nicht? Oder dürfen wir nicht? Urologe, 57, 1091–1099. Windley, P. (2016). How Sovrin works: A technical guide form the sovrin foundation. Sovrin: Technical Report. World Health Organisation. (2019). Recommendations on Digital Interventions for Health System Strengthening https://www.who.int/reproductivehealth/publications/digital-interventionshealth-system-strengthening/en/. Xia, K.-J., Zhong, X., Zhang, L., & Wang, J. (2019). Optimization of diagnosis and treatment of chronic diseases based on association analysis under the background of regional integration. Journal of Medical Systems, 43(3), 46:1–46:8.

Chapter 2

Modernizing Healthcare by Using Blockchain Mario Ciampi, Angelo Esposito, Fabrizio Marangio, Mario Sicuranza, and Giovanni Schmid

Abstract Electronic health record (EHR) systems are designed and deployed to store data accurately and to capture the state of a patient across time, and they have been one of the major drivers to advance care in the last decade. However, the EHR is not eligible in supporting a model that is beyond episodic visits, nor the idea of an integrated care plan that all care team members can view and contribute to. On the other hand, the concept of a longitudinal record and the idea of a “smart care plan” are key factors for paving the way toward Predictive, Preventive, Personalized and Participatory (P4-medicine), which arguably will be in a near future the only effective and sustainable approach for pandemics and “silent” chronic diseases. At the current state-of-the-art, the HL7 FHIR standard and distributed ledger technologies (DLTs) are two very promising areas of research and development in the context of health information management, and a proper synergy among their approaches, concepts and tools could overcome the limitations of EHR systems, giving rise to the hub of the IT infrastructure for P4-medicine. This chapter explores the potential and challenges of integrating the FHIR standard into DLTs, also through a concrete example of implementation. Keywords Electronic health record · FHIR · Care planning · Blockchain · Hyperledger fabric

M. Ciampi (B) · A. Esposito · F. Marangio · M. Sicuranza · G. Schmid Institute for High Performance Computing and Networking of the National Research Council of Italy, Naples, Italy e-mail: [email protected] A. Esposito e-mail: [email protected] F. Marangio e-mail: [email protected] M. Sicuranza e-mail: [email protected] G. Schmid e-mail: [email protected] © The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2021 S. Namasudra and G. C. Deka (eds.), Applications of Blockchain in Healthcare, Studies in Big Data 83, https://doi.org/10.1007/978-981-15-9547-9_2

29

30

M. Ciampi et al.

2.1 Introduction Population health information management is a key factor for paving the way toward Predictive, Preventive, Personalized and Participatory medicine (P4-medicine), which in turn represents the main answer to the two most challenging threats to population health: pandemics and “silent” chronic diseases. Arguably, P4-medicine will be in a near future the only effective approach for containing public spending and the sustainability of national health systems (Góngora Alonso et al. 2019). In the last decade, electronic health record (EHR) systems have been designed and deployed to store data accurately and to capture the state of a patient across time, and they represent one of the major drivers to advance care in many Countries. However, the EHR is not eligible in supporting a model that is beyond episodic visits, nor the idea of an integrated care plan that would draw on all of the relevant data about an individual at any point in time, and that all care team members can view and contribute to. These smart care plans could represent the linchpin of P4-medicine approaches if they were housed on collaborative care platforms that can access to and perform cognitive computing on the patient data from a variety of sources. Distributed ledger technologies (DLTs)—and, in particular, blockchain architectures—are widely recognized as having the potential to transform health care, placing patients at the center of the healthcare ecosystem and increasing the availability, reliability and usefulness of their data (Ciampi et al. 2019). However, an analysis of the current state-of-the-art of DLTs in healthcare shows that it is very challenging to design and implement dependable, interoperable and scalable blockchain platforms upon which health information can be connected, searched for and computed in compliance with privacy and safety regulations (Namasudra et al. 2020). In fact, data and workflows in healthcare are by far more complex, variegate and interdependent than in other application domains, and major efforts have to be done in order to guarantee that the proposed solutions actually permit to store medical data in a certified manner (Kim and Deka 2019) and adhere to emerging standards. The HL7 Fast Health Interoperability Resources (FHIR) standard and the use of open application programming interfaces (APIs) are very promising approaches for developing IT platforms aiming at managing population health information, now that new sources, formats and processing tools for health data are emerging, and that interoperability among health IT systems and with patient’s own data sources will be required (Kilintzis et al. 2019). The characteristics of this new standard, which permits to represent health information in simple and formal data structures (named “resources”) based on XML or JSON formats, facilitate the implementation of numerous applications for the healthcare sector that need to exchange and memorize data. In particular, it represents an enabling standard to support all the actors involved in care plans according to a patient-centric approach. These aspects are dealt with the IHE Dynamic Care Planning (DCP) profile, which specifies the structures and communication protocols based on FHIR resources for planning, creating, updating and sharing care plans among many users (like providers, patients and payers), with particular reference to patients with chronic conditions.

2 Modernizing Healthcare by Using Blockchain

31

The recent technological innovations have been permitting to significantly improve healthcare services: (i) healthcare informatics standards consent to structure clinical data and processes in an unambiguous way, (ii) artificial intelligence technologies allow to derive new medical knowledge, (iii) regulations and norms enable to develop privacy- and security-by design solutions, and so on. However, the event clinics regarding patients occurred after physicians’ prescriptions are not always traceable and very often the health processes are carried out in a wrong or not completed way. This issue represents the motivation of this chapter, which is devoted to explore potentialities and challenges of integrating the FHIR standard in distributed ledger technologies for managing clinical processes. After introducing concepts, frameworks and emerging needs for the health domain, the chapter will explore the relationships of permissioned blockchain technologies with FHIR and IHE DCP. Then, a concrete example concerning the implementation of IHE DCP profile in Hyperledger Fabric is illustrated and discussed. The rest of the chapter is organized as follows. Section 2.2 provides an overview on Distributed Ledger Technologies and on the Hyperledger Project. Section 2.3 illustrates the most important needs of the health domain and the desired tools. Section 2.4 describes the key characteristics of the health informatics standards for data representation and care planning, such as HL7 FHIR and IHE PCC DCP. Section 2.5 illustrates the mechanisms to adopt to manage and monitor clinical information included in health records in a secure and standard way. Section 2.6 proposes a novel blockchain network based on Hyperledger Fabric opportunely designed to manage resources represented in HL7 FHIR. Section 2.7 presents a case study that shows how to manage care plans by means of a blockchain-based platform opportunely designed. Section 2.8 concludes the chapter.

2.2 Distributed Ledger Technologies The natural recording system for recordkeeping business actions is the ledger, an append-only register, where asset transfers to or from it. These actions, also known as transactions, are recorded according to contracts, which set conditions for transactions to occur. Therefore, a ledger is a registry acting as a historical memory, with the aim of checking, verifying and managing all the transactions made and the assets involved therein. In the context of the modern society, an asset is anything, tangible or intangible, that is capable of being owned or controlled to produce value, and assets are more and more made available through sets of companies and organizations, each having a different role, function and geographical location but common strategic and operational objectives. Such business networks can be quite complex in processing, and can be deployed on a very large scale, but each participant keeps their own system of record and runs their own form of the business process to update their ledger.

32

M. Ciampi et al.

This reflects the centralized nature of the data base management systems (DBMSs) realizing these recording systems. Although a DBMS, through its deployment, could implement a traditional ledger with various degrees of replication and/or distribution among multiple network nodes (in order to avoid a single point of failure), data in these systems are stored and managed under the control and responsibility of a single authority. This lack of decentralization may lead to substantial costs and risks in business networks, where multiple ledgers have to be kept synchronized between all the interacting parties. Establishing data provenance can be very laborious, tracking back a chain of transactions can take days, contracts must be signed and executed manually, and every database in the network can represent a single point of failure since it contains unique information. A distributed ledger is a ledger replicated among multiple parties. All the replicas are kept synchronized without a central authority, through to a consensus protocol (that is, a protocol among a set of peers designed to ensure that all participants agree on a common value or status). In addition to data being shared, the software protocols (well known as smart contracts) that implement the logic related to assets and transactions can also be shared through the ledger. Specifically, a smart contract is a piece of code defining the transaction logic that controls the lifecycle of a business object (asset) contained in the world state. One or more smart contracts can be packaged into a chaincode, which is then deployed to a communication subnet, where a consensus protocol allows a set of peers to determine which transactions can be written to, and their total ordering in the shared ledger. This way, a unique copy of the ledger is shared among participants (consistency), and they will have a common view of the business processes flowing throughout the network. Moreover, a consensus protocol for a distributed ledger system is usually designed to be resilient to a certain percentage of peers that can arbitrarily diverge from following the protocol, thus assuring both the liveness and integrity of the network below a threshold of such faults. With the ability to coordinate their business data and processes through a shared ledger also in untrusted environments, business networks can overcome many of the drawbacks and limitations of current systems.

2.2.1 Introduction to DLTs Distributed ledger technologies generically refer to a set of data structures, protocols and networking technologies that, when appropriately combined, give rise to a distributed ledger system. At the current state-of-the-art, many DLT-based systems exist, differing in the kind of registers, consensus protocol, network and smart contracts programming. These technical differences often reflect the diverse key requirements from which distributed ledger systems are designed and implemented. DLTs emerged from the consumer-to-consumer market with the exchange of cryptocurrencies, as a decentralized method of value transfer without third-party intermediaries. Originally designed in 2008 as the core data and programming structure of the Bitcoin cryptocurrency, blockchain technology is an application of DLTs that,

2 Modernizing Healthcare by Using Blockchain

33

in the last two decades, has widely spread and evolved beyond the scope and context of financial industry. In a blockchain network, any transaction task concerns endpoints that are authenticated through public keys of a given digital signature scheme, and the blockchain ledger composes of a continuously growing list of transaction records that are grouped in blocks, where each block contains a cryptographic hash of the previous block. Assuming that a given block cannot be altered, all the previous blocks in the chain— with high probability—cannot be altered, too, because of the properties of the hash function. In particular, if the last block in the chain is supposed to be uniquely generated and unforgeable, then these properties are inherited with high probability by all the other blocks, and the overall blockchain satisfies both the consistency and integrity properties. Blockchain technology is quickly evolving and consolidating around two basic models of decentralized network, realizing two different types of blockchain: permissionless and permissioned. Bitcoin and Ethereum are examples of permissionless blockchain: anyone can participate to the management of the ledger through the consensus protocol without a specific identity. Permissionless blockchains typically involve a native cryptocurrency and often use consensus based on a “proof of X” block proposal scheme, unfinished block finalization (as explained below) and economic incentives. In permissioned blockchains, on the other hand, the ledger is managed by a restricted set of known, identified participants in the system, and consensus can be realized through more efficient approaches achieving deterministic finality like byzantine fault tolerant (BFT ) protocols. BFT and “proof of X” based protocols are both designed to tolerate byzantine faults, in which one or more peers involved in consensus behave arbitrarily against the goal of reaching agreement (liveness) or that of adding to the blockchain the true block intended by the protocol (integrity). BFT protocols have been studied since the early 80 s (Pease et al. 1980; Lamport et al. 1982; Dwork et al. 1988), and modern instantiations can be deployed on asynchronous networks (e.g.; Miller et al. 2016) and also be optimized for different objectives like BEAT (Duan et al. 2018). These protocols have a marginal computing cost and result in a definite agreement, but can manage consensus only on small scale (up to few dozens of nodes), since they require explicit communication rounds among participants in order to select the peer in charge of uploading the new block to the blockchain. On the contrary, “proof of X” based protocols select the uploader through a sort of cryptographic puzzle, which does not require explicit communication, so they scale well and can be used to manage consensus among a large and open set of participants. In the face of such advantages, however, these protocols: (i) are quite expensive in terms of specific resources of participants (e.g.; computational power, owned coins, network bandwidth), and (ii) suffer from unfinished consensus, that is they select the uploader just with high probability so that temporary forks in the blockchain could occur before reconciliation. The first unfinished consensus protocol was the Nakamoto protocol introduced with Bitcoin (Nakamoto 2008), which is based on the proof of work (PoW ) block proposal scheme and uses the longest chain rule for block finalization. In this last decade, many alternatives to the PoW have been introduced, primarily in order to avoid its energetic

34

M. Ciampi et al.

high inefficiency, such as the proof of stake (PoS) (King and Nadal 2012), the proof of activity (PoA) (Bentov 2014; Bentov et al. 2016) and the proof of elapsed time (PoET ) (Chen et al. 2017). Other recent proposals (e.g.; Kogias et al. 2016; Micali & Vaikuntanathan 2017; Daian et al. 2019) try to overcome the limitations of the two above approaches by combining them in hybrid protocols that first randomly select a small subgroup of participants and then reach consensus through explicit voting ballots in this subset. Overall, there are currently substantial efforts and investments for not only developing and deploying mature DLT-based systems in many industry sectors like finance, manufacturing, banking, insurance, retail, healthcare and telcos, but also to improve public administration and e-governance. The next Subsection illustrates the Hyperledger project, one of the major consortium established so far as a result of the great interest of industry toward DLTs; it is of particular interest in the context of business networks, since its main goal is to promote a modular approach that provides a wide range of open-source blockchain solutions across many industries.

2.2.2 The Hyperledger Project The Hyperledger project was started in 2015 by the Linux Foundation to advance cross-industry collaboration by developing blockchains and distributed ledgers, with a particular focus on improving the performance and reliability of these systems, so that they are capable of supporting global business transactions by major technological, financial and supply chain companies. The philosophy underlying this project is that DLT is not one-size-fits-all technology: since different organizations have different needs, there will never be one single, standard blockchain; instead, many blockchains with different features will provide a wide range of solutions across many industries. Hyperledger provides a “greenhouse” structure that can incubate new ideas, support each one with essential resources, and distribute the results widely. Modular programming allows this structure to support many different solutions while consuming far fewer resources. So far, the available Hyperledger projects enabling the implementation of DLTs are: Besu, Burrow, Fabric, Indy, Iroha, Sawtooth. All the Hyperledger projects are designed so to be composed of software modules that can be reused and replaced. This way, developers can experiment and build blockchain suitable for different requirements. Through this feature, for instance, different consensus protocols can be tried in order to find the one that best suits a given application scenario. The Hyperledger Architecture Work Group (AWG) is a technical workgroup focused on identifying common and critical components, providing a functional decomposition of a blockchain stack into component layers and modules, regularizing interfaces between the components, and interoperability between ledgers. Another important aspect of the blockchain solutions hosted by the

2 Modernizing Healthcare by Using Blockchain

35

Hyperledger projects is that they do not require any cryptocurrency or token in order to work; however, some of these projects allow implementing a cryptocurrency, or giving developers the possibility to create tokens so to manage assets and currencies through them. A cryptocurrency is a digital medium of exchange designed so that individual coin ownership records are stored in a database using strong cryptography, so to control the creation of additional digital coin records and to guarantee the correct flow of coin transactions avoiding double spending. Instead, a token represents an asset or utility tied to, and evaluated in term of, a given blockchain cryptocurrency. Tokens are tradable and transferable among the various participants of the blockchain, and they are often used to fundraise for crowd sales. At the time of writing this chapter, the Hyperledger project hosts the frameworks, libraries and tools illustrated in Fig. 2.1. Six different frameworks for implementing complete DLT-based systems are currently provided, all based on the blockchain technology but with major differences in the consensus protocols supported, the membership service, the smart contract programming models, and the APIs for the interactions of the application layer with the blockchain network. Some frameworks, like Burrow and Indy, are focused on specific tasks, whilst others (e.g.; Fabric) are general frameworks that aim at providing solutions for different application scenarios. The main characteristics of the Hyperledger projects designed to realize DLTs are provided below. Besu is a client designed to create public or private permissioned networks on top of Ethereum, but that can also be ran on test networks such as Rinkeby (Rinkeby 2020) or Ropsten (Ropsten 2020). It supports different consensus algorithms including IBFT2.0 (Saltini and Hyland-Wood 2019), Ethash (Zamanov et al. 2018), and RCPA (Schwartz et al. 2014). Burrow provides a modular blockchain client with a permissioned smart contract interpreter built in part to the specification of the Ethereum Virtual Machine (EVM). It was designed to be a general-purpose smart contract machine. It supports both

Fig. 2.1 The Hyperledger Project “greenhouse” structure. (source www.hyperledger.org)

36

M. Ciampi et al.

EVM and WASM based smart contracts and uses BFT consensus via the Tendermint algorithm (Kwon 2014). Governance and permissioning is built in and can be amended by on-chain proposal transactions. It is optimized for public permissioned proof of stake use cases, but can also be used for private/consortium networks. Fabric is a platform for building distributed ledger solutions, with a modular architecture that delivers high degrees of confidentiality, flexibility, resiliency, and scalability. Fabric allows main components, such as consensus and membership services, to be plug-and-play. This way, solutions developed with Fabric can be adapted for any industry. It leverages container technology to host and orchestrate the various components of a blockchain network, and offers the possibility to write smart contracts in different general-purpose programming languages like Go, Javascript, and Java. Indy is a special-purpose distributed ledger for the deployment and management of digital identities. Indy provides tools, libraries, and reusable components for creating and using independent digital identities rooted on blockchains or other distributed ledgers. These identities are interoperable across administrative domains, applications, and any other organizational silos. Iroha is an easy to use, modular distributed blockchain platform with its own unique crash fault tolerant consensus and ordering service algorithms, rich role-based permission model and multi-signature support. Iroha was designed to be simple and easy to incorporate into infrastructural or IoT projects that require distributed ledger technology. Sawtooth offers a flexible and modular architecture that separates the core system from the application domain, so smart contracts can specify the business rules for applications without needing to know the underlying design of the core system. Hyperledger Sawtooth supports a variety of consensus algorithms, including Practical Byzantine Fault Tolerance (PBFT) (Castro and Liskov 1999) and PoET (Chen et al. 2017). The four libraries currently provided by the Hyperledger project aim to reduce the development effort in writing distributed ledger software from scratch, but can also be used to enrich the above frameworks with new functionalities or for implementing interoperability among different blockchains. Aries is a shared, reusable, interoperable tool kit designed for creating, transmitting and storing verifiable digital credentials, with the cryptographic support provided by Ursa. Quilt provides all core Java primitives required for sending and receiving payments in a ledger-agnostic manner, enabling payments across any payment network. Transact is a library used to implement virtual machines or interpreters, called smart contract engines, for processing smart contracts. Ursa is a shared cryptographic library designed to avoid duplicating cryptographic work for Hyperledger and non-Hyperledger projects, so to increase security in the process. Hyperledger provides also a set of tools to facilitate the interaction with blockchain platforms. Avalus aims to enable the secure movement of blockchain processing off the main chain to dedicated computing resources. Cactus is a blockchain integration tool designed to allow users to securely integrate different blockchains. Cello is a blockchain provision and operation system, which helps people use and manage

2 Modernizing Healthcare by Using Blockchain

37

blockchains in a more efficient way. Last but not least, Explorer is a user-friendly web application used to query and view any relevant information stored into a ledger. The most important Hyperledger project is Fabric (HLF 2020), a highly modular and configurable open source permissioned DLT platform, designed for use in enterprise contexts: its modularity is the strength of the platform, since companies can develop architectures that meet specific requirements. At a high level, Fabric is comprised of the following modular components: • An ordering service establishes consensus on the order of transactions and then broadcasts blocks to peers. The ordering service is logically decoupled from the peers that execute and endorse transactions, thus separating agreement on execution order (i.e.; ledger status) from agreement on the execution of applications. This approach is much more suitable for commercial networks than the consensus implemented for cryptocurrencies, as it allows to tailor agreement among parties in function of the specifics of business. Moreover, since the ordering service is implemented as a pluggable module, it can be chosen on the basis of the trust assumption of a particular deployment or solution. Well-established protocols for crash fault-tolerant or byzantine fault-tolerant consensus are being provided for the latest Fabric release. • A pluggable membership services provider (MSP) is responsible for associating entities in the network with cryptographic identities. The MSP defines the rules in which identities are validated, authenticated, and allowed access to a Fabric network. Each MSP makes use of a Certificate Authority (CA) and X.509 public key certificates, and there is a default CA that can be implemented through the Fabric-CA API. Organizations can however implement external CAs of their choice; as a result, a single Hyperledger Fabric network can be controlled by multiple MSPs, where each organization brings its own favorite. • A gossip protocol performs three primary functions: (i) peer discovery and channel membership management, (ii) ledger data dissemination across all peers on a channel and, (iii) peer-to-peer state transfer update of ledger data. A channel is a private “subnet” of communication among several members, with the aim of exchanging confidential transactions. Each channel has its own members, anchor peers per member, shared ledger, chaincode and ordering service. Each transaction on the Fabric network is executed on a channel, where each party must be authenticated and authorized to transact on that channel through a MSP. Each gossiped message is signed, thereby allowing participants sending faked messages to be easily identified and the distribution of messages to unwanted targets to be prevented. Peers resulting in missed blocks will eventually be synced up to the current ledger state by contacting peers in possession of these missing blocks. • Smart contracts are implemented and deployed as chaincode, which runs within a container environment (e.g. Docker) for isolation rather than on the ledger. A smart contract can be written in standard programming languages and defines the different states of a business object or asset through transactions. • The ledger subsystem can be configured to support a variety of DBMSs and comprises two components: the world state and the transaction log. The world

38

M. Ciampi et al.

state is the database of the ledger and describes the state of the ledger at a given point in time, whilst the transaction log has a blockchain structure and records all transactions, which have resulted in the current value of the world state. • A pluggable endorsement and validation policy enforcement that can be independently configured per application. A Hyperledger Fabric network can be used by different organizations forming a so-called consortium. Since not all the organizations within a consortium can be interested or permitted to share the same assets with all the others, Fabric provides the notion of channel, and allows the use of multiple channels in the same network. Each channel has its own ledger, chaincode and ordering service: only the nodes registered to a given channel can interact with the underlying blockchain, as specified by the access control, endorsement and validation policies enforced on that channel. A node can be connected to multiple channels, so it can interact with multiple blockchains maintaining a separation between them. In a Fabric network, there are two basic types of nodes: orderers and peers. Orderers are the nodes composing the ordering service, which is responsible for ordering transactions in a consistent manner so to ensure that the updates of the world state are valid after being committed to the network. Peers are the nodes that commit transactions and maintain the state and a copy of the ledger; moreover, some peers can enforce specific functions. Endorsing peers must have chaincode installed, since they simulate transactions and prepare transaction responses. Anchor peers act as gateways for the communication between different organizations connected to the ledger. Finally, leading peers use the gossip protocol to disseminate messages from the ordering service to the other peers of the same organization. As shown in Fig. 2.2, clients are applications interacting with the network through the Fabric SDK, which provides a simple API to submit transaction proposals to a ledger or query its content with minimal code. In case of a transaction proposal, the Fabric SDK sends the proposal to the endorsing peers, which verify and execute the transaction, generating an output (transaction response) which is sent back to the client. If the transaction response certifies that the endorsement policy provided for the transaction was satisfied, then the client can send the response to the ordering service. The orderers then assemble the above transaction alongside with other received transactions in a block, and send

Fig. 2.2 Transaction proposal workflow in a fabric network

2 Modernizing Healthcare by Using Blockchain

39

this block to the committers. All and only the peers that register to a Fabric channel play the role of committers for the blocks proposed on that channel. They check all the transactions encoded in a block against their world state database, reporting each as valid or invalid and updating the database only in the first case; lastly, they add the new block in their copy of the blockchain.

2.3 Needs and Tools for the Health Domain The change in the needs and expectations of the patient-citizen, mostly caused by the aging process of the population, along with the spread of the technological innovation and the development of science in the medical field, is pushing towards the definition of new models of health care and delivery of services, according to a “patientcentric” vision. In the recent years, the health domain has shown an adequate attention towards the introduction in a systematic way of communication and information technologies in the entire social and health processes (eHealth). In this context, eHealth becomes a strategic and enabling instrument for the management of the sociohealth systems. It allows not only the systematic collection and retrieval of health information, but also its correct interpretation, according to models able to support the decentralization of the care, the optimization of clinical and organizational resources and the improvement of the quality of health processes. The technological and methodological solutions currently available have several limitations, as they are not able to manage the dynamism of health processes in a synergic and intelligent way, due to the interaction between organizational flows and care protocols. These limitations are reflected in the efficiency in the use of resources and in the adequacy of the care processes, causing inhomogeneity of the care levels on the territory. The main innovations that must be provided to the health system mainly have to be able to provide: • a universal model for health focused on the person (every time, and not only for a specific clinical event); • a proactive approach to the health domain, by means of novel tools aiming at involving the patient-citizen in the care processes; • an integrated process management, by creating cooperative care models through the digital connection among all the actors involved in the prevention, treatment and follow-up processes; • a certification of the health protocols adopted and of the clinical data produced, in order to encourage a native use of knowledge technologies, which allow to offer intelligent services capable of integrating and configuring themselves dynamically with respect to the operational context with a view to socio-health care comprehension as a complex adaptive system. In light of these reasons, the health domain needs innovative IT platforms and services that comply with the most consolidate health informatics standards, able to support stakeholders in the development of innovative and natively secure, certified,

40

M. Ciampi et al.

Table 2.1 Possible solutions for the main health issues Issue

Solution

Secure sharing of health data

Consolidated syntactic and semantic interoperability models and secure protocols have to be adopted for exchanging heterogeneous information coming from different sources (like hospitals, first aids, laboratories, general practitioners, etc.), assuring unambiguity and privacy preservation

Personalized health care

Specific IT systems have to be designed to collect, process, and store patient health and wellness information in a certified manner directly in the patient’s home, in order to transfer prevention and treatment to the territory

Health processes

Advanced models and tools for the optimization, certification, and handling of the health processes need to support the decision-making phase

Evidence-based medicine

An information model have to be used for facilitating the integration and analysis of large amounts of socio-health data, based on the adoption of the Big Data Analytics paradigm

Internet of things

Practical tools have to be specifically developed to facilitate an effective integration of the data produced by the numerous existing biomedical sensors and wearable devices with other patient-related data

and interoperable eHealth applications. With reference to the problems and limitations previously exposed, such IT platforms and services will have to provide new solutions concerning a set of specific issues, as shown in Table 2.1. Blockchain technology permits to implement innovative platforms in the health domain, facilitating the management of the different phases of the health processes, identifying and certifying activities and procedures to be followed. This will facilitate above all the scheduling of the resources to be used, in order to monitor and optimize overall efficiency and effectiveness with a reduction of the major process inefficiencies in terms of time, duplication or uselessness of some phases/activities making up each process. Moreover, they will simplify the activities of medical and health personnel, also offering patients a better and faster treatment service. The certification of clinical data produced and health processes performed will permit to provide “controlled” intelligent services to doctors both in: (i) the management of decision-making processes carried out in diagnostic, therapeutic and rehabilitation practice, and (ii) the assessment of the appropriateness of the interventions to be carried out to provide patient health care. Indeed, this would allow training artificial intelligence based systems on correct, verified and shared information rather than on fake ones. This would also permit to improve the overall quality of services and to reduce health risk, ensuring alignment with reference clinical guidelines. This Section firstly provides an overview on the most important European initiatives undertaken to implement homogeneous and interoperable electronic and

2 Modernizing Healthcare by Using Blockchain

41

personal health records. Then, it illustrates the main aspects regarding clinical workflows and the importance to respect the health paths formalized, in order to follow best practices and provide a homogeneous care service.

2.3.1 Electronic and Personal Health Records EHRs offer the great advantage to make it possible for healthcare professionals to easily consult the patient’s clinical history, if they have the access right to such information. Many efforts have been performing worldwide to realize exhaustive and distributed EHR systems, even if with several critical issues. Indeed, the implementation of such systems can be really completed only with the development of numerous subsystems by many different actors (hospitals, clinical laboratories, general practitioner ambulatories, institutional authorities, etc.) and by paying much attention to user privacy. Despite this, the importance of having a great amount of clinical information available pushes the authorities to finance this kind of projects. Differently, a Personal Health Record (PHR) is devised to collect personal health information maintained by the patient, like clinical reports, annotations or data produced by biomedical sensors. They represent an important tool complementary to EHRs, considering their ability to classify and memorize all the data provided by a patient, thus offering to him/her an individual’s medical history. The main difference between EHR and PHR lies on the nature of the health information collected. EHRs gather certified clinical information produced by healthcare facilities, whereas PHRs collect information held by the patients and, for this reason, these data are not certified. So far, several PHR systems have been implemented from private enterprises or public organizations, also in order to take advantage of the widespread of biomedical sensors and wearable devices, which are able to produce great amount of physiological data. However, even if many Countries have issued norms for establishing their realization, a comprehensive technical framework for assuring the implementation of homogeneous and interoperable systems is still in progress (NCHIT 2018). Instead, many efforts have been performed in the last two decades to develop IT systems able to gather the great amount of clinical documents (like clinical reports, prescriptions, discharge letters and so on) produced by the healthcare facilities. The great part of these systems are based on the registry/repository paradigm: the digital healthcare documents are stored in repositories, which are information systems managed directly by the healthcare facilities or by more high-level organizations; a set of metadata related to such documents (including the reference to the repositories where they are stored) is memorized in a registry. These systems are typically distributed and managed by the organizations deputed at different levels to their implementation: healthcare enterprises, regional administrations, Countries. Considering that many EHR systems are implemented by different organizations, much attention has been paid in the last years by the European Commission to promote initiatives aimed at making such systems interoperable

42

M. Ciampi et al.

each other at a European level. The most important European projects focused on such a theme are described in Table 2.2.

2.3.2 Clinical Pathways Clinical Pathways (CPs) or clinical workflows represent a health methodology used everywhere, which aim at standardizing the clinical approach to provide care to specific categories of patients. More in detail, they are structured plans of care defined to realize the implementation of clinical guidelines. CPs are standardized descriptions of clinical processes for defined combinations of symptoms adapted to clinical Table 2.2 Main European projects on eHealth Project

Duration

Description

epSOS (2014)

2008–2014

The aim of the project was to update, test and evaluate cross-border eHealth services. Attention was paid to high quality services for the exchange of two main clinical documents between European Countries: (i) Patient Summary (PS) and (ii) e-prescription and e-dispensation documents

CALLIOPE network (2010)

2008–2010

The project was part of the Open eHealth Initiative, led by the health administrations of the Member States. It was initiated by 17 health authorities and 10 organizations representing networks of doctors, pharmacists, patients, industry and other stakeholders in the health sector. The project represents a targeted effort to establish an open discussion forum, properly managed, composed and structured, with the main objective of supporting the Member States in the implementation of interoperable e-health solutions, in close collaboration with the main interested parties, including users and industry

eHealth Governance Initiative—eHGI (2014)

2011–2014

The initiative established a governance structure for eHealth in Europe in order to ensure continuity of both national and international health care. This aim was pursued through the development of strategies, priorities, recommendations and guidelines aimed at providing e-health in Europe in a coordinated way (continued)

2 Modernizing Healthcare by Using Blockchain

43

Table 2.2 (continued) Project

Duration

Description

Thematic Network Antilope (2015)

2013–2015

The project was launched by the European Commission for promoting the use of standards and profiles for eHealth interoperability and their adoptions throughout the European Union. The policies concern services that are based on the availability of reliable and interpretable data exchanged between the health systems used by health professionals and patients

Trillium Bridge (2015)

2013–2015

The project aimed to align the use of standards and in particular the Patient Summary specifications between the EU and the United States, in order to share basic patient data between EU and US healthcare professionals, subject to consent from the patient. By creating a transatlantic interoperability “bridge” for sharing specifications on Patient Summary that will benefit both EU and US citizens, Trillium Bridge helped implement the EU-US eHealth roadmap and support the improvement of healthcare, economic growth and innovation

e-SENS (2016)

2013–2016

The project was launched by the European Commission and involved over 100 private actors from 22 Countries. Its aim was to consolidate the work done by the previous large-scale pilot programs, by providing generic IT solutions for cross-border communication that can be applied to any domain

EXPAND (2015)

2014–2015

The project aimed to address the challenge of moving from a series of pilot solutions projects to large-scale deployment of cross-border structures that support Member States in delivering their local e-health plans and services and providing cross-border assistance. In particular, the goal of the network was to maintain and expand existing infrastructure resources and act as a catalyst for real operational use by the Member States (continued)

44

M. Ciampi et al.

Table 2.2 (continued) Project

Duration

Description

VALUeHEALTH (2017)

2015–2017

The project was established with the aim of developing a model and a business plan for the sustainability of cross-border eHealth services. It focused on the cross-border exchange of information between Member States that foster the right to health of citizens who move within the EU and are in need of receiving health care or who are deliberately called to receive health care in a Country different from their own

Trillium Bridge II (2019)

2017–2019

The project responds to the request of the EU-US interoperability roadmap, with an exceptional consortium to further promote the interoperability of the EHR systems. Activities that revolve around IPS (International Patient Summary) standards can foster digital health innovation, reduce trade barriers and advance patient safety and confidence, bridging the gap between strategic intent and SDOs (Standards Development Organizations) action capacity that seek interoperability, quality, and safety through the adoption of standards

eHealth Digital Service Infrastructure (eHDSI)

Since 2019

The initiative was activated within the 2015 Work Programme Connecting Europe Facility (CEF). Two cross-border eHealth services were derived from the epSOS project: Patient Summary and ePrescription/eDispensing. Cross-border eHealth services are integrated end-to-end processes that deploy activities in more than one Member State and in more than one professional environment, involving both healthcare professionals and ICT professionals

conditions. They are tools that allow to outline, with regards to one or more pathologies or clinical problems, the best possible path within an organization and among organizations for taking care of the patient and his/her family. CPs lie on the concept of putting a patient in a therapeutic diagnostic path where, according to the needs and phases of the disease, the medical team defines the most appropriate therapy in agreement with the interested parties. CPs thus have the aim of representing the best temporal and spatial sequence for the patient care. CPs, according to the European Pathway Association, have to:

2 Modernizing Healthcare by Using Blockchain

45

• Include a clear explanation of the objectives and key elements of clinical healthcare based on scientific evidence; • Make an easier communication among team members, caregivers and patients; • Manage the healthcare processes by coordinating roles and implementing the activities of multidisciplinary teams; • Include documentation, monitoring and evaluation of the outcomes; • Identify the resources necessary to implement the path. • To increase the quality of clinical care, improving outcomes and promoting patient safety through the use of the right necessary resources; • To support health professionals, clinicians and care operators, by continually improving the quality of services and safeguarding high standards of care. One of the main purposes of the application of Information and Communication Technology (ICT) in the healthcare domain is to improve quality in the patients’ continuity of care. ICT can be the enabler for an amplified personalization within a communication network, improving the overall coordination of shared treatment activities and the degree of participation of the diverse stakeholders such as patients, care providers, healthy people interested in prevention or fitness (Schlieter et al. 2017). Clinical pathways are being applied in different medical domains. However, their application is typically difficult without an appropriate ICT environment, such as health information system or an appropriate IT architecture. Without a system able to support the physicians in using efficiently the collected data, performing actions, analyzing results, and so on, is very complex to implement the follow-up of the clinical process defined throw a specific clinical pathway. CPs are devised to support the professionals in this complex procedure: the design of the path, the execution, the evaluation of the different parameters that could lead to an improvement of the pathway and the possibility of managing the patient’s conditions with respect to the specific identified needs. In addition, this process has to be performed in complete security. The more salient benefits of CP include improved patient involvement in treatment procedures, reduced hospitalization times, improved overall medical quality, reduced medical costs, reduced incidence of poor practices, and provision of clinical training tools (Fico et al. 2016). While patients’ journeys should be carefully led according to CPs planned on evidence based guidelines, EHRs have the ability to track such journeys. For this reason, much effort has been putting to integrate clinical workflows with the patient’s EHR (Ainsworth and Buchan 2012). The integration and use of care plans with health information systems would allow supporting a multidisciplinary team of professionals and informal caregivers across a range of statutory, private, or voluntary organizations along all phases of the care process (i.e. from prevention, to rehabilitation; inpatient, outpatient and home care) (Billings 2005; Kodner and Spreeuwenberg 2002). In the recent years, the use of clinical pathways has gradually changed, from a central concept of care to one process-oriented and coordinated healthcare among different heterogeneous systems, which are diverse departments, hospitals, and systems (Kinsman et al. 2010; Panella and Vanhaecht 2010). This change leads to

46

M. Ciampi et al.

the improvement of the decision making process of physicians, helping to adapt the medical treatment for the patient’s needs. Studies show the reasonableness of interdepartment pathways in terms of decreasing lengths of hospital stays or a better coordination of the whole care procedure (Rotter et al. 2010; Rotter 2013). The use of care plans among different departments and systems has allowed improving the quality of patient care. Once the most suitable treatment path for the specific problem (such as pathology, disease, state of health, etc.) is identified, it is essential that all health professionals who are part of the process and the patient follow the whole workflow. In the same manner, logging all the actions undertaken for patient care is necessary for research purposes and the improvement of the process itself, as well as for identifying responsibilities in a care plan. The ability to update the treatment plan is also essential to follow the specific needs of a patient during the start of the treatment path or during the therapy, in order to set the treatment plan with respect to any patient’s needs, thus obtaining a personalized dynamic pathway. These ones are flexible tools that go beyond the traditional installation of clinical pathways. The management of care plans through a health service architecture has to support the personalization of care for specific patient requirements, as well as the addition of patient interactions with the care process, in order to achieve objectives that bring healthcare to improve the quality of care. An integrated environment in which the healthcare treatment can represent the link among different departments in the process of a specific patient treatment, as well as the possibility of making the patient fully experience for her/his path, allows realizing the so-called patient empowerment. It is a key element allowing patient to acquire trust towards the therapy to be followed and towards the IC technologies to be used in order to improve the quality of care. Moreover, it is the core element to decrease the risk of the escalation of the pathologies, especially of comorbidities (Chaudhry et al. 2006). Figure 2.3 shows an example of care plan modeled according to the OMG BPMN 2.0 standard, which may be represented in a CP document. It is possible to note that the all the care journeys carried out from the patient follow strictly the planned path:

Fig. 2.3 Example of a care plan

2 Modernizing Healthcare by Using Blockchain

47

from a general visit by the General Practitioner (GP) to a diagnostic exam performed by a specialist center or to a medication dispensed by a pharmacy. The definition of the IT services architecture based on informatics health standards (such as HL7, FHIR, IHE, etc.) and on the use of blockchain technologies will allow in a simple way to make the care plans: (i) interdisciplinary (among different departments and systems); (ii) connected to each other, and consequently allowing interaction among different actors (such as doctors with diverse specializations) with different roles, in order to favor the second opinion, use different medical skills and permit the communication in an easy manner. In addition, an enabling platform able to track all the phases of a clinical workflow would allow incentivizing and enticing the patient to take part in the treatment process: in this way, it would be possible to obtain the trust from the patient and therefore increase the probability that he/she correctly follows the therapy. Then, it would increase the degree of personalization of the clinical pathway in a secure way. The use of blockchain technology in the architecture of such a platform would offer the following important benefits: • Identification of an integrated and verified treatment plan; • Management of care paths in a secure way, by satisfying confidentiality and integrity; • Log all the operations carried out on the clinical pathways for subsequent analysis phases, useful to certify the actions taken in the care process and possibly identify responsibilities in the process; • Guide physicians and patients to comply with the specific treatment plan identified; • Verification of the correct application of the CP specific to the situation: the system made up of blockchain technology is in fact able to identify a deviation from the modeled CP and thus notify the observed deviation.

2.4 Standards Many health informatics standards have been produced by the Standard Developing Organizations (SDOs) to assure homogeneous implementation and interoperability of health IT systems. These standards provide important benefits in the development of homogeneous, interoperable, reusable IT systems for healthcare. For this reason, they are used to implement health record and workflow systems. These standards have to be used and integrated with all the new technologies (like blockchain) introduced in a health domain to implement additional IT applications. This Section illustrates the most recent health informatics standards and technical specifications, which refer to clinical data representation and care planning: HL7 FHIR and IHE PCC DCP.

48

M. Ciampi et al.

2.4.1 Fast Healthcare Interoperability Resources Fast Healthcare Interoperability Resources (FHIR) is a new generation standards framework developed by Health Level Seven (HL7) International, which provides interoperability specification for the exchange of electronically healthcare information. The main goal of FHIR is to simplify the implementation of health IT applications, without sacrificing information integrity. It provides a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications. In FHIR, a basic building block is a Resource, which is designed to provide a standard method to communicate various pieces of health information. A resource is a FHIR entity that can be used to store and exchange data in order to manage healthcare information and processes, both clinical and administrative. A resource is univocally identified and contains a set of structured data items and a human-readable XHTML representation of its content. These resources can easily be assembled into working systems that solve real-world clinical and administrative problems. The FHIR basic philosophy is the expression of the following key concepts: (i) focus on developers; (ii) support for common scenarios; (iii) leverage web technologies; (iv) human readability as a basis for interoperability; (v) making content available for free. FHIR represents a step forward in the world of healthcare, a push to pass from offline to online, from PC to tablet, from the web to apps, from desktop to cloud. About transparency of data, it acts as an ‘open API’ to access the data present in the various EHR systems (silos-like). About analytics, FHIR uses data structures that allow to dissect and decompose information for data analysis. FHIR offers several improvements over existing standards, in particular: (i) a strong focus on implementation; (ii) multiple implementation libraries with many examples; (iii) the specification is free; (iv) interoperability out-of-the-box—base resources can be used as are, but can also be adapted for local requirements; (v) evolutionary development path from HL7 v2 and CDA—standards can co-exist and leverage each other; (vi) based on web standards like XML, JSON, HTTP, Atom, OAuth, etc.; (vii) support for RESTful architectures and seamless exchange of information using messages or documents; (viii) concise and easily understandable specifications; ix) based on a human-readable format for ease of use by developers; (x) solid ontology-based analysis with a rigorous formal mapping for correctness. The current version of the FHIR specifications is 4.0.1—Technical Corrections to R4: Oct-30, 2019, available on the website (HL7 FHIR 2020). The specifications are organized into several levels; each of them detail a particular aspect of the standard. Level 1 is responsible for the overall infrastructure of the FHIR specification, maintaining the basic documentation for the FHIR specification. Level 2 supports implementation and binding to external specifications. Level 3 links real-world concepts in the healthcare system. Level 4 gives resources to record and exchange data for the healthcare process. Level 5 provides the ability to reason about the healthcare process. The main concepts of the FHIR standard are described below.

2 Modernizing Healthcare by Using Blockchain

49

Resources Resources are the smallest discrete concepts that can be maintained independently. They are collected in the following classes: • Administration: covers basic data that can be represented in FHIR, such as Patient, Practitioner, CareTeam, Device, Organization, Location, Healthcare Service; • Clinical: contains clinical records (e.g. Allergy, Procedure, CarePlan/Goal, ServiceRequest); • Diagnostics: holds clinical diagnostics, including laboratory tests, imaging, and genomics; • Medication: contains the ordering, dispensing, administration of medications; • Workflow: includes the resources for managing assistance processes (e.g. appointment, order, encounter, etc.); • Financial: supports billings and payments (e.g. coverage, claim, etc.); • Clinical Reasoning: permits to provide the ability to reason, such as artifacts of clinical knowledge, clinical decision support rules, quality measures, etc. Data Types The data types are used for categorizing the resource elements. They are organized into the following four categories: • • • •

Simple/primitive types, which are single elements with a primitive value; General-purpose complex types, which are re-usable clusters of elements; Metadata types, which are a set of types used with metadata resources; Special purpose data types, which are defined elsewhere in the specification for specific usages.

Bundling A common operation performed with resources is to collect them into a single instance, containing correlated data with respect to a specific context. In FHIR, this is called “bundling”, i.e. a group of resources. The “Bundle Resource” includes the whole content of all resources, not only their metadata and references. Profile Another important aspect of the FHIR specifications concerns the concept of Profile. Profiles are part of the standard that describe the adoption of FHIR in particular use cases. Some specific use cases are common or important enough to be described as a part of the specification itself. A FHIR profile is thus a set of rules that allow a FHIR resource to include specific constraints or extensions, so that additional attributes can be added.

50

M. Ciampi et al.

2.4.2 IHE PCC DCP Integrating the Healthcare Enterprise (IHE) is an international organization promoted by healthcare professionals and industries with the aim of improving the way computer systems in healthcare share information by using consolidated standards (IHE 2020). IHE is organized by clinical and operational domains, where interoperability and issues related to clinical workflows, information sharing and improved patient care in the respective areas of healthcare is addressed. Each domain develops and maintains its own set of Technical Framework (TF) documents. The current IHE domains are: Cardiology; Dental; Eye Care; Endoscopy; IT Infrastructure (ITI); Pathology and Laboratory Medicine; Patient Care Coordination (PCC); Patient Care Device (PCD); Pharmacy (PHARM); Quality, Research and Public Health (QRPH); Radiation Oncology; Radiology. IHE is based on a process in which dedicated groups gather case requirements, identify standards and develop technical specifications. The documents produced, named Integration Profiles, describe the solutions individuated to interoperability problems. These documents specify how actors use standards to address a definite healthcare use case, by exchanging a set of structured messages named transactions. It is worth noting that in IHE a transaction is an interaction between actors that transfers the required information through standards-based messages. Numerous transactions are specified by IHE: they are used within the Integration Profiles to formalize how the actors interact with each other to exchange information. The Integration Profiles are published by each IHE domain as part of their TFs. The publication process is organized in different states (IHE Wiki 2020): • Final Text (FT): stable; • Trial Implementation (TI): frozen for trial use; changes permitted prior to FT; • Public Comment (PC): a TI profile republished or a new profile published for receiving public comments; • Draft Supplement: not yet ready for Public Comment; • Deprecated/Retired: no longer recommended or maintained by IHE. Vendors can evaluate the conformance of their implementations of Integration Profiles with respect to the technical specifications during periodical events named IHE Connectathons, which provide a detailed implementation and testing process. These events are organized annually by the Associations affiliated to IHE International, which are IHE Europe, IHE North America, IHE South America, IHE Asia-Oceania, IHE Middle East. The broad diffusion and adoption of IHE specifications in Europe is evidenced by the European Commission Norms Commission Decision (EU) 2015/1302 of 28 July 2015 on the identification of ‘Integrating the Healthcare Enterprise’ profiles for referencing in public procurement and Commission Recommendation (EU) 2019/243 of 6 February 2019 on a European Electronic Health Record exchange format, which identified 27 IHE Integration Profiles as reliable means of electronic exchange of information.

2 Modernizing Healthcare by Using Blockchain

51

General clinical care aspects such as document exchange, order processing, workflows and coordination with other specialty domains are dealt within the IHE PCC domain, sponsored by HIMSS (Health Information Management Systems Society) and ACP (American College of Physicians). Some solutions to these issues have been described in numerous Integration Profiles (IHE PCC 2020). Specifically, the structures and transactions for care planning, creating, updating and sharing Care Plans that meet the needs of interested users are provided in the Dynamic Care Planning (DCP) Integration Profile, whose Revision 3.1 was published in September 2019 as Trial Implementation (IHE PCC DCP 2019). The DCP profile permits to dynamically update Care Plans by the different actors involved in the care processes each time a patient interacts with the healthcare system. The profile takes advantage of these standards: • From a functional point of view, it is based on HL7 Service Functional Model: Coordination of Care Service (CCS) (HL7 CSS 2018); • With regards to the data model, it derives its concepts from the HL7 Care Plan Domain Analysis Model (DAM) (HL7 DAM 2016); • With concerns to technical aspects, the profile is based on HL7 FHIR Resources and transactions. The data that a system compliant to IHE PCC DCP has to be able to process have to be represented in the following HL7 FHIR resources: • CarePlan: tool used by clinicians to plan and coordinate care for an individual patient; • PlanDefinition: contains an action definition that describes an activity to be performed; • ActivityDefinition: specific actions to be performed as part of care planning. The actors formalized in this profile are described below: • Care Plan Contributor: reads, creates and updates Care Plans and Plan Definitions, generates Care Plans and requests resources based on a selected activity definition; • Care Plan Service: manages Care Plans received from Care Plan Contributors and provides updated Care Plans to subscribed Care Plan Contributors; • Care Plan Definition Service: manages Plan Definitions received from Care Plan Contributors and provides updated Plan Definitions to subscribed Care Plan Contributors; • Care Team Contributor: reads, creates and updates Care Teams; • Care Team Service: manages Care Teams received from Care Team Contributors and provides notification of updates and access to updated Care Teams to subscribers.

52

M. Ciampi et al.

2.5 Managing and Monitoring Health Records The management and monitoring of health processed information are complex activities because they provide for the adoption of specific mechanisms to guarantee the security and control of the actions about health data. In the healthcare context, it is essential to adequately manage data qualitatively as well as quantitatively. For this reason, it is necessary to assure the integrity and availability of health data, as well as confidentiality, being the health data contain sensitive information. The management of health information must be monitored so as to allow the identification of the users and the operations on health data done (creation/update/cancellation), in this way performing the so-called integrity monitoring. At the same time, the operations carried out by the user who reads the data must also be monitored and controlled, in order to provide data confidentiality. This Section provides information related to the way health records should be securely managed and monitored in a standard way. Thus, the concept of security (in particular, integrity and confidentiality) will be explored by adopting the FHIR standard. The next Section illustrates how these issues can be satisfied by using blockchain technology.

2.5.1 FHIR Security and Privacy FHIR takes in due account security issues. Specifically, authentication and authorization of the actors on the system are a necessary requirement. FHIR defines exchange protocols and content models to be used with the well-known IT security protocols. Among these, there are: • Time Keeping, using NTP/SNTP; • Communications Security: all data exchanges must be protected via TLS (e.g. HTTPS); • Authentication: the use of OAUTH is recommended; • Access Control: defines a Security Label infrastructure to support access control management, in addition to the extended CRUD (Create, Read, Update, Delete) scheme; • Audit: defines useful resources for auditing (audit event and provenance). The mechanisms to guarantee privacy and security directly depend on the analysis of the requirements of the specific system to implement and must protect against the security risks of the data to protect. FHIR is based on a RESTful protocol: each of the wide set of clinical, administrative, financial, and infrastructure resources formally defined has a different protection requirement. It supports basic operations on resources, so assuming that adequate protocols like OAuth and TLS are in place to authenticate parties and protect their communications. Thus, it is sufficient to define

2 Modernizing Healthcare by Using Blockchain

53

an appropriate access control mechanism to properly guarantee the supported operations (for example, concerning the Query and Read operations, the FHIR standard classifies the resources in several classes). Business Sensitive Resources This typology is characterized by resources that contain business (referring to companies, organizations, offices, or groups) and sensitive data. Therefore, these resources require client-side authentication to ensure that only authorized actors are granted access. FHIR indicates possible client authentication methods, such as: TLS with mutual authentication, APIKey, JWT with signed app or JWT OAuth client ID per app. Individual Sensitive This typology refers to resources that do not contain patient data, but provide information about other process participants. Example of such resources are: Practitioner, PractionerRole, CareTeam or other type of users. Access to these other identities is often regulated by appropriate company rules. To this purpose, the access to the individuals represented by these resources will tend to be role-specific. For this reason, it is important using appropriate access control mechanisms based on roles or attributes. Patient Sensitive Most FHIR resources belong to the “Patient Sensitive Class”. These resources contain very sensitive or are linked to very sensitive health information. They use security labels to differentiate various confidentiality levels. Access to these resources requires that the user expresses the “purpose of use”, controlled by a privacy consent. Not Classified These resources do not fall into any of the above classifications, as their sensitivity is highly variable. These resources need special management. They are often used to describe content in a way that can be used for access control decisions. The resources and mechanisms presented above provide the foundation elements to design a FHIR-based blockchain network able to assure the realization of health business processes in a secure, standard and structured way.

2.5.2 Authentication and Access Control FHIR servers should authenticate clients: to this aim, they can either (i) authenticate and trust the client system or (ii) authenticate the individual user with a variety of techniques. For web environments, the standard recommends using OpenID Connect. It also recommends using OAuth to authenticate and/or authorize the client and user. The Smart-On-FHIR profile on OAuth is a recommended method for using OAuth. The OAuth 2.0 protocol framework defines a mechanism to allow a resource owner to delegate access to a protected resource for a client application, optionally

54

M. Ciampi et al.

limited by a set of scopes. This specification profiles the OAuth 2.0 protocol scopes to be used with the FHIR protocol to increase baseline security, provide greater interoperability, and structure deployments in a manner specifically applicable to (but not limited to) the healthcare domain (Richer and Mandel 2018). A set of privacy and security specifications are developed: they allow authorization to access the health data sharing features made available through the RESTful API (https://openid.net/ wg/heart/). The correct identification of an actor on a system is one of the bases on which the security system is based. In fact, most security applications (authentication, access control, digital signatures, etc.) are based on the correct mapping between the relevant resources and the underlying systems. The data owner should not allow the disclosure of data unless there are sufficient guarantees that the other party is authorized to receive it. This applies to a client that creates/updates a resource via PUT/POST, as much as it is managed by a server that returns resources required via GET. Two of the classic Access Control models are Role-Based Access Control (RBAC), where the access policies are based on the role assumed by a user, and Attribute-Based Access Control (ABAC) (Esposito et al. 2013; Shen & Hong 2006), where the access policies are evaluated by analyzing several attributes of the user (and not only on the role). Some other access control models have successfully been proposed (Namasudra 2019). A possible approach to create a specific access control model, accompanied by appropriate security policies, is through the use of the FHIR API. In particular, HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. HAPI FHIR 3.8.0 introduces a new interceptor framework that is used across the entire library. Interceptor classes may “hook into” various points in the processing chain in both the client and the server. The interceptor called Authorization Interceptor permits to determine preliminarily whether a user has the appropriate permission to perform a given task on a FHIR server. This is done by declaring a set of rules that can selectively allow (whitelist) and/or selectively block (blacklist) the access to a resource. The Authorization Interceptor, opportunely used, is an important mechanism that can be used to intercept a client request sent to a server in order to: (i) apply the access control policies in order to grant or deny the access to a health service/resource requested by a user (for example, a service able to return a clinical report or a set of metadata related to a patient); (ii) send the same request to the blockchain network, with the aim of recording the operation, as shown in Fig. 2.4. This way, the authorization protocol can be performed in two phases: (i) one at application level (that is, health business level); (ii) one at network level (that is, blockchain level).

2.5.3 Integrity and Auditing FHIR provides an AuditEvent resource used for event logging. This audit logging action records specific details when the event occurs to ensure security and privacy.

2 Modernizing Healthcare by Using Blockchain

55

Fig. 2.4 The FHIR authorization interceptor

This form of audit logging records details about the security event that happened. The AuditEvent can then be used by authorized applications in order to support audit reporting, alerting, filtering, and forwarding. This model is developed and used by the widespread IHE ATNA profile. The events of the ATNA logs can be automatically converted into FHIR resources and therefore the applications are able to search for audit events or to register for notifications. As regards HTTP logs, developers need to consider the implications of distributing access to the logs, in fact, HTTP logs should be regarded as being as sensitive as the resources themselves. Therefore, FHIR allows, through the appropriate use of the AuditEvent resource, to guarantee the data integrity on the system, by using the hash attribute of the resource. It is hard to guarantee integrity at the health process level, because there are different resources and actors that take part in the process. A platform based on the FHIR framework and blockchain technology would permit to assure integrity at a process level, satisfying the key needs of the health domain, such as interoperability of data and applications, structured data, unambiguous representation of information.

2.6 FHIR Resource Management with Hyperledger Fabric As illustrated in the previous Section, the integrity protection of healthcare data and processes is a key factor for the success of digitized medicine and medical research. Diagnostic processes and care plans can be more easily implemented, controlled and updated by assuring that medical records and the actors, actions, devices and circumstances producing and/or consuming them are reliably tracked through a kind of tamper-proof ledger. Effective and efficient tools rooted in blockchain concepts can be designed to promote research integrity values in medical sciences; indeed, the concept of transaction can be used to encode a potential cause-effect relation that can

56

M. Ciampi et al.

later be analyzed with backward reasoning. By one side, the recording of data and procedures should mitigate the physician’s or scientist’s bias on the outcome, or the tendency to rule out data which do not support the hypothesis, or even the failure to estimate quantitatively systematic errors. On the other hand, feedbacks from patients and records of their significant health parameters can be comprehensively collected, analyzed and correlated to care processes. FHIR resource management can greatly benefit from the adoption of blockchain networks, since these can be used to enforce resource authentication and the integrity of their related workflows, which are two aspects not covered by the standard. FHIR is devoted to interoperability for the exchange of electronic healthcare information, and this goes well with the decentralized nature of a permissioned blockchain network, where code and data are replicated among a set of authorized parties and kept synchronized without a central authority by means of a consensus protocol. The model of trust better fitting with modern healthcare ecosystems is indeed that realized through open consortia, where well-recognized healthcare providers (hospitals, nursing homes, diagnostic centers and medical associations) cooperate in order to offer a multidisciplinary, flexible and complete care support. As detailed in Subsect. 2.2.2, Hyperledger Fabric was designed so that a network can be worked under a governance model based on the trust among the participants, such as a legal agreement or framework for handling disagreements, although the participants may not fully trust one another. This is precisely the trust model of open consortia. The multi-channel architecture of Hyperledger Fabric allows the various kinds of FHIR resources to be managed independently, sharing them among different participants and according to specific access control policies. This way, interoperability can be achieved without sacrificing privacy, and the backbone network supporting FHIR services can be built incrementally over time in a modular fashion with respect to managed resources (i.e.; number of services) and the set of participants and their roles.

2.6.1 Coupling FHIR Services with Fabric Channels FHIR specifications are based on the REST architectural style (RESTful): for this reason, the kind of possible operations that can be performed on a resource are the same for each resource type. This aspect permits to manage the resources in a highly granular fashion. Such operations are carried out by means of client/server interactions based on the HTTP primitives (like GET, PUT, POST, DELETE): they can be relative to interaction types, interaction instances or the whole system (as shown in Table 2.3), and collectively constitute the Resource-Oriented Architecture based on the FHIR API. Coherently with context and scope of the standard, this API does not directly address authentication, authorization, and audit collection; nor it provides methods for assuring the integrity of information supplied by servers: implementers can choose which of the interactions are made available, and which resource types are supported by servers.

2 Modernizing Healthcare by Using Blockchain

57

Table 2.3 The FHIR RESTful API Instance Level Interactions Type Level Interactions

read

Read the current status of the resource

vread

Read the state of a specific version of a resource

update

Update an existing resource

patch

Update an existing resource with specific changes

delete

Delete a resource

history

Retrieve the change history for a specific resource

Whole System Interactions

create

Create a new resource

capabilities

Get a capability statement for the system

search

Search the resource type on the basis of specific criteria

batch/ transaction

Update, create or delete a set of resources

history

Retrieve the change history for a specific resource type

history

Retrieve the change history for all resources

search

Search across all resource types on the basis of specific criteria

In order to realize an integrated architecture based on a blockchain network able to address the needs outlined in Sect. 2.3, Hyperledger Fabric may be used to act as a network underlying the application layer implemented with FHIR, and upon which FHIR services rely for the integrity and the proper synchronization of the resources that they provide and share among the set of participants. Each FHIR server is coupled with one or more Fabric peers through a Fabric client, which acts as an interface between the FHIR and the Fabric layers. The Fabric client is in charge of intercepting the interactions with the FHIR server and issuing appropriate transaction requests on a suitable Fabric channel (as defined in Subsect. 2.2.2). The Fabric channel is selected on the basis of the FHIR resource being managed, whereas the transaction request depends on the type of interaction performed on the resource. Using different channels for different resources is not mandatory; however, it should help in defining integrity protection controls, which are tailored for the specific workflow of a given resource. Different Fabric channels can indeed implement in a different way the transactions corresponding to the same FHIR interactions through

58

M. Ciampi et al.

Fig. 2.5 The hyperledger fabric—HL7 FHIR integrated architecture

a diverse chaincode, whilst each channel can have its own set of participants and access control policy. The integrated architecture is shown in Fig. 2.5. One main point in this design is the choice of the FHIR resources, or part of them, that must be coded as Fabric assets. For the purpose of data and process integrity, it is not efficient to store on the ledger the full specification of a resource, since it can consist of many elements, and some of them are quite narrative and not important to be recorded as such. Blockchain ledgers are not usually designed to store large assets, since they are intended to log transactions (i.e.; state changes in assets) for large amount of time and in a replicated way, and this can easily result in large amounts of data and scalability issues. Resources are already stored and managed by the FHIR server, thus replicating them on the Fabric ledger would only result in a harmful computational and storage overhead. Moreover, FHIR resources are closely related to each other: it is often the case that a FHIR resource contains references to other FHIR resources, which can be managed by the same server or even by a remote server. Fully reproducing these interdependencies at the blockchain layer would be too complex and useless, since this is managed by the application layer. Thus, it is mandatory in this proposed approach to select a few primary FHIR resources on which the others depend and keeping explicitly track on the ledger only of the first ones. Another main point in the proposed design concerns how resource instances are named and addressed in the context of a single server and the overall network. The name space has to be defined not only to avoid name collisions under the assumption that FHIR servers give names independently from each other to newly created instances, so to get globally unique assigned names. A more stringent requirement is that the naming convention must not disclose sensitive information (e.g.; patient identifiers) and must be immune to enumeration attacks. The proposed approach involves

2 Modernizing Healthcare by Using Blockchain

59

resource names consisting of three parts: a prefix that uniquely identifies the FHIR server in the network and its service,1 a unique pseudo-random string (nonce) in the namespace of the server to univocally identify each resource managed by the server, and a sequential integer that identifies the version of the given resource. This naming schema is compatible with the FHIR standard and major naming conventions for computer networks (e.g.; DNS).

2.6.2 Participant Management A final relevant point of the design concerns participants in the Fabric network. Being a permissioned blockchain, Fabric relies on Member Service Providers to manage the identities of participants, which in turn are constructed from public-key certificates and a X.509 public key infrastructure. Managing the identities at the application layer through Fabric would result in a large-scale, time-varying process which is quite cumbersome to administer via the MSPs, and that it would also significantly deviate from current standards. As detailed in Subsect. 2.5.2, FHIR applications have their own authentication and authorization requirements that are very different from those concerning a permissioned blockchain network. FHIR recommends to use OAuth 2.0 (Hardt 2012) to authenticate and/or authorize the client and user. Moreover, for the purpose of data and process integrity, handling user authentication and authorization at the Fabric layer is completely useless, whereas it is instead important to keep track of “who does what” in the ledger, where “who” and “what” are defined at the application layer. The identities managed at the Fabric level will be therefore those concerning the FHIR servers operating at the application layer, which will be casted as Fabric clients, plus those related to the peers and orderers composing the Fabric network, as provided by the organizations belonging to the consortium defined at the application layer and enforced at the blockchain layer. This way, the FHIR layer has the aim of managing participants at business level, whereas the Fabric layer at network level.

2.7 Case Study: IHE PCC DCP This Section illustrates a case study in which a two-tier blockchain-based platform implemented on the top of FHIR and Fabric is opportunely designed to effectively manage care plans, by respecting the health informatics standards, health requirements, security and privacy.

1 It may

be the case that a single server offers multiple services (i.e.; resources): thus it is important to distinguish among different services deployed by the same server, for example through FHIR resource acronyms.

60

M. Ciampi et al.

The IHE Dynamic Care Planning (DCP) Profile provides the structures and transactions for managing and sharing care plans that meet the needs of providers, patients and payers. As illustrated in Subsect. 2.4.2 and fully detailed in (IHE PCC DCP 2019), this profile is built around the HL7 FHIR Care Plan resource and is made up by the Care Plan, Care Team and Care Plan Definition services. Care Plan captures basic details about who is involved and what actions are intended in a care planning, without dealing in discrete data about dependencies and timing relationships. A Care Plan can be dynamically created from tools used to support evidence-based practice, allows the inline definition of activities using the activity.detail element, and is updated by the Care Plan contributors. The Care Plan contributors constitute a Care Team, which can be made up of a single individual (e.g.; a self-caring patient), a single group of individuals or multiple groups of individuals providing various types of services. In the context of DCP Profile use cases, it is therefore natural to consider Care Plan as the primary resource that needs an explicitly track on the ledger through a dedicated Fabric channel. On this basis, the other external FHIR resources characterizing it are managed by means of a suitable cryptographic hash values, so to get the overall integrity of the plan. It is worthwhile to note in this respect that retrieving an external resource and computing its hash value is only required if such a resource is not managed with integrity protection by its related server. Otherwise, it will suffice to guarantee the integrity of the reference to the resource by explicitly tracking it into the ledger, without communication and computing overhead. The architecture of the proposed platform is shown in Fig. 2.6. It is composed of the following components:

Fig. 2.6 The proposed two-tier architecture for care plan management

2 Modernizing Healthcare by Using Blockchain

61

• REST Interface: represents a REST server able to receive requests and send responses according to the FHIR protocol; • Authorization Manager: is deputed to verify the access rights to the resources; • Storage Manager: interacts with the FHIR DB for storing/retrieving FHIR resources; • Asset Composer: has the aim of coupling a service managing a primary FHIR resource to a Fabric channel of the same name; • FHIR DB: is a database where FHIR resources are stored; • Digest Analyzer: computes and verifies the digests of the FHIR resources; • Transaction Management: identifies the Fabric transactions to be performed according to the user request; • Fabric Ledger: is a distributed and shared registry where transactions are immutably stored. A high level sketch of the interactions among the components is illustrated for the Care Plan create/upload workflow in Fig. 2.7. However, it should be noted that the architecture depicted in Fig. 2.6 is valid for any FHIR resource or service, although its implementation can vary and, at the time of writing, it was developed only for the Care Plan resource in the context of the IHE DCP Profile. A request containing a FHIR Care Plan resource, sent through the REST Interface, is intercepted by the Authorization Manager, in order to verify if the user has the rights to access the service. In this case, the request is sent to the Storage Manager, which parses the incoming FHIR transaction and, depending on the request type, it creates or updates the FHIR DB resource database. Then, using a resource specific configuration file, the Digest Analyzer interface selects the elements of the resource

Fig. 2.7 Software components interactions for creating/updating a care plan

62

M. Ciampi et al.

that have to be explicitly tracked in Fabric and computes some digest values through the use of an hash function, thus obtaining a memory buffer that encodes the Fabric asset (named Resource Digest), which corresponds to the resource targeted in the FHIR transaction (Care Plan Digest in Fig. 2.7). The FHIR interface is also in charge of assigning names (Resource ID) to newly created resources and their related Resource Digests, according to the naming schema described in Subsect. 2.6.1. The Fabric interface of the Asset Composer represents the client of the Fabric channel implementing the tamper-proof logging for a given FHIR resource or service. It is called by the FHIR interface with the Resource ID and the string encoding the Resource Digest as parameters, and it returns to the caller a status condition. This interface makes use of the Fabric SDK to connect to the Fabric network, access to the channel provided for the given resource, and submit transactions, trough the Transaction Manager, to the ledger according to the application transactions intercepted by the FHIR interface. Figure 2.7 shows two types of transactions: create and update. Fabric transactions are then managed by the peers and endorsers composing the network, with chaincode installed and instantiated on the endorsing peers which is appropriate for the processing of the given resource.

2.8 Conclusions A crucial aspect for the improvement of the health domain is to make medicine predictive, preventive, personalized and participatory (P4-medicine). An enabling factor to reach such an objective is represented by the availability of operating platforms connecting the various actors, actions, devices and circumstances producing and/or consuming health records, while guaranteeing the authenticity of the information acquired and its correct processing in compliance with current regulations and health informatics standards. Distributed ledger technologies, and in particular permissioned blockchain platforms, have the right requirements but must be correctly deployed and implemented in order to solve some technological and research problems that stand in the way of their effective use. Most important, these technologies can be used only for the network layer, and they have to be appropriately integrated with the application layer to get the required platforms. In this chapter, potentialities and challenges of integrating the emerging health informatics HL7 FHIR standard in distributed ledger technologies are explored. The great advantage of such an integration is to satisfy an important necessity for the health domain: certify and verify the clinical events occurred for development of the health processes. After introducing concepts, frameworks and current challenges for distributed ledgers and the health domain, the adoption of FHIR for the particular use case of dynamic care planning, as defined in the IHE DCP profile, is illustrated. Then, in order to show how blockchain technologies can be used to enforce the authentication of FHIR resources and the integrity of their related workflows, a concrete example of integration of the permissioned blockchain platform Hyperledger Fabric with some of the services considered by the IHE DCP profile is provided.

2 Modernizing Healthcare by Using Blockchain

63

Key Terms and Definitions Blockchain: A special kind of distributed ledger technology, where the ledger composes of a linked list of transaction blocks. Transaction records are grouped in blocks, and each block contains the fingerprint of the previous block realized by means of a system-wide cryptographic hash function. Because of the properties of the hash function, if the last block in the chain is supposed to be uniquely generated and unforgeable, then this occurs with high probability for all the other blocks, and the overall blockchain is both unique and unforgeable. BFT Protocol: A consensus scheme where the peer in charge of taking the next action (e.g.; uploading the new block to a blockchain) is selected via explicit communication rounds among participants. These protocols have a marginal computing cost and result in a definite agreement, but scale poorly in the number of participants. Clinical Pathway: Represents a health methodology used everywhere, which aims at standardizing the clinical approach to provide care to specific patients’ categories. A clinical pathway is a multidisciplinary management tool based on evidence-based practice for a specific group of patients (for example characterized by a pathology), in which the different tasks (clinical actions, therapies and others) to be carried out for the treatment of the patient is well defined and optimized. The clinical pathways can vary from the simple use of drugs to a complete treatment plan with indication, for example, of clinical tests to be carried out. Clinical pathways aim at greater standardization of therapeutic regimens as well as at better results, both from the point of view of quality of life and from the point of view of clinical results. Distributed Ledger: An append-only log of transactions, which is replicated among multiple nodes, alongside with the code (smart contracts) implementing transaction logic. These nodes constitute a network of peers with respect to the management of the ledger, and are usually spread around different geographical sites and institutions. This way, a decentralized management of authority and trust can be enforced: participants share a consistent historical register of data processing, and the smart contracts producing it, using a consensus protocol to agree on the validity of transactions and their order on the ledger. The enabling technology consists in a set of data structures, protocols and networking technologies that, when appropriately combined, give rise to a distributed ledger system. Proof of X: An algorithm for block proposal where the uploader is selected through a sort of cryptographic puzzle, whose solution requires a cost in terms of some specific resource of participants (e.g.; computational power, owned coins, network bandwidth).

64

M. Ciampi et al.

References Ainsworth, J., & Buchan, I. (2012). COCPIT: A tool for integrated care pathway variance analysis. Study Health Technology Information, 180, 995–999. Antilope. (2015). Advancing eHealth Interoperability Available at: https://www.antilope-project. eu/front/index.html. Bentov, I., et al. (2014). Proof of activity: Extending bitcoin’s proof of work via proof of stake [extended abstract]. ACM SIGMETRICS Performance Evaluation Review, 42(3), 34–37. Bentov, I., Gabizon, A., & Mizrahi, A. (2016). Cryptocurrencies without proof of work. In International Conference on Financial Cryptography and Data Security (pp. 142–157). Springer, Berlin, Heidelberg. Billings, J. (2005). What do we mean by integrated care? A European interpretation. Journal of Integrated Care, 13(5), 13–20. CALLIOPE Network. (2010). CALL for InterOPErability. Available at: https://www.eu-patient.eu/ whatwedo/Projects/completed-projects/CALLIOPE-Network/. Castro, M. & Liskov, B. (1999). Practical Byzantine fault tolerance. In OSDI (Vol. 99, No. 1999, pp. 173–186). Chaudhry, B., et al. (2006). Systematic review: Impact of health information technology on quality, efficiency, and costs of medical care. Annals of Internal Medicine, 144(10), 742–752. Chen, L. et al. (2017). On security analysis of proof of elapsed-time (PoET). In International Symposium on Stabilization, Safety, and Security of Distributed Systems (pp. 282–297). Springer, Cham. Ciampi, M. et al. (2019). A blockchain architecture for the Italian EHR system. In Proceedings of the Fourth International Conference on Informatics and Assistive Technologies for Health-Care, Medical Support and Wellbeing—HEALTHINFO (pp. 11–17). Daian, P., Pass, R., & Shi, E. (2019). Snow white: Robustly reconfigurable consensus and applications to provably secure proof of stake. In International Conference on Financial Cryptography and Data Security (pp. 23–41). Springer, Cham. Duan, S., Reiter, M. K., & Zhang, H. (2018). Beat: Asynchronous bft made practical. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (pp. 2028– 2041). Dwork, C., Lynch, N., & Stockmeyer, L. (1988). Consensus in the presence of partial synchrony. Journal of the ACM (JACM), 35(2), 288–323. E-SENS. (2016). Electronic simple European networked services. Available at: https://www.ese ns.eu/. eHGI. (2014). The European eHealth Governance Initiative. Available at: https://www.ehgi.eu/def ault.aspx. epSOS. (2014). Smart Open Services for European Patients. Available at: https://www.epsos.org/. Esposito, A., Sicuranza, M., & Ciampi, M. (2013). A patient centric approach for modeling access control in EHR systems. Algorithms and Architectures for Parallel Processing. ICA3PP 2013. Lecture Notes in Computer Science, (vol. 8286, pp. 225–232) Springer. EXPAND. (2015). Deploying sustainable cross-border eHealth services in the EU. Available at: https://www.expandproject.eu/. Fico, G., et al. (2016). Integration of personalized healthcare pathways in an ICT platform for diabetes managements: A small-scale exploratory study. IEEE Journal Biomed Health Information, 20(1), 29–38. Góngora Alonso, S., de la Torre Díez, I., & García Zapiraín, B. (2019). Predictive, personalized, preventive and participatory (4P) medicine applied to telemedicine and eHealth in the literature. Journal of Medical Systems, 43, 140. Hardt, D. (2012). The OAuth 2.0 authorization framework. Request For Comment 6749. HL7 CSS. (2018). HL7 Service functional model: Coordination of care service, STU, Release 1. Available at: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=452.

2 Modernizing Healthcare by Using Blockchain

65

HL7 DAM. (2016). HL7 Version 3 Domain Analysis Model: Care Plan Release 1. Available at: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=435. HL7 FHIR. (2020). HL7 Fast Healthcare Interoperability Resources. Available at: https://www.hl7. org/fhir/ (Accessed on 30th June 2020). HLF. (2020). Hyperledger Fabric Documentation. https://hyperledger-fabric.readthedocs.io/ (Accessed on 30th June 2020). IHE. (2020). Integrating the Healthcare Enterprise. Available at: https://www.ihe.net/ (Accessed on 30th June 2020). IHE PCC. (2020). IHE Patient Care Coordination domain. Available at: https://www.ihe.net/ihe_ domains/patient_care_coordination/ (Accessed on 30th June 2020). IHE PCC DCP. (2020). IHE PCC Dynamic Care Planning Integration Profile, Release 3.1, Trial Implementation. Available at: https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_ Suppl_DCP.pdf (Accessed on 30th June 2020). IHE Wiki. (2020). Available at: https://wiki.ihe.net/index.php/Main_Page (Accessed on 30th June 2020). Kilintzis, V. et al. (2019). Supporting integrated care with a flexible data management framework built upon Linked Data, HL7 FHIR and ontologies. Journal of Biomedical Informatics, 94. Kim, S., & Deka, G. C. (2019). Advanced Applications of Blockchain Technology. Studies in Big Data 60, Springer. King, S., & Nadal, S. (2012). Ppcoin: Peer-to-peer crypto-currency with proof of stake, selfpublished paper. Kinsman, L., et al. (2010). What is a clinical pathway? Development of a definition to inform the debate. BMC Med, 8, 31–33. Kodner, D., & Spreeuwenberg, C. (2002). Integrated care: meaning, logic, applications, and implications—a discussion paper. International Journal of Integrated Care, 2. Kogias, E. et al. (2016). Enhancing bitcoin security and performance with strong consistency via collective signing. In 25th Usenix security symposium (Usenix security 16) (pp. 279–296). Kwon, J. (2014). Tendermint: Consensus without mining. Draft v. 0.6, fall, 1 (11). Lamport, L., Shostak, R., & Pease, M. (1982). The byzantine generals problem. ACM Transactions on Programming Languages and Systems, 4(3), 382–401. Micali, S., & Vaikuntanathan, V. (2017). Optimal and player-replaceable consensus with an honest majority. MIT-CSAIL-TR-2017–004. Miller, A. et al. (2016). The honey badger of BFT protocols. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (pp. 31–42). Nakamoto, S. (2008). Bitcoin: A Peer to Peer Electronic Cash System, self-published paper. Namasudra, S. (2019). An improved attribute-based encryption technique towards the data security in cloud computing. Concurrency and Computation: Practice and Exercise, 31(3). Namasudra, S. et al. (2020). The revolution of blockchain: State-of-the-art and research challenges. Archives of Computational Methods in Engineering. NCHIT. (2018). National Alliance for Health Information Technology, Defining Key Health Information Technology Terms. Panella, M., & Vanhaecht, K. (2010). Is there still need for confusion about pathways? International Journal Care of Pathw, 14(1), 1–3. Pease, M., Shostak, R., & Lamport, L. (1980). Reaching agreement in the presence of faults. Journal of the ACM (JACM), 27(2), 228–234. Richer, J., & Mandel, J. (2018). Harvard Medical School Department of Biomedical Informatics, Health Relationship Trust Profile for Fast Healthcare Interoperability Resources (FHIR) OAuth 2.0 Scopes—openid-heart-fhir-oauth2. Rinkeby. (2020). Rinkeby TestNet Explorer. Available at https://rinkeby.etherscan.io/ (Accessed on 30th June 2020).

66

M. Ciampi et al.

Ropsten. (2020). Ropsten TestNet Explorer. Available at https://ropsten.etherscan.io/ (Accessed on 30th June 2020). Rotter, T., et al. (2010). Clinical pathways: Effects on professional practice, patient outcomes, length of stay and hospital costs. Cochrane Database Systematic Review, 3, 2010. Rotter, T. (2013). Clinical Pathways in Hospitals: Evaluating effects and costs (p. 2013). Erasmus MC: University Medical Center Rotterdam. Saltini, R., & Hyland-Wood, D. (2019). IBFT 2.0: A Safe and Live Variation of the IBFT Blockchain Consensus Protocol for Eventually Synchronous Networks. arXiv preprint arXiv:1909.10194. Schlieter, H. et al. (2017). Towards adaptive pathways—Reference architecture for personalized dynamic pathways. https://doi.org/10.1109/CBI.2017.55. Schwartz, D., Youngs, N., & Britto, A. (2014). The ripple protocol consensus algorithm. Ripple Labs Inc White Paper, 5(8). Shen, H-B., & Hong, F. (2006). An attribute-based access control model for web services. Seventh International Conference on Parallel and Distributed Computing, Applications and Technologies, PDCAT ‘06, December, pp. 74–79. Trillium Bridge. (2015). Bridging Patient Summaries across the Atlantic. Available at: https://cor dis.europa.eu/project/id/610756/it. Trillium Bridge II. (2019). Reinforcing the Bridges and Scaling up EU/US Cooperation on Patient Summary. Available at: https://cordis.europa.eu/project/id/727745/it. VALUeHEALTH. (2017). Establishing the value and business model for sustainable eHealth services in Europe. https://www.ehtel.eu/activities/eu-funded-projects/valuehealth.html. Zamanov, A. R., Erokhin, V. A., & Fedotov, P. S. (2018). ASIC-resistant hash functions. In 2018 IEEE Conference of Russian Young Researchers in Electrical and Electronic Engineering (EIConRus) (pp. 394–396). IEEE.

Mario Ciampi is technologist at CNR-ICAR. He received his M.Sc. degree in Computer Engineering from the University of Naples “Federico II”, and a Master’s degree in European Master on Critical Networked Systems and a Ph.D. degree in Information Engineering from the University of Naples “Parthenope”. His topics of interests include e-health interoperability, software architectures and standards. He has held numerous leadership roles within international and national research projects. He is member of the Technical-Strategic Committee of HL7 Italy and the UNINFO Commission of Medical Informatics. He is Adjunct Professor of Computer Science at the University of Naples “Federico II”. Angelo Esposito is a technologist at CNR-ICAR. He received his (BS) degree in Computer Science in 2005 and his (MS) degree in 2009 from the University of Salerno, Italy, a Master in Interoperability for Public Administration and Networked Enterprises from the University of Roma “La Sapienza” in 2013, and a Ph.D. in Information Engineering in May 2017 from the University of Naples “Parthenope”, Italy. His research interests include e-Health and Information Security. Fabrizio Marangio is a research fellow at CNR-ICAR and a Ph.D. student at the University of Naples “Parthenope”. He received his (MS) degree (cum laude) in 2018 in Telecommunications Engineering from the University of Naples “Parthenope”. His research interests include e-Health and Information security. Mario Sicuranza received his BEng in Computer Engineering in 2006, MEng in 2011 from the University of Naples ‘Federico II’, and a Ph.D. degree in Information Engineering on Cybersecurity for Health Information System in 2016. Currently, he is a technologist at CNR-ICAR. His research interests include e-health, web services, and security architectures. Since 2017, he is Adjunct Professor of Elements of Computer Science at the University of Naples “Federico II”.

2 Modernizing Healthcare by Using Blockchain

67

Giovanni Schmid received his MS degree (cum laude) in Mathematics and his Ph.D. in Applied Mathematics and Computer Science from the University of Naples “Federico II”. Since 2012 he is a Certified Information System Security Professional (CISSP), and currently he works as research scientist at CNR-ICAR. His main research interests are Computer and Network Security, Cryptography, Secure Programming, Distributed and Cloud Computing. Since 2012 he is member of the technical-scientific board of CLUSIT (www.clusit.it), and member of the International Information Systems Security Certification Consortium (www.isc2.org). He carries out teaching and consulting activities both at universities and companies, in the fields of Secure Programming, Information Security and Cryptography.

Chapter 3

Security, Privacy, Trust Management and Performance Optimization of Blockchain Technology Mayank Swarnkar, Robin Singh Bhadoria, and Neha Sharma

Abstract Blockchain is a developing technology which provides data storage, secure transactions and establishing trust in an open environment. Blockchain is widely implemented in cryptocurrency systems like Bitcoins, smart contracts, smart grids over IoT devices etc. Blockchain also has wide applications in healthcare, automobile industries, private and public sectors. This growing popularity of Blockchain is luring hackers to perform various cyber-attacks in order to detect vulnerabilities in the applied Blockchain system. A vulnerable block chain system is open for network breaches, data thefts and information manipulations. Therefore, it is important to design a Blockchain system with proper security, privacy and trust management. However, increasing security and privacy in Blockchain reduces its performance because security and privacy policies are overhead to the applied Blockchain system. Therefore, it is also important to optimize the performance of Blockchain system with proper implementation of security and privacy. This chapter discuss the current scenarios of security, privacy and trust issues in Blockchain. The chapter also discuss the proposed solutions regarding these issues. Further, the chapter discuss the performance analysis on increasing security and privacy in the Blockchain technology and proposed optimizations in the literature. This chapter is then conclude by providing few research directions for improving security, privacy and trust in Blockchain technology while keeping its performance optimized. Keywords Block chain · Security · Privacy · Trust management · Performance optimization · Network attacks · System attacks M. Swarnkar (B) Computer Science and Engineering, Indian Institute of Technology (BHU), Varanasi, India e-mail: [email protected] R. S. Bhadoria Computer Science and Engineering, Birla Institute of Applied Science, Bhimtal, India e-mail: [email protected] N. Sharma Computer Science and Engineering, IPS College of Technology & Management, Gwalior, India e-mail: [email protected] © The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2021 S. Namasudra and G. C. Deka (eds.), Applications of Blockchain in Healthcare, Studies in Big Data 83, https://doi.org/10.1007/978-981-15-9547-9_3

69

70

M. Swarnkar et al.

3.1 Introduction In the past few years, internet has grown a lot leading to changes in various technologies worldwide. One such growing technology is Blockchain. As per the reports of Statista (Statista, n.d.), worldwide market of Blockchain is 3.9 billion USD in 2020 and expecting to grow to 23.3 billion USD by 2023 A block chain is a temporal series of unchangeable records of data stored in the computers belong to distributed systems. The copy of data is stored in more than one computers and these computers communicate with each other securely using data encryption. Blockchain has many applications but cryptocurrency Bitcoin is its most widely used application (Yuan and Wang 2018). Bitcoin was invented in 2008 by Satoshi Nakamoto. He made the source code open in 2009 for public use. Bitcoin is a digital and cryptographic secured currency designed for secure online transaction. This technology become popular among product based websites, investment startups etc from 2013. Moreover, Blockchain gave a proper platform to Bitcoin for secure and trustable transactions. However, Blockchain is also gaining popularity among applications like Insurance, Healthcare, Smart Appliances, Passports, Online ID verification etc. This growing popularity of Blockchain is luring hackers towards it for data stealing, data corruption, Denial of Service attacks on Blockchain network, network breaches etc. (Li et al. 2017). A vulnerable Blockchain system if applied to the sectors such as Healthcare, document storage etc. which contains sensitive and confidential data, it can be attacked by hackers for data stealing and selling it (Namasudra et al. 2020). Moreover, integrity of data or transaction is still a problem in Blockchain system (Otte et al. 2017; Anjum et al. 2017). Therefore, it is important to design a secure Blockchain system to prevent it from such attacks and vulnerabilities (Namasudra and Deka 2018). However, it is known that increasing security in any interconnected system decreases its working efficiency (Wu 1988; Acharya et al. 2006). The same also implements in Blockchain. For example, if high number of security policies are implemented on Blockchain system then each packet of inbound and outbound network traffic needs to be checked with those implemented policies. This will increase the load of the interconnected Blockchain system and sometimes become a performance bottleneck. Therefore, it is also important to consider the performance optimization of secure Blockchain system. This book chapter discuss the following points in detail: 1. Blockchain design from security perspective using hash pointers and Merkel tree. 2. Digital signature in Blockchain using Elliptical Curve Digital Signature Algorithms. 3. Blockchain transaction models for privacy like UTXO model and Account based model. 4. Cyber-attacks in Blockchain and its defense mechanisms 5. Privacy and trust management in Blockchain by mix-coin, signature anonymity and privacy decentralization 6. Performance optimization of Blockchain by using methods like sharding, chain optimization and system optimization.

3 Security, Privacy, Trust Management and Performance …

71

The rest of this book chapter is divided into following sections: Sect. 3.2 as Literature Survey, Sect. 3.3 as Security in Blockchain, Sect. 3.4 as Privacy and Trust Management in Blockchain, Sect. 3.5 as Performance optimization in Blockchain, Sect. 3.6 as Case Study of Smart Home and conclude with Sect. 3.7 as Conclusion and Future Research Directions.

3.2 Literature Survey In this section, we discuss the work done in Security, Privacy, Trust Management and Performance Optimization of Blockchain Technology. Following are the subsections, each describing the previous work done briefly.

3.2.1 Security in Blockchain Eclipse attack proposed by Heilman et al. (2015) allows an adversary to remotely command and control the sufficient number of computers to monopolize bidirectional connection for victim computer. However, the attack works only on Peer to Peer Bitcoin network. Various Double Spend attack models described by Pinzón and Rocha (2016) in which a user can spend the Bitcoins at-least twice in any Bitcoin design and such attacks cannot be mitigated. This is supported by theoretical proof of concept given by Fischer et al. (1985) for the FLP impossibility result. Moreover, it was also described that Eclipse attack makes Double Spend attack much easier to perform on any Cryptocurrency based systems (Heilman et al. 2015). Luu et al. (2016) reported that 45.61% of Ethereum contracts which is second largest cryptocurrency platform after Bitcoin are vulnerable to adversarial manipulation. The authors created a tool Oyente to find bugs in contracts and enhance the contracts by removing bugs and adding bug related semantics to the contracts. Other security issues in Blockchain includes variety of malware (Moubarak et al. 2018; Pletinckx et al. 2018) which are either crafted and transmitted using Blockchain or implemented over Blockchain technology.

3.2.2 Privacy in Blockchain Zyskind et al. (2015) implemented a protocol to automate the access control manager of Blockchain system to avoid the trusted third party to increase the data and account privacy. However in this method, a malicious user can do much more harm to the Blockchain system as third party cannot verify the actions of users. Hawk which is a method for privacy preservation of smart contracts was designed by Kosba et al. (2016) which encrypts and store the financial transactions in intuitive manner.

72

M. Swarnkar et al.

This method also adds processing complexity in the Blockchain system because of the implementation of additional cryptographic algorithm. Provchain by Liang et al. (2017) which collect, store and verify the origin of the data for cloud based data with very low overhead to cloud storage applications. However, the method is limited to cloud computing only. Li et al. (2018) proposed CreditCoin which is a Blockchain based vehicular announcement system for authentic announcements in Vehicular Adhoc Network which also preserves the privacy of the announcer. CreditCoin is temper resistant and traces malicious users identities in the Blockchain system. However, the proposed method is tested in simulated environment only.

3.2.3 Trust Management in Blockchain Anjum et al. (2017) suggested various theoretical Blockchain standards compliance for trust management in the system. The article provided the theoretical overview and provided future direction for the increasing trust in the implemented Blockchain system. Blockchain based trust management system for vehicular network is proposed by Yang et al. (2018). In this article, authors provided the method to validate the message received by the neighboring vehicles using Bayesian Interference model. Simulated results showed the strong trust values in the deployed vehicular network. Kochovski et al. (2019) proposed a method to increase the trust management in Blockchain using Fog Computing.The method uses decenter fog computing platform that uses the Blockchain based Smart Contracts and trust-less smart oracles. Moreover the work is practically implemented on Ethereum Ledger. Mlik et al. proposed TrustChain (Malik et al. 2019) which is a three layered trust management framework and uses consortium Blockchain to track interactions among the participants of the supply chain and to dynamically assign trust and reputation scores based on these interactions. However, the model increases the notable time complexity of the working of the Blockchain system because of multilayered trust verification process.

3.2.4 Performance Optimization in Blockchain García-Bañuelos et al. (2017) provided optimized execution of Business process in Blockchain by compiling Business Process Model Number with smart contracts and deployed on Ethereum platform. Thakkar et al. (2018) identified bottlenecks in the Hyperledger Fabric which is a Blockchain platform in Linux environment. Authors identified three bottlenecks in the performance of Fabric Hyperledger as endorsement policy verification, sequential policy validation of transactions in a block, and state validation with commit. Authors implemented various existing optimization techniques to increase the performance of all three bottlenecks by 3 times, 7 times and 2.5 times respectively. Huang et al. (2018) proposed an network performance optimized

3 Security, Privacy, Trust Management and Performance …

73

decentralized security model for electric vehicle and charging piles using lightning network and smart contract in the Blockchain ecosystem. Li et al. (2018) developed a queuing theory of Blockchain systems using the matrix-geometric solution and then evaluated the Blockchain system performance. Authors reported improved performance of the system under few assumptions. Liu et al. (2019) proposed deep reinforcement learning based performance optimization framework for Blockchainenabled Industrial IoT systems for improving scalability maintaining security and latency of the system.

3.3 Blockchain Design from Security Perspective A secure Blockchain system is far away from simplicity in terms of real implementation. There are many features associated with Blockchain system which provide security. However, two of the most important security features are consensus and immutability. Consensus is the ability of the nodes or end devices within a distributed Blockchain system to agree on the true state of the Blockchain network and on the transaction validity. Efficiency of Consensus depends on the implementation of Consensus algorithms. Anomaly can introduce fake nodes or bots in the system for data theft but strong consensus algorithm protects the Blockchain system from such attacks. In other words, Consensus prevents any unwanted state the distributed Blockchain. On the other hand, Immutability refers to the ability of the Blockchain system to prevent any modification in the confirmed transactions. Immutability prevents anomaliness such as fake transactions, genuine transaction alterations etc. Blockchain system implements hash chain storage to maintain security features like consensus, immutability etc. In the following subsections, we study the secure way of storing and validating transactions in the distributed Blockchain system.

3.3.1 Hash Chained Storage in Blockchain: Hash Pointer and Merkel Tree Hash chain means successive hashing of any message to improve authenticity of that message. However in Blockchain, Hash chained storage consist of two elementary building blocks which are Hash pointer and Merkle tree. Figure 3.1 shows Hash chained storage in Blockchain. It can be observed from Fig. 3.1 that both Hash pointer and Merkel tree is implemented simultaneously for Hash chained storage in Blockchain. Hash pointer and Merkel tree are explained in the following consecutive subsections. Hash Pointer: It is basically a pointer that contains the address of a previous block and the cryptographic hash of the information inside the previous block. The pointer can be used to access the information stored in the predecessor block. Moreover, the

74

M. Swarnkar et al. Block-1 Header

Block-2 Header

Block-3 Header

Block-n Header

Hash of Previous Block Header

Hash of Previous Block Header

Hash of Previous Block Header

Hash of Previous Block Header

Merkle Root

Merkle Root

Merkle Root

Merkle Root

Block-1 Transactions

Block-2 Transactions

Block-3 Transactions

Block-n Transactions

Fig. 3.1 Hash Chain Storage in Blockchain Pointer to Block-0

Pointer to Block-1

Pointer to Block-(n-1)

Hash of Block-0

Hash of Block-1

Hash of Block-(n-1)

Data

Data

Data

Block-1

Block-2

Block-n

Data

Block-0 or Genesis Block

Fig. 3.2 Hash pointer implemented in blockchain

hash can be used to verify that information has not been tampered. A Blockchain can be referred as a linked list that uses hash pointer to link data blocks together. A simple implementation of Hash pointer is shown in Figure. From Fig. 3.2, we can observe that Blockchain is a distributed ledger that can record data between two parties in an efficient way. Each block contains data, hash, and hash of previous block. Data stored inside the block depends on the type of Blockchain. For example, Bitcoin Blockchain stores data as sender-id, receiver-id and number of coins transferred in the transaction process. Second element is the hash of the previous block which is always unique and can be called as fingerprint. It identifies the block and all of its contents. Once the block is created, its hash is being calculated. Any changes made inside the block will cause the hash to change. Thus, it is useful to detect any change inside the block and thus used for validation. Third element is the hash of the previous block. The hash of the first block is not stored in any other block therefore called genesis block. When the data is changed in any block the hash of the block is changed which will cause all the following blocks invalid because it will no longer store the valid hash of the previous block. Thus, a chain of blocks is created which keeps this technique secure. Merkle Tree: It is named after Ralph Merkle, who patented the concept in 1979. Merkle tree is a binary search tree where each non-leaf node is a hash of its respective child nodes. A merkle tree is also shown in Fig. 3.3.

3 Security, Privacy, Trust Management and Performance …

75

Top Hash (Hash-1 + Hash-2)

Hash-0 (Hash-00 + Hash-01)

Hash-1 (Hash-10 + Hash-11)

Hash-00 Hash (L1)

Hash-00 Hash (L2)

L1

L2

Data Blocks

Hash-00 Hash (L3)

Hash-00 Hash (L4)

L3

L4

Fig. 3.3 Merkle tree structure

We can see in Fig. 3.3 that the leaf nodes are present at the lowest level in the tree which are data blocks in Blockchain. Merkle tree is a significant data structure for building a Blockchain where nodes are connected to each other by using hash pointers. In this tree disjoint groups are formed by grouping two nodes present at the lower lever into one at the parent level and for each pair of lower level nodes, hash value is calculated and stored in a new data node created at an upper level. This process is repeated until reaching the root node of the tree. Merkle tree has three salient features which are as follows: • Tamper evident: In a Merkle tree, only hash pointer of the root node is memorized which makes it temper evident as one change disturbs whole Merkel tree. • Traversal efficiency: In a Merkel tree, one data block can be verified by only traversing the path to that node because of unique hash values of child nodes. The complexity of traversal in the Merkle tree is O(log(n)) which is much more efficient compared with O(n) of a linked list like Blockchain. • Non-Membership proof : This property means that there is no space left between the nodes if they are present in the sorted order in the tree.

3.3.2 Digital Signature A digital signature is a technique that can verify that the data is received from the authentic source and is remained unaltered in the transmission channel. There are two important properties of a digital signature: Verifiability and Unforgeability. Verifiability means the data obtained at receiver end can be verified using digital signature and Unforgeability means digital signature cannot be forged as per forged data by an anomaly. Digital signature has three core components: key generation algorithm, signing algorithm, verification algorithm. The key generation algorithm creates a public key and a private key. A key that is made available to the public

76

M. Swarnkar et al.

is known as the public key and the key that is used to sign the messages is known as the private key. The signing algorithm is used to produce a signature on the input message by using the private key. The verification algorithm takes signature, message, and a public key as inputs and returns a Boolean value by validating the message’s signature with a public key. The digital signature can close deals between the two parties within a few minutes by right-clicking the document, sign digitally using their secure pin code, and then send it off by email. This process is completely paperless and in the European Union, a digital signature is just as valid as one made with ink. Digital signature benefits everyone from common citizens and enterprises to the governments. It raises productivity, efficiency, and reduces our impact on the environment. Blockchain uses Elliptic Curve Digital Signature Algorithm (ECDSA) for for storing, processing, and securing encrypted data and digital transactions. EC DS A is a modified elliptical curve cryptography algorithm proposed in 2001 (Johnson et al. 2001). ECDSA is a digital signature algorithm which also works in three steps: Key Generation Algorithm, Signing Algorithm and Signature Verification Algorithm. All three algorithms are shown in Algorithm 1, Algorithm 2 and Algorithm 3 respectively. The parameters used in all the algorithms are abbreviated in Table 3.1. Algorithm 1 Key Generation Algorithm for ECDSA Input: F(C), n, G Output: d A , Q A 1: Sender generate d A such that d A ∈ [0, n − 1] 2: Sender generate Q A as Q A = d A × G

ECDSA is resistant to forgery in the presence of a chosen-message attack or side channel attack if the elliptic curve group is modeled by a generic group and if the hash function employed is collision-resistant (Fournaris et al. 2019). ECDSA also prevents forgery attacks against a legitimate entity by fabricating a valid signature on any unknown message after obtaining the entity’s signature by sending a set of selected probing queries on a set of messages (Mehibel and Hamadouche 2020).

Table 3.1 Parameter description for ECDSA Parameter Description F(C) G n dA QA m

Function used for elliptic curve field Elliptic curve base point that generates a subgroup of large prime order n Integer order of G such that n × G = O where O is the identity element. A private key (randomly selected) A public key (calculated by elliptic curve) Message to send

3 Security, Privacy, Trust Management and Performance …

77

Algorithm 2 Signature Generation for ECDSA Input: Message m to be signed Input: F(C), G, n, d A , Q A Output: Generated signature s with message m 1: Calculate e = H AS H (m) 2: Calculate z = L n (e) where L n is the leftmost bits of group order n 3: Select k such that k ∈ [1, n − 1] 4: while True do 5: Calculate curve point (x1 , y1 ) = k × G 6: Calculate r = x1 mod(n) 7: Calculate s = k − 1(z + r × d A )mod(n) 8: if (r = 0  s = 0) then 9: Break 10: end if 11: end while 12: Signature is the pair (r, s)

Algorithm 3 Signature Verification for ECDSA Input: Signed Message m Input: F(C), G, n, Q A , r, s Output: Generated signature s with message m 1: if (r ∈ / [0, n − 1])  (s ∈ / [0, n − 1]) then 2: Invalid Signature 3: Break 4: else 5: Calculate e = H AS H (m) 6: Calculate z = L n (e) where L n is the leftmost bits of group order n 7: Calculate u 1 = zs −1 mod(n) 8: Calculate u 2 = r s −1 mod(n) 9: Calculate curve point (x1 , y1 ) = u 1 × G + u 2 × Q A 10: if (x1 , y1 ) = O then 11: Invalid Signature 12: Break 13: end if 14: if r ≡ x1 mod(n) then 15: Valid Signature 16: else 17: Invalid Signature 18: end if 19: end if

3.3.3 Consensus The consensus mechanism is a way to make decisions with no authoritative figure in a decentralized peer-to-peer system. This mechanism is used to ensure that records are true and honest. There are three types of consensus mechanisms: • Proof of Stake: In this system, the creator of a new block also known as the validator is randomly chosen based on the number of stakes they commit to the network. The

78

M. Swarnkar et al.

more number of stakes results in higher chances to become a validator. Blockchain protocols like Cardano’s Ouroboros & EOS adopt the Proof of Stake consensus. • Proof of Work: In this system transaction data is stored in blocks attached to a complicated math problem. Such data is only validated when people solve it. This task is performed by powerful computers and process is known as “Mining”. A reward in the form of cryptocurrency is issued to the first miner who cracks the problem. Cryptocurrencies like Bitcoin and Ethereum use a Proof of Work mechanism. • Proof of Authority: It is a modified version of Proof of Stake. In this system only approved parties are selected based on their reputation. IBM’s Hyperledger Fabric and Ethereum’s Koven Testnet Blockchain systems use Proof of Authenticity. A good consensus mechanism has two important properties: persistent and liveliness. Persistence ensures the consistent response from the system about the state of a transaction. Liveliness states that all nodes agree on a decision or a value.

3.3.4 Consistency Consistency refers to the property that says all nodes have the same ledger at the same time. Some people argue that eventual consistency is provided by the bitcoins (Wattenhofer 2016) while other argue that bitcoins guarantee strong consistency (Sirer 2016). Comparison between eventual consistency and strong consistency is shown in Table 3.2.

3.3.5 Temper Resistant It refers to the resistance to an entity by the users or the adversaries. Entity can be a system, product or physical/logical object. In context of Blockchain, tamperresistance means that any transaction cannot be harmed or tampered during and after the generation of a block. In bitcoin system, new blocks are generated by mining nodes. Information can be tampered in following two ways:

Table 3.2 Comparison between eventual and strong consistency Property Eventual consistency Strong consistency Data Data update policy Performance Cost

Offers stale data Lazy data update Low latency Cheap

Offers up-to-date data Frequent data update High latency Expensive

3 Security, Privacy, Trust Management and Performance …

79

• Information of received transaction may be tampered by the miners. • Information that is stored on the block may get tamper by an adversary. For the first kind of tampering, secure hash functions- SHA-256, ECDSA can be used and for the second kind of tempering, hash pointer-a cryptographic technique can be used.

3.4 Blockchain Transaction Models for Privacy Blockchain is also known as distributed ledger that is created and maintained for online transactions. However, maintaining privacy of end users, stored data and transaction is a challenging task in distributed environment. To handle privacy in distributed Blockchain systems, there are two transaction models for privacy: The Unspent Transaction Outputs (UTXO) model and the Account Based Online Transaction (ABOT) Model. Both models are explained in the following subsections respectively.

3.4.1 UTXO Model UTXO model was initially introduced by Bitcoin (Bitcoin). This model resembles the bank’s account record-keeping system, owner of accounts, and account balances. UTXOs are processed continuously and are responsible for beginning and ending of each transaction. Unspent transaction output is a result of a transaction that the user receives and spends in the future. Every UTXO can only be spent once; meaning it cannot be used again in the future. Working of UTXO model is shown in Fig. 3.4. Validation of each transaction is important in terms of privacy and Security. In UTXO, each transaction can be validated if it meets following three constraints:

Ti User A

Broadcast

Unconfirmed Transaction Pool (T1, T2, T3 ... Tn)

Blockchain Network

Confirmed Block

Yes Block

Block

Fig. 3.4 UTXO model

Block

Block

Add Block to Blockchain

Block Validation (Consensus)

No

Remove the Block and Report

80

M. Swarnkar et al.

• Every referenced input in the transaction must be signed by its owner and not yet spent. • If the transaction has multiple inputs, then each input must have a signature matching the owner of the input. • A transaction is legal if the total value of its inputs equals or exceeds the total value of its outputs. The benefits of implementing UTXO model in Blockchain system are: • Scalability: UTXO enables parallel transactions to process multiple UTXOs at the same time. • Privacy: UTXO can maintain higher level of privacy as long as each transaction uses new address.

3.4.2 ABOT Model ABOT model was introduced by Ethereum. This model is simpler as compared to the UTXO model. It explicitly operates on all the transactions to improve consensus efficiency and to achieve faster block time at the cost of a higher degree of risk. ABOT model is also shown in Fig. 3.5. Each transaction with a token value is validated if it meets following constraints: • The token is signed by the message writer i.e. sender. • The writer’s ownership of token value can be attested. • The writer’s spending account has sufficient balance for the transaction.

T1

Sender-1

T2

Reciever-1

T3

Reciever-2

Tn

Transaction Chain

Fig. 3.5 ABOT model

3 Security, Privacy, Trust Management and Performance …

81

After the validation of a transaction, token value is debited from the sending account and the value is credited to the receiving account. Thus, in Ethereum system, user’s account balance refers to the sum of the ETH coins for which the user has a private key for producing a valid signature. The benefits of Account based online Transaction model are: • Simplicity: Account/Balance model does not force transactions to include states thus making the design of the model simple. • Efficiency: Account/Balance model is efficient because each transaction only needs to validate that the sending account has enough balance for the payment in a transaction.

3.5 Security in Blockchain Blockchain system means Blocks in Chains attached to each other. Its design only make it very secure as compared to other data storage systems. If an anomaly wants to make a change in one node or try to compromise one block, it has to make changes to its consecutive nodes. However this requires a lot of computational power to break such encryption is small amount of time. Even if the anomaly makes successful change in the Block, the Block synchronization of Blockchain reveals the compromised blocks. Nevertheless their are many motivated hackers in the world who can damage the distributed Blockchain system in various other ways. In the following subsections, few attacks are discussed which are effecting the security of Blockchain.

3.5.1 Distributed Denial of Service Attack Denial of service attack is performed on the host. In DOS attack, host machine and its network resources are made unavailable to the intended recipients by disrupting the hosted Internet services. DDoS attack refers to “distributed” DOS attack. DDoS attack uses multiple end machines as bots to disrupt the service or empty the resources of the targeted server. Bitcoin exchange servers in the BitCoin Blockchain system are the main targets of the attackers for DDoS attacks. As per the report of cloudflare, one popular coin exchange service has been flagged for 76 application layer DDoS attacks over about a year. However, there are various defense mechanism available to detect DDoS attacks in applied distributed Blockchain system (Mirkin et al. 2019).The fully decentralized mechanism of the Blockchain system and the consensus protocol mechanism effectively ensure the working of Blockchain would prevent the Blockchain system from DDoS attacks. Moreover, exchange servers are installed with powerful Intrusion Detection Systems.

82

M. Swarnkar et al.

3.5.2 Double-Spending Attack Double-spending attack refers to the spending of a coin more than once. In other words, it is an ability to use same Bitcoin for multiple transactions by an attacker. However, this attack is not possible if the attacker has massive computing power. To overcome such issues, attackers used to combine double spending with other attack like Sybil attack to make significant harm to the Bitcoin system (Zhang and Lee 2019). Such type of attacks poses major challenge in trading digital currency in a decentralized network. However. there are few solutions provided by the researched community to prevent double spending in distributed Blockchain systems. Doublespending attack can be prevented by evaluating and verifying the authenticity of each transaction using transaction logs in a Blockchain with a consensus protocol. Each transaction is publicly verified with a consensus protocol before adding the block into the global Blockchain. Additionally, each transaction is signed by its sender using a secure digital signature algorithm.

3.5.3 Majority Consensus Attack Majority Consensus attack is also known as 51% attack. Presence of cheating risks in the majority consensus protocol gives rise to the 51% attack. This attack is caused by the group of miners controlling more than 50% of the Blockchain network’s computing power. If attackers control the majority of the computing power on the Blockchain network, an attacker or group of attackers can interfere with the process of recording new blocks. Thus, attackers can prevent other genuine miners from completing blocks and allowing attackers to monopolize the mining of new blocks and earn all of the rewards every-time. There were multiple instances of 51% attack in the world. Krypton and Shift which are two Blockchain based on Ethereum, suffered 51% attacks in August 2016. Similarly in May 2018, Bitcoin Gold which was the 26th-largest cryptocurrency at that time, suffered a 51% attack. These attacks can be prevented by strong end user monitoring and surveillance systems.

3.5.4 Pseudonymity Pseudonymity refers to a state of disguised identity or holding someone else identity. In Blockchain, attacker can disguise as genuine user by stealing genuine user’s credentials. In this way, attacker can freely perform anomalous tasks in the Blockchain system without worrying about identity disclosure. Such attacks directly effect the genuine user. In case of bitcoins, address stored in the Blockchain is a hash of public keys of a node in the network. Users can interact with the system as anonymous entities without revealing their names. Thus, the address provided by the user is

3 Security, Privacy, Trust Management and Performance …

83

seen as a pseudo-identity. Moreover Pseudonymity directly hinders confidentiality in Blockchain. This problem can only be prevented by the end user itself. Genuine user must protect its credentials and does not get caught in the identity theft attacks like Phishing etc.

3.6 Privacy and Trust Management in Blockchain Secure sharing and storage of trust information are important for maintaining confidentiality and integrity in the Blockchain systems. Privacy leakage leads to trust issues in Blockchain system. Identity integrity makes applied Blockchain system trustworthy for its users. There are few techniques discussed in this chapter to maintain privacy and build trust in Blockchain systems. These techniques are discussed in the following subsections.

3.6.1 Mixing Mixing is the process of hiding the linkages between the input and output of individual transactions by combining (mixing) with inputs and outputs of other transactions. There are two popular methods for Mixing which are as follows: • MixCoin: It is a bitcoin mixing protocol that was proposed for providing transaction accountability. It allows users to send their transactions to trusted third party who act as mixing peers and then receive back the same amount of the transactions submitted by other users. This is done to provide anonymity to bitcoin transactions. Trusted third party uses mixing server simply called as mix. Later, the mix decrypts the new addresses, randomly shuffles them, and sends the funds back to each participant. MixCoin also provides signed warranties to participants as a recovery in case of error by the Third party. MixCoin can also provide anonymity to external participants. The major disadvantage of this approach is that the participants deal with a third party and have to trust the mix. • CoinJoin: It solves the drawback of MixCoin by involving the combination of inputs by multiple users into a single transaction for protecting the privacy of bitcoin users when they conduct transactions with each other. It provides anonymity by using multi-signature transactions. Multi-signature requires the involvement of more than one party in the transaction. In CoinJoin, the participants mix their joins by generating one single mixed transaction. The transaction with multiple inputs is considered valid only if has been signed with all the keys related to the input addresses. Hence, the generated mix is verified by each user and refuses to sign the transaction to stop the exchange. CoinJoin provides external unlinkability. It is a process in which no external party can determine which input corresponds to which user. In this way, ownership of Bitcoins is hidden from external parties by

84

M. Swarnkar et al.

joining them with others in a single mixed transaction. The disadvantage of CoinJoin is that one of the involved parties can learn the process of linking transactions between inputs and outputs.

3.6.2 Signature Anonymity Anonymous digital signatures are required because basic digital signature does not provide signer anonymity or unlinkability. Anonymous digital signature retains the public verifiability. Two of the popular method for anonymous digital signature are Group signature and Ring signature which are discussed below: • Group Signature: It was introduced by Chaum and van Heyst in 1991. In this signature, there exists a group manager who is responsible for handling registration of group members and providing each group member with a group certificate (or a group signing key). Each member of the group can sign anonymously on behalf of the whole group. Meanwhile, the group manager can identify the real signer of a valid group signature. • Ring Signature: It was introduced by by Rivest, Shamir and Tauman in 2001. In this signature, there is no involvement of a ring manager and thus, each user has a complete freedom in selecting other ring members. Similar to group signature, a ring signature allows a ring member to sign anonymously on behalf of other ring users. Moreover, no one is able to revoke the anonymity of a ring signature.

3.6.3 Homomorphic Encryption and Attribute Based Encryption Encryption that allows one to perform calculations on the encrypted data without decrypting it first is called Homomorphic encryption. Applications of Homomorphic encryption are healthcare, smart grids, education, and machine learning as a service (MLASS). Figure 3.6 shows MLaaS Application of Homomorphic Encryption.

Encrypted Result

Public Key Encryption Algorithm

Decryption Algorithm

Model for Calculations

Message

Secret Key

Sender Side

Reciever Side

Fig. 3.6 MLaaS application of homomorphic encryption

Decrypted Result

3 Security, Privacy, Trust Management and Performance …

85

Homomorphic encryption is used in the sectors where input privacy is important and making use of data is highly complex due to the presence of several regulations and security concerns. There are two main advantages of Homomorphic encryption which are as follows: • Inference is performed on the encrypted data thus; model can never see the private data of the client. Therefore, data is not misused or leaked. • There is no requirement of any interaction between the client and the model owner for performing any computation. However thee are two disadvantages also of Homomorphic encryption which are as follows: • Computation cost makes this technique expensive. • Restricted applications. Attribute-base encryption is an algorithm of public key cryptography in which the secret key of a user and the ciphertext are dependent on certain user attributes such as position, place of residence, type of account, etc. ABE has wide applications in cloud computing, mobile computing, and the Internet of things. ABE provides flexible and fine-grained access control of sensitive data. Advantages of ABE are optimized ciphertext expansion rate and anonymity of receivers.

3.6.4 Privacy Decentralization There is a rapid increase in reported incidents of security breaches that have compromised the user’s privacy. The decentralization mechanism of Blockchain eliminates the need for a central authority, thus increasing the user’s privacy. Data privacy can be reshaped by the following measures: • Decentralizing data storage and transfer • Integrating decentralization with innovations such as multiparty computation, encryption and trusted execution environment. Blockchain has refueled a growing generation of ideas that has allowed individuals to take their privacy back with the help of decentralization. The decentralized mechanism of Blockchain addresses several challenges that are faced by centralized models. Three major challenges are as follows: • Prevents replicated identities through data verification by all the network users and through time stamping of transaction records • Prevents data tampering through hashing algorithms • Prevents data processing manipulation with a majority consensus achieved through several mechanisms (proof of work, proof of stake, etc.)

86

M. Swarnkar et al.

3.7 Performance Optimization in Blockchain Blockchain technology works on three major principles that are decentralization, security, and scalability. For increasing the performance gains of the system there is a requirement of improving the performance and scalability of the systems. Some optimization techniques are sharding, Directed Acyclic Structure (DAG), Scalable consensus, Side-chain, On-chain and system optimization are currently available.

3.7.1 Sharding Sharding is a database architecture pattern that divides a large piece of data into smaller data pieces that are faster and easier to manage. These broken pieces are later placed on different servers for improving performance and availability. In the Blockchain, block is fragmented and each node only needs to verify the transaction in its own shard. There is no need of verifying the transaction outside the shard. Thus, the transactions can be performed in a parallel fashion with the other nodes on the network. Parallel mechanism completes the verification task in a faster way, reduces redundancy calculation performed by the nodes, improves the transaction speed of the public chain, and minimizes the transaction cost. There are three mainstream sharding strategies: network sharding, transaction sharding, and state sharding. Creating shards and preventing them from the attackers are crucial tasks for the developers. Embedment of randomness in the Blockchain structure can prevent the overfilling of individual fragments by attackers. The key feature of sharding is the separation of entire storage for accommodating different parts on different shards. Thus, each node is only responsible to maintain its own fragmented data rather than storing entire Blockchain structure. In the case of account handing between two different shards, frequent cross-fragmentation and state change phenomena are required. Cross-fragmentation does not allow performance gains for state sharding. This problem requires further studies. Another problem faced in state sharding is data availability. The solution to this problem is the maintenance of backup by the node which can help to system to repair and recover data that are not available. There are various challenges that are faced by sharding such as creation of shards, assigning shards to the nodes, determining the size of each shard, implementation of cross-shard trading, high costs, affect on the throughputs and profits of the entire network, etc. The first project that implemented fragmentation technology using network sharding and consensus mechanism is Zilliqa (Zilliqa, n.d.). It has used 1400 nodes and 6 shards in the test and got a throughput of 2800 TPS.

3 Security, Privacy, Trust Management and Performance …

87

Table 3.3 Comparison between traditional and DAG based blockchain Property Traditional blockchain DAG based blockchain Element Efficiency Scalability Perpetrate Data transmission rate Shadow chain attack Smart contract development

Block Low Weak Hard Low Easy Easy

Transaction High Strong latency Harder High Hard Hard

3.7.2 Directed Acyclic Structure Directed Acyclic Graph is the second method to design Blockchain systems. DAG was proposed by Nxt community to store blocks and solving the problem of Blockchain efficiency. In DAG, performance can be greatly improved by doing the transaction packaging on different branch chains in a parallel fashion. The concept of DAG-chain was first proposed in the year 2005 and in the same year DAG network was upgraded from the block packaging dimension to the transaction-based level. DAG-chain skips the stage of packing the block and directly broadcasts the transaction to the whole network. Thus, efficiency is theoretically improved. Table 3.3 shows the comparison between DAG-based Blockchain and traditional Blockchain. In DAG, verification of the previous transactions is done by the latter transaction. This verification method allows the DAG to write transactions asynchronously and concurrently. This finally forms a topology tree structure and thereby improving scalability.

3.7.3 Scalable Consensus New consensus protocols can be adopted to improve efficiency and scalability. The mining process used in the Proof-of-Work (POW) wastes a large number of resources and consumes time to reach consensus. These delays are not suitable for commercial applications. Proof-of-Stake (POS) consensus is an upgrade to POW. The difficulty of the mining process is reduced in POS consensus by managing the proportion and time of each node. This shortens the time required to reach the consensus but the involvement of the mining process still creates problems for commercial applications. Delegated Proof-of-Stake is another improved version of POS that works on the concept of voting elections. In DPOS several nodes are selected as representatives to operate the network and professional network servers are used to ensure security and performance of the Blockchain network. PBFT Byzantine fault-tolerant algorithm claims for high performance and good security but the degree of decentralization is

88

M. Swarnkar et al.

weak, fault-tolerance is low, and the node system is closed. Another protocol known as Ripple consensus protocol that improves speed and scalability works in two stages: • The first stage involves the scenario of reaching the consensus in the transaction set. • The second stage involves the proposal of newly generated blocks and finally forming the consensual block. Ripple results in weak security and a centralized structure. Ripple itself controls a large part of accounting nodes. From all the above consensus protocols, it can be concluded that extending the protocols might cause some improvements in the performance of the network but weakens the degree of network decentralization. Therefore, the best consensus mechanism can be designed by considering local conditions for fostering the best results in the future.

3.7.4 Side Chain The concept of side-chain is introduced to expand the function and performance of the main chain. This is realized by transferring values from the main chain to the side chain through bidirectional anchoring. Side-chain works in three phases: First, a part of bitcoin is locked on the main chain. Second, operate currency on the side chain. The third and final step, settle on the main chain after the end of the operation cycle. To solve trust problems in the Blockchain, transaction data can be easily verified by notary mechanism or block header. Additionally, the hash time can be used to guarantee the atomicity of transactions. Atomicity is a property of database management system to mark a transaction either pass or fail by assigning 1 or 0 values to a transaction. If a transaction is successful, value one is assigned and if a transaction fails, value zero is assigned to a transaction. Locked assets can be managed by Single custodian, alliance custodian and intelligent contract custodian. Side-chain is an innovative mechanism to reduce the burden of the main chain by creating independency between data and code in the side-chain. This phenomenon is a naturally occurring fragmentation mechanism. Side-chains are greatly useful for increasing flexibility of the Blockchain and can expand the dimension and application range of Blockchain technology. Disadvantages of side-chains include the high complexity of side-chains and the requirement of enough miners for ensuring safety parameters within the system. Ethereum requires plasma for building side-chains. Plasma consists of five core components: • Incentive layer: This layer calculates the contracts cost-effectively. • Tree-like arrangement: This arrangement of side-chains can maximize the lowcost efficiency and the net-settlements of transactions. • Map-reduce computing framework: It helps in increasing the scalability of sidechains by reframing the state transitions. Also builds fraudulent proofs of state transitions in the side-chains and makes them compatible with a tree structure.

3 Security, Privacy, Trust Management and Performance …

89

Plasma Contract (Decentralized Exchange)

Plasma Contract (Private Blockchain)

Ethereum Root Chain

Plasma Contract (Social Network)

Plasma Contract (Micropayments)

Fig. 3.7 Rootchain example for ethereum

• Consensus mechanism: This is based on the main chain. • Bitmap-UTXO commitment: this structure ensures the correctness of state transitions of the main chain and maximizes the cost of large-scale exits. Figure 3.7 shows an example of Ethereum is the root and trunk of a tree and side chains based on plasma are branches. Most transactions are handled by these branches to save space on the main chain and increase processing speed. Each plasma side-chain is dominated by the main chain. Smart contracts are used for controlling the participating nodes of the main chain, for confirming activities and reaching to the consensus.

3.7.5 On Chain There are some significant ways that are introduced to improve the scalability of Blockchain networks through on-chain which are as follows: • Multiple Blocks per Leader: In this approach, multiple blocks are appended to the Blockchain until another leader is elected. Bitcoin-NG is based on the same trust model, but breaks bitcoin’s Blockchain operation into leader and transaction serialization for performance improvement. Leader election is performed randomly and infrequently via proof-of-work. In bitcoin, leader can propose to append only one block to the Blockchain whereas in Bitcoin-NG time is divided into multiple epochs and a leader can unilaterally append multiple transactions to the Blockchain for the duration of its epoch which ends when a new leader is elected. • Collective Leaders: Many systems employ multiple leaders to collectively and quickly decide whether the block should be added to the Blockchain or not. This unanimous decision gives a strong reason to a client about the placement of a block on the chain. Byzcoin replaces the probabilistic transaction consistency of a bitcoin with strong consistency thus, improving transaction latency of bitcoin.

90

M. Swarnkar et al.

• Parallel Blockchain Extension: Here, different parts of the Blockchain are grown in a parallel fashion. This work is accomplished by multiple leaders. Bitcoin performs a linear process for growing blockchains. A problem is given to the miners, one who finds the solution adds the bloc to the chain. Boyen et al. (2016) introduced a framework that parallelizes this process by abandoning the concepts of “blocks” and “chains” and introduced the concept of cross-validation of transaction. Each transaction confirms two transactions (its parents) and contains some payload (for example, cryptocurrency) and proof of work.

3.7.6 System Optimization Optimization techniques are introduced and implemented to alleviate the bottleneck present in the Blockchain network. In a Hyperledger fabric, CPU resources are left unutilized during the VSSC verification phase. For better resource utilization, multiple transactions can be processed in the VSSC verification phase. Since encryption operation requires more involvement of CPU, some routine operations can be avoided by introducing and maintaining a deserialized identifier cache and its MSP information. Additional CPU power can be utilized effectively by improving process transactions within and across channels. Couch DB can perform batch read/write operations without additional transaction semantics. Bulk operations are adopted to reduce lock duration and improve performance. GoLevelDB and CouchDB result in locking the entire database during the approval and ledger update phases without snapshot isolation level. There are three simple optimization techniques: • Addition of a cache to an MSP (Membership Service Provider). • Parallelization of VSSC (Validation System Chaincode) verification block. • Creating a batch of (read/write) operations during MVCC (Multi-Version Concurrency Control) verification and submitting them. By optimizing the combination, the overall performance of a single channel environment is increased by a factor of 16 (from 140 TPS to 2250 TPS).

3.8 Conclusion In this chapter, an overview about various security, privacy, trust and optimization issues on distributed Blockchain system is described. Moreover, this chapter also described few of the effective solutions given by researchers to resolve each kind of problem. Blockchain is an interesting modern technology which will grow further in the near future. Because of its growing popularity and adaptability, applications of Blockchain will increase and so the issues which are discussed in this chapter. This will surely give real challenges to Security and Blockchain related researchers in the coming future.

3 Security, Privacy, Trust Management and Performance …

91

References Acharya, S., Wang, J., Ge, Z., Znati, T. F., & Greenberg, A. (2006). Traffic aware firewall optimization strategies. In Proceedings of the 12th IEEE International Conference on Communications (ICC’06) (pp. 2225–2230). Anjum, A., Sporny, M., & Sill, A. (2017). Blockchain standards for compliance and trust. Cloud Computing, 4, 84–90. Boyen, X., Carr, C., & Haines, T. (2016). Blockchain-free cryptocurrencies: A framework for truly decentralised fast transactions. Cryptology, 1, 1–13. Fischer, M. J., Lynch, N. A., & Paterson, M. S. (1985). Impossibility of distributed consensus with one faulty process. Journal of the ACM, 32, 374–382. Fournaris, A. P., Dimopoulos, C., Moschos, A., & Koufopavlou, O. (2019). Design and leakage assessment of side channel attack resistant binary edwards elliptic curve digital signature algorithm Architectures. Microprocessors and Microsystems, 64, 73–87. García-Bañuelos, L., Ponomarev, A., Dumas, M., & Weber, I. (2017). Optimized execution of business processes on blockchain. In Proceedings to the 1st International Conference on Business Process Management (BPM’17) (pp. 130–146). Heilman, E., Kendler, A., Zohar, A., & Goldberg, S. (2015). Eclipse attacks on bitcoin’s peer-to-peer network. In Proceedings to the 24th USENIX Security Symposium (USENIX’15) (pp. 129–144). Huang, X., Xu, C., Wang, P., & Liu, H. (2018). LNSC: A security model for electric vehicle and charging pile management based on blockchain ecosystem. IEEE Access, 6, 13565–13574. Johnson, D., Menezes, A., & Vanstone, S. (2001). The elliptic curve digital signature algorithm (ECDSA). International Journal of Information Security, 1, 36–63. Kochovski, P., Gec, S., Stankovski, V., Bajec, M., & Drobintsev, P. D. (2019). Trust management in a blockchain based fog computing platform with trustless smart oracles. Future Generation Computer Systems, 101, 747–759. Kosba, A., Miller, A., Shi, E., Wen, Z., & Papamanthou, C. (2016). Hawk: The blockchain model of cryptography and privacy-preserving smart contracts. In Proceedings of the 37th IEEE Security and Privacy Workshops (S&P’16) (pp. 839–858). Li, Q.-L., Ma, J.-Y., & Chang, Y.-X. (2018). Blockchain queue theory. In Proceedings of the 7th International Conference on Computational Social Networks (pp. 25–40). Liang, X., Shetty, S., Tosh, D., Kamhoua, C., Kwiat, K., & Njilla, L. (2017). Provchain: A blockchain-based data provenance architecture in cloud environment with enhanced privacy and availability. In Proceedings of the 17th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing (CCGRID’17) (pp. 468–477). Li, X., Jiang, P., Chen, T., Luo, X., & Wen, Q. (2017). A survey on the security of blockchain systems. Future Generation Computer Systems, 107, 841–853. Li, L., Liu, J., Cheng, L., Qiu, S., Wang, W., Zhang, X., et al. (2018). Creditcoin: A privacy preserving blockchain-based incentive announcement network for communications of smart vehicles. IEEE Transactions on Intelligent Transportation Systems, 19, 2204–2220. Liu, M., Yu, F. R., Teng, Y., Leung, V. C., & Song, M. (2019). Performance optimization for blockchain-enabled industrial internet of things (IIoT) systems: A deep reinforcement learning approach. IEEE Transactions on Industrial Informatics, 15, 3559–3570. Luu, L., Chu, D.-H., Olickel, H., Saxena, P., & Hobor, A. (2016). Making smart contracts smarter. In Proceedings of the 21st ACM International Conference on Special Interest Group on Security, Audit and Control (SIGSAC’16) (pp. 254–269). Malik, S., Dedeoglu, V., Kanhere, S. S., & Jurdak, R. (2019). TrustChain: Trust management in blockchain and IoT supported supply chains. In Proceedings of the 2nd IEEE International Conference on Blockchain (ICBC’19) (pp. 184–193). Mehibel, N., & Hamadouche, M. (2020). A new enhancement of elliptic curve digital signature algorithm. Journal of Discrete Mathematical Sciences and Cryptography, 23, 743–757. Mirkin, M., Ji, Y., Pang, J., Klages-Mundt, A., Eyal, I., & Jules, A. (2019). BDoS: Blockchain denial of service. arXiv:1912.07497 .

92

M. Swarnkar et al.

Moubarak, J., Chamoun, M., & Filiol, E. (2018). Developing a K-Ary malware using blockchain. In Proceedings of the 13th IEEE/IFIP Network Operations and Management Symposium (NOMS’18) (pp. 1–4). Namasudra, S., & Deka, G. (2018). Taxonomy of DNA-based security models. In Advances of dna computing in cryptography (pp. 37–52). Namasudra, S., Deka, G. C., Johri, P., Hosseinpour, M., & Gandomi, A. H. (2020). The revolution of blockchain: State of the art and research challenges. Archives of Computational Methods in Engineering. Otte, P., de Vos, M., & Pouwelse, J. (2017). TrustChain: A sybil-resistant scalable blockchain. Future Generation Computer Systems, 107, 770–780. Pinzón, C., & Rocha, C. (2016). Double-spend attack models with time advantange for bitcoin. Electronic Notes in Theoretical Computer Science, 329, 79–103. Pletinckx, S., Trap, C., & Doerr, C. (2018). Malware coordination using the blockchain: An analysis of the cerber ransomware. In Proceedings of the 6th IEEE International Conference on Communications and Network Security (CNS’18) (pp. 1–9). Sirer, E. (2016). Bitcoin guarantees strong, not eventual consistency. Distributed: Hacking. Statista. (n.d.). (https://www.statista.com/statistics/647231/worldwideblockchain-technologymarket-size) Thakkar, P., Nathan, S., & Viswanathan, B. (2018). Performance benchmarking and optimizing hyperledger fabric blockchain platform. In Proceedings of the 26th IEEE International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems (Mascots) (pp. 264–276). Wattenhofer, R. (2016). The cience of the blockchain. CreateSpace Independent Publishing Platform. Wu, F. (1988). Real-time network security monitoring, assessment and optimization. International Journal of Electrical Power & Energy Systems, 10, 83–100. Yang, Z., Yang, K., Lei, L., Zheng, K., & Leung, V. C. (2018). Blockchain-based decentralized trust management in vehicular networks. IEEE Internet of Things Journal, 6, 1495–1505. Yuan, Y., & Wang, F.-Y. (2018). Blockchain and cryptocurrencies: Model, techniques, and applications. IEEE Transactions on Systems, Man, and Cybernetics: Systems, 48, 1421–1428. Zhang, S., & Lee, J.-H. (2019). Double-spending with a sybil attack in the bitcoin decentralized network. IEEE Transactions on Industrial Informatics, 15, 5715–5722. Zilliqa. (n.d.). (https://www.zilliqa.com/) Zyskind, G., Nathan, O., et al. (2015). Decentralizing privacy: Using blockchain to protect personal data. In Proceedings of the 36th IEEE Security and Privacy Workshops (S&P’15) (pp. 180–184).

Chapter 4

Securing Healthcare Data by Using Blockchain Meenu Gupta, Rachna Jain, Meet Kumari, and Gaurav Narula

Abstract Healthcare is an important aspect of the development of the nation, and healthcare data are a key element in curing patient health. Healthcare information exchange is a very important aspect that benefits patients as well as health service providers. Due to a large amount of patient data, service providers use many cloudbased solutions, but insecurity arises in the case of the third-party service provider. This issue has been addressed by the authors in this chapter. However, existing techniques mainly focus on collecting patients’ records from medical examination. In the present, IoT is widely used in mobile applications for monitoring patient’s health and maintaining records. Then, collecting records could be sent to laboratories for further analysis and diagnosis. But, present techniques are too rigid in exchange of metadata. Authors tried to develop a method using smart contracts in blockchain which helps in securing the data over transfer. Each and every aspect of healthcare has been taken into consideration including the lab results, clinical trials, reimbursements, medical charts, etc. In this chapter, the role of blockchain in making digital records and transfer of the same in the healthcare system safe and encrypted is discussed. Different technology used for managing healthcare data is also discussed in this chapter. Later on, the use of smart contracts in blockchain and migration of the existing model of healthcare system into blockchain is discussed. Based on the proposed model, result evaluation is discussed for securing healthcare data using blockchain.

M. Gupta (B) Department of CSE, Chandigarh University, Punjab, India e-mail: [email protected] R. Jain · G. Narula Department of CSE, Bharati Vidyapeeth’s College of Engineering, Delhi, India e-mail: [email protected] G. Narula e-mail: [email protected] M. Kumari Department of ECE, Chandigarh University, Punjab, India e-mail: [email protected] © The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2021 S. Namasudra and G. C. Deka (eds.), Applications of Blockchain in Healthcare, Studies in Big Data 83, https://doi.org/10.1007/978-981-15-9547-9_4

93

94

M. Gupta et al.

Keywords Smart contracts · E-healthcare records · Blockchain · Data exchange · Healthcare data · Healthcare service provider

4.1 Introduction Healthcare is the preservation of health by safety, diagnosis, disease treatment, or injury. The healthcare industry includes many industries that are essential elements for delivering healthcare services and goods. Healthcare data are one of the most important elements of this industry as this data help the healthcare system to construct a detailed image analysis that examines the whole person, including their physical, mental and emotional health, while taking into account social factors (Biswas and Muthukkumarasamy 2017). Managing healthcare data effectively in a classified manner is very important. Patient data are highly fragmented and substantial, being a complex system of interconnected entities within heavily regulated boundaries. Managing such an enormous amount of data is very difficult (Gordon and Catalini 2018). Blockchain is a ground-breaking technology that can help overcome the data processing problems associated with healthcare. Blockchain has been around for quite a while now. The technology was first brought into the spotlight through bitcoin (the much-popular cryptocurrency) (Genestier et al. 2017). Blockchain has previously been used to record transactions such as records, but with this, its use cannot be restricted. Due to its main features such as decentralized governance, improved protection, distributed ledgers, consensus, and faster settlement, blockchain technology can be proved very beneficial for the healthcare industry (Kshetri 2018). Blockchain is a decentralized ledger system that cannot be altered and can provide data transparency, and for their benefit, no one can change any feature of the data. The healthcare industry has seen rapid adoption of Electronic Health Records, which has contributed to major developments in the digitization of healthcare care delivery systems (Kuo and Ohno-Machado 2004). Blockchain is a trusted interoperability network for certain HERs. Blockchain provides data anonymization tools and guarantees that the data cannot be manipulated or fabricated (Ahram et al. 2017). Healthcare has always remained one of the most successful research fields over the last few decades. It continues to find new and more effective ways of supporting the population and healthcare sector. Specific parties (practitioners, medical providers, clinics, nurses, patients, payers, etc.) must arrange, view, and exchange health information in a safe and interoperable manner, without any alteration (Ahram et al. 2017). The provenance of data is also important to prove record authenticity. Blockchain technology is being applied in different contexts and can address the main healthcare sector issues. However, it needs to focus on more research to deploy this technology in real-time applications. Some implementations of this technology in the healthcare sector follow. MedRec platform provides open record-keeping, authorization, and data sharing among stakeholders in the healthcare sector. Patients can save their data and also allow approvals to be issued and revoked on their records. This framework

4 Securing Healthcare Data by Using Blockchain

95

provides complete confidentiality as the records are not stored on the blockchain, instead of pointing only in this blockchain to the data storage locations, logs, and permissions. Gem has introduced Gem Health Network using Ethereum blockchain, in collaboration with Philips Blockchain Lab. This structure is developed to address operating costs (Shen et al. 2019). This shared infrastructure offers interoperability between various organizations that access the same information to improve patient care better. Healthcare platform Guardtime provides an intermediate partnership between patients and providers in Estonia. Guardtime blockchain allowed open patient, provider, and payer information sharing promising secure, accurate, and auditable records. Research organizations demand the health data of patients. In this sense, the Healthbank has provided patients with a forum for preserving and exchanging their health data with research organizations that can be used for clinical research and pharmaceuticals. The platform also supports patients with financial incentives for their blockchain-based data sharing (BBDS) access control program optimized for their contributions using authorization blockchain. Data owners can use a shared data pool to access their EMRs (Khatoon 2020). This safe and scalable framework recognizes, authenticates, and authorizes users to use cryptographic keys and digital signatures that gain an advantage over Healthcare Data Gateways (HDG), a mobile application developed over the blockchain cloud. Quick Healthcare Interoperability Resources: FHIR chain was developed by the clinical data exchange organization Health Level Seven International (HL7). FHIR is improving performance and interoperability (Khatoon et al. 2019). The existing systems have certain flaws in its management and security making it prone to security attacks and making confidential patient data at a very high risk. Keeping this in mind, authors try to resolve this issue by introducing the concept of blockchain and smart contract system which uses encryption and decentralized nodes in its process to provide security. Authors try to develop a system which is user friendly but also provides high security with public-key encryption to overcome the existing security flows in the existing systems. This book chapter focuses on the concepts of decentralization that can be applied to large-scale data processing using blockchain technology. It can be applied to large-scale data processing in the medical sector and to streamline tough medical procedures. The authors demonstrate an innovative approach to the handling of medical records, giving auditability, interoperability, and accessibility through smart contracts. In this chapter, a smart contract healthcare system for managing healthcare data and complex streamlining medical procedures has been presented. In the field of healthcare, authors addressed the state-of-the-art blockchain work and introduced an ethereum cantered solution for healthcare management. The older healthcare system pooled money collectively in the area of medicine and rehabilitation, which was not consistent with the external network. One of the most important problems is the exchange of data between different entities requesting data from healthcare providers such as physicians. This new healthcare system model uses smart blockchain contracts (Schöner et al. 2017).

96

M. Gupta et al.

The chapter includes every aspect of healthcare facilities. Firstly, smart contracts are discussed and how they can be used in healthcare management, its benefits over existing systems. Then, authors proposed a system using Ethereum’s smart contracts and included medical prescriptions, laboratory data and results, reimbursement, clinical trials, and various other necessary facilities in the healthcare chain.

4.2 Background Legacy programs usually only exchange healthcare and medical services internally, and they are not completely compliant with systems externally. Nonetheless, evidence shows various benefits from hybridizing these networks for connected internally and improved medical, calling for interconnections for health informatics researchers between different organizations (Dennis and Owen 2015). One of the most important problems is the multi-organizational data sharing that allows other organizations, like a research or physician center, to have ready access to medical data collected by a healthcare provider (Mougayar 2020). Blockchain technology redefines data processing and governance in many healthcare implementations. This is due to its unparalleled and adaptability segmentation, safe storage, and exchange of healthcare data. Blockchain technology is at the forefront of dozens of other emerging trends in the healthcare industry, as shown in Fig. 4.1. With advances in health-related electronic technology, patient data, cloud data storage data and security laws, new chances for medical data management and convenience for patients to access and exchange their medical data are opening up (Siyal et al. 2019). Ensuring data privacy, storing, managing and transactions for their

Fig. 4.1 Blockchain mechanism (Makhdoom et al. 2019)

4 Securing Healthcare Data by Using Blockchain

97

smooth integration is prodigious. This information is valuable to any medical datadriven organization, especially in medical care where blockchain technology can solve these critical issues robustly and effectively. Blockchain-based applications comprising data management, data sharing, data storage, and EHR were addressed in detail in this section (Hölbl et al. 2018). Proceedings blockchain-based medical technologies are conceptually divided into many levels, comprising data sources, blockchain technology, medical care implementations, and stakeholders (Deshpande et al. 2017). Gordon and Catalini published a healthcare blockchain analysis where they observed their discussion on how the blockchain technology would allow patient-centered control over institution-centric control of data sharing in healthcare (Ratta et al. 2020). They explored how the blockchain technology changes the medical sector by allowing for digital access rights, network-wide recognition of patients, managing a vast amount of healthcare data, and immutability of data (Wu and Lin 2019a). An MIT Media Lab study addressed the privacy and security aspects of data processing and information management, outlining all the applications of blockchain technology. This is the importance of data processing which is stable—in the sense that it cannot be manipulated (Wu and Lin 2019b). Data protection and privacy are other dimensions of data security. For instance, the decentralized Enigma is a privacy-guaranteed computing program and a breakthrough on the blockchain. Enigma aims to consider developers to create a point to point decentralized application without a trusted third party that is ‘privacy by design’. An Enigma is an extension of the blockchain technology as data storage, and processing data are not achieved inside the blockchain. Rather the blockchain is an “operating system” for secure multiparty computations performed by network-participating storage and computing nodes. Here, information is split between distinct nodes, and various nodes work together to observe functions without leaking information to the other nodes. In summary, each party has an insignificant, and no one party has access to data in its entirety (i.e., seemingly arbitrary) rather a piece of that (Tamazirt et al. 2018). Blockchain holds the promise of creating the new data contract, a greater degree of personal data ownership, control, and content delivery, through a network that enables the society to benefit from data aggregation (Agbo and Mahmoud 2020).

4.2.1 Smart Contract A smart contract is a computer program or a transaction protocol which is intended to automatically execute, control, or document legally relevant events and actions according to the terms of a contract or an agreement. Smart contracts enable valid transactions to be carried out without third parties. These transactions are permanent and traceable (Alladi et al. 2020). Figure 4.2 shows an example of maintaining patient records using smart contracts. Smart contract proponents argue that many kinds of contractual clauses can be

98

M. Gupta et al.

Fig. 4.2 Role of smart contract in maintaining patient record

made partially or completely self-executing, self-enforcing, or both. The goal of smart contracts is to provide protection that is superior to traditional contract law and to reduce certain contract-related transaction costs (Warkentin and Orgeron 2020). Different cryptocurrencies have introduced smart contract forms. In the early 1990s, computer scientist, lawyer, and cryptographer Nick Szabo first proposed smart contracts which coined the term. In the latest implementations, based on blockchains, “smart contract” is often used more explicitly in the context of computing the general intent that takes place on a blockchain or distributed ledger (Al-Jaroodi and Mohamed 2019). There are various areas of healthcare where smart contracts can be applied for great benefit. 1. Health insurance Smart contracts can be used daily in health insurance and could reduce many inefficiencies in the current system. If patients use smart contracts to buy their insurance, all details of their policy will be automatically secured in their patient profile. This is then stored on the blockchain—a safe and secure ledger which is less prone to hackers than a traditional database. They could also eliminate the stress involved in having to file lengthy insurance claim forms. If an insurer was to go through a medical procedure that is covered by the insurance policy, the smart contract would be automatically triggered. This means that the money from the insurance company’s account will go straight to the hospital. This automation cuts out any delays and hassle and allows for correct payments of medical services. In turn, this would speed up all transactions between parties and ensure the procedure does not get delayed. 2. Health records Smart contracts allow records and information to be stored on a digital ledger. This means if a patient was moving from one hospital to another, they would be able to do so with ease and without having to fill out numerous forms. Records can then also be viewed by the patient’s preferred physician on the blockchain network. Hospitals and healthcare companies rely on a number of databases filled with patient information. However, these can be too restrictive to allow for the sharing of potentially life-saving insights around the globe. Without blockchain and smart contracts, this information may take a long time to reach the recipient and could potentially be hacked. If health records were kept in a smart contract and stored on the blockchain, that information would be available to hospitals and research institutions everywhere. With sufficient adoption, an individual could

4 Securing Healthcare Data by Using Blockchain

99

walk into any hospital in the world for treatment, and if they produce their private key, the hospital would have access to their information in a heartbeat. 3. Telemedicine Telemedicine is a medical field that is growing by the day. It allows physicians and doctors to reach their patients through the use of electronic devices, such as mobile phones and other IoT devices. It is primarily used for providing care for the terminally ill. Telemedicine allows doctors to take care of prescription compliance and collate real-time data measurements of their patients’ conditions. These modern advancements are helping to increase interoperability and reduce admin inefficiency while enhancing patient outcomes. However, telemedicine has downsides as the mechanisms involved are a large target for hackers. If smart contracts are used, the safety and privacy of a patient’s information and other important clinical data can be ensured. Smart contracts can be implemented on a large scale and stored on the blockchain to share and protect the data. They can also help to maintain data and ensure patients’ private information is stored securely and in a transparent manner. Smart contracts combined with blockchain technology represent the future of healthcare and medicine. They embrace high-level encryption and security that allows users, patients, and doctors to have trust that their information is safe and attack-proof. Byzantine fault-tolerant algorithms allowed smart contracts to shape digital protection through decentralization. Additionally, the programming languages with varying degrees of Turing-completeness as an integrated function of some blockchain make it possible to construct custom sophisticated logic (Khezr et al. 2019). Figure 4.3 shows the workflow with smart controlled access in a system.

Fig. 4.3 Workflow with smart controlled access in a system

100

M. Gupta et al.

4.2.2 Migration of Healthcare Chain Code in Blockchain The Hyperledger Global Forum is the most important annual platform for businesses implementing blockchain technology in the consortium. At the annual Hyperledger Forum, hundreds of blockchain enthusiasts come together to share their use cases and the latest advances in enterprise blockchain technologies (Bell et al. 2017). During the conference, a paper was presented on the ten critical issues and requirements to be considered using the Hyperledger Fabric-based Oracle Blockchain Platform (OBP) based on numerous business blockchain implementation projects. These ventures span the spectrum of sectors, including financial services, supply chain, healthcare, and government, and spectrum from custom innovations funded by the Oracle technology team to ISV technology and SI-led ventures. Those critical issues are as follows (Kenry and Lim 2016): • • • • • • • • • •

Using SQL for rich smart contract queries Save/recover data Checkpoint database and pruning/archiving Byzantine consensus tolerant of fault Governing Achievement Privacy & privacy protection Supporting the internetwork Crypto implementations pluggable Capacity audit.

Although the original public blockchain relies on a self-sovereign style of management with complete decentralization and rules governed by consensus algorithms, permitted blockchain is structured differently (Xu et al. 2020). Throughout the enterprise-permitted blockchain used in private or consortium implementations, participating companies are mostly concerned with effectively and resiliently managing their nodes and, at the same time, operating as part of a cross-company blockchain network (Saberi et al. 2019). This requires a secure and flexible model of governance and on-chain collaborative mechanisms to address the many operational issues at different layers of the blockchain network—from interoperable connections to storage management, membership management, chain code distribution, etc. When organizations set up their blockchain networks, they need to pay special attention to and develop their networks with a view on many issues (Nir Kshetri 2019). Figure 4.4 shows the healthcare system using blockchain.

4 Securing Healthcare Data by Using Blockchain

101

Fig. 4.4 Healthcare system using blockchain

4.2.3 Technology Used to Manage Healthcare Data The technology for implementation of the platform would be a decentralized application (DApp) supporting a private blockchain system with a distributed file system (DFS) at the back end. Ethereum is used to introduce a smart contract framework for healthcare blockchain. It is an open-source network and currently one of the largest public blockchain networks with an active community and a large collection of public DApps (Rejeb 2018). The platform currently uses a consensus proof-of-work (PoW) algorithm called Ethash, but developers are working to turn it into a proof-of-stake (PoS) scalability algorithm shortly. Ideally, for the design of distributed applications, a Delegated Proof-of-Stake (DPoS) or Practical Byzantine Fault Tolerance (PBFT) consensus algorithm is suitable. The DApp will have the potential to detect irregularities, unwanted data insertions, and missing entities by matching DFS information with ledger registers (Horst Treiblmaier 2020). Each phase is labeled with an Audit Timeline. The primary elements of the smart contracts are events, state variables, functions, and modifiers, and they were written in the language of a high level known as Solidity. To pay the transaction fee, Remix and Kovan test networks were used to deploy smart contracts on the test net and test net ethers. Three stages are involved in the development of smart contracts, which use Solidity programming to write, compile, and announce (Rodrigo da Rosa Righi 2020). The real-time compiler Solidity creates the bytecode. Ethereum Wallet has

102

M. Gupta et al.

been used to disclose smart Blockchain contracts. Figure 4.4 shows the function of Ethereum with smart contracts, where for simplification, the mining process is ruled out. This smart contract is compiled into machine-level bytecode, where each byte represents an operation and then added as an EVM-1 transaction to the blockchain. A miner picks it up and confirms Block-1. When a user passes the request through the Web interface, the EVM-2 queries embeds the Web-based data into Transaction tx and deploys it to the blockchain. In Block-2, the transaction tx status is changed. If node 3 decides to test the states stored in the contract, it will need to synchronize up to at least Block-2 later to observe the changes that tx makes (Crosby et al. 2020).

4.3 Proposed Model Authors propose a model that uses Ethereum’s smart contracts to construct smart representations of existing medical records that are stored within individual nodes on the network. Main focus is building contracts to include metadata, permissions, and data validity of record ownership. Blockchain transactions of our network hold cryptographically signed instructions to handle certain properties. State-transition contract functions execute laws, only through legal transactions that implement data alteration (Pournader et al. 2019). Such regulations can be designed to implement any set of rules that govern a specific medical record as long as it can be expressed in computational form. Such as, a policy can involve the sending of different consent transactions from both healthcare and patients providers before granting permission to a third party to access. So, a framework is developed for complex healthcare workflows that are based on blockchain smart contracts. In the healthcare environment, smart contracts were built for specific medical workflows, and then, data access permission was handled between various entities. A smart stored contract on blockchain technology could be built, where all the necessary conditions from handling various permissions to accessing data, as shown in Fig. 4.5. It can be seen that a variety of stakeholders are interested in this scheme performing distinct activities. It would help to create stronger physician-patient experiences. The rules regulating data authorization are integrated into smart contracts (Saberi et al. 2018). This can also help monitor all actions from their origin to their surrender, with unique Id. Distinct scenarios have been explained and designed alongside all the processes embedded, and functions in the smart contracts are well described. There will be no need for a centralized body to oversee and authorize the project because it can be handled directly through the smart contract that will greatly reduce the management process administration costs. To ensure consistency and economic viability, all healthcare record data is stored in local database storage, and the hash of data is the data part of the blockchain block joined to the chain (Chang et al. 2019). The proposed model uses Aadhar card verification combined with smart contracts in Ethereum blockchain for verification of one’s identity. This identity verification helps doctors to access the medical history of patients along with any current medications or treatments ongoing. The Aadhar data transactions are private keys (patient

4 Securing Healthcare Data by Using Blockchain

Fig. 4.5 Integrated framework of healthcare system with the existing system

103

104

M. Gupta et al.

or physician) signed by the owner. The network’s block content reflects data ownership and viewing authorization exchanged by various members of a private peer-topeer network. Thus, blockchain technology helps the utilization of smart contracts that allow automating and monitoring particular state transitions. On an Ethereum blockchain, one logs patient–provider relationships through smart contracts using Aadhar card that joins a healthcare record with viewing data retrieval. Permissions instructions (essentially information pointers) for external server execution to ensure against manipulation provide a cryptographic hash of the medical record on the blockchain to ensure data integrity (Pandey and Litoriya 2020). Figure 4.5 shows an integrated framework for the healthcare system with the existing system. Providers may attach a new record associated with a specific patient, and patients can require the sharing of records between providers. In both cases, the party receiving new information receives an automatic notification and may check the proposed record before approving or rejecting the data. That keeps the participants updated and involved in the evolution of their data and helps them decide and give control of data. This system prioritizes usability by also offering a designated contract based on Aadhar verification that aggregates references to all a user’s patient–provider relationships, thus providing a single reference point for checking for any updates in healthcare history. Also, it uses a public-key cryptography to handle identity verification and our utilization of a DNS-like implementation that maps the user’s Ethereum address to an already defined and commonly accepted type of ids such as name or social security number. A syncing algorithm handles “off-chain” data exchange between a patient database and a provider database. After referring the blockchain to validate permissions through our database authentication service, the data will exchange. Different medical workflows were planned and implemented through blockchain smart contract systems, involving unique medical procedures. Those involve providing simple medical prescriptions for the treatment of chronic diseases and their protocol for surgical patients as a recovery technique. The aim of developing these smart medical contracts is to promote the overcoming of administrative inefficiencies for the patients, doctors, and healthcare organizations. This program will assist in the recovery, review, and management of complex data and procedures in the healthcare sector (Kleinaki et al. 2018; Namasudra et al. 2017, Namasudra and Roy 2017, 2020a, b, c; Namasudra 2019). Table 4.1 shows the proposed model workflow for securing healthcare data by using blockchain. These workflows have been explained as separate entities with data flow in each of them. • Issuing and Filling of Medical Prescriptions Process The key objective is to smooth the process of healthcare prescription handling by deleting the long waiting period cycle, removing the fraud factor from the network, and the error rate caused by misinterpretations by the doctor. A doctor prescribes for the patient and sends it into a smart contract into the patient’s healthcare records. The pharmacy then accesses this prescription through the Ethereum blockchain smart contract through the primary doctor and a patient’s permission to do so. After the

4 Securing Healthcare Data by Using Blockchain Table 4.1 Proposed model workflows

105

S. no.

Workflow

1

Issuing and filling of medical prescriptions process

2

Sharing results data/laboratory test

3

Enabling patients and service providers effective communication

4

Healthcare reimbursement data flow

5

Smart contracts for clinical trials based on Ethereum

6

Cost estimation method

prescription has been obtained, the pharmacy then issues the drug via smart contracts along with its expiry date and dosage usage listed on the patient medical records. Then, the medication is ready for patient selection. Smart contract apps generally coordinate medicine satisfaction among doctors and drug stores. Doctors spend less time discussing demands for medication, or simply talking to drug stores during a patient’s visit (Namasudra 2018). As shown in Fig. 4.6, data flow for the issuance of a medical prescription involves patient, primary doctor (PD), and pharmacy. It also contains prescription information, which includes drug ID, date of expiry, a patient ID, etc. • Sharing Results Data/Laboratory Test Here, the primary objective is to exchange information through smart blockchain contracts by enabling hospitals, physicians, emergency clinics, and various partners to successfully access and share the therapeutic information of a patient among various stakeholders, as shown in Fig. 4.7. Find a case of use in which a patient visits a blood test laboratory. After processing, the laboratory must insert the causes into the patient records, the patient receives these updates via Ethereum blockchain, a note that the tests processed provides are Fig. 4.6 Data flow for medical prescription

106

M. Gupta et al.

Fig. 4.7 Smart contract for sharing lab results

accessible and can choose whether to allow the laboratory to encrypt the information and position it on Ethereum blockchain. The patient grants permission to post the details on the blockchain. The emergency room will be able to access patient details instantly through Ethereum blockchain whenever he and will have personalized care, and there is an emergency with the patient (Namasudra et al. 2017). By allowing medical records to be posted on healthcare blockchain, a medical prevents having to either bear the test reports on their own or arrange for records to be faxed to different care providers. He also makes sure all of his healthcare professionals know available to deliver the best quality treatment. Laboratories provide each printing and mail/fax regulatory expense for every test result to singular suppliers. Also, laboratories and patients have access to the healthcare blockchain, where they can receive installments from protective firms recommending the transferred information to process claims or from pharmaceutical companies choosing the information to be used in contemplates. Specialists and emergency departments have access to pool restorative knowledge about their patients at no expense, reducing authoritative research and expense. • Enabling Patients and Service Providers Effective Communication The patient applies to a healthcare condition in this case, as shown in Figs. 4.7 and 4.8. It immediately sends the question through the smart contract network to the primary doctor. For quality assurance, patient information related to disease is taken and respond with observations where it is possible. After analyzing the patient information they refer to the specialist for further treatment. Patient information about treatment history should be reported on the EHR.

4 Securing Healthcare Data by Using Blockchain

107

Fig. 4.8 Smart contract for enabling communication between patient and service provider

Please notice that a local database holds patient records, and there are unique rules that can have access to the record to what degree and to what degree the smart contracts on Ethereum blockchain control those rules, another case in which the patient applies a particular medical procedure. Accordingly, the strict structure of the agreement sends this submission to the correct professional. A doctor understands the demand and response with suggestions, but patients can exchange their thoughts with the specialist for further treatment. Any patient information regarding treatment history must be effectively reported on the EHR. Here, a nearby database provides patient records where there are principles that can approach the record to what extent the knowledgeable contracts on Ethereum blockchain administer these guidelines (Namasudra and Deka 2018). Patients looking for health information on a particular subject receive suggestions that are far more comprehensive than those given by a Web search. Senior doctors are finding a new way to monetize without having to overbook their expertise. In contrast, junior doctors can enter a novel potential customer audience and develop their brand within their nobility. Payments allow patients to seek Junior Doctors’ recommendations. • Healthcare Reimbursement Data Flow The key goal is to speed up the payment process for the healthcare system. In this, doctors will be able to proceed with care quickly, instead of having to put their patient’s treatment on hold while waiting for the payer to respond. Automated smart contract execution will supervise the entire operation. This process is reducing and removing-human effort to manually review the payment where patients needs to requests for prior authorization. It also reducing appeals caused by misinterpretation of manually written prior authorization for medical treatment (Sarkar et al. 2015). Medical Insurance Company posts its policies via smart blockchain contracts, which contain the policies used to decide authorization. A manufacturer then lodges a submission for prior authorization for a specialist consultation, diagnosis, or prescription using the blockchain. The payer’s smart contract for a medical policy automatically decides authorization using the patient’s medical details stored by Ethereum

108

M. Gupta et al.

blockchain and the details in the request. Authorization data is then immediately returned to the supplier. Also, the patient, as well as any laboratories, hospitals, specialists, and other stakeholders to whom the patient has delegated access, could check the authorization for insurance in real time. The entire cycle is shown in Fig. 4.8. The automated prior authorization process will result in considerable cost savings for payers, which currently spends significant sums on manual analysis and response to requests. Doctors will continue with treatment immediately, rather than having to pause their patient’s care while waiting for the payer’s response. Patients will be spared concerned about how their insurance will cover the medication their doctor recommends. With details on prior authorization readily accessible, physicians and patients can work together comfortably with a treatment plan tailored specifically to the patient’s needs and the correct insurance coverage. • Smart Contracts for Clinical Trials Based on Ethereum Allowing medical device and drug manufacturers with a quicker and more costeffective alternative to the existing recruitment in clinical trials also entails substantial expenditures in purchasing patient contact information from independent data suppliers and carrying out extensive pull-marketing campaigns. The primary goal is to allow users to run clinical trial-related smart contracts on an Ethereum network leading to secure medicines and improved public interest in medical research. Thus, in this phase, authors manage metadata via smart contracts, considering protocol registration, preset study information, screening, and enrollment logs. A pharmaceutical company is looking for metadata stored on the Ethereum blockchain to classify possible patients for clinical trial inclusion, as seen in Fig. 4.9. The organization then sends a letter to read access to their medical records for selected patients, including any related laboratory test results. The patient permits access, a pharmaceutical company bill will be processed via smart contracts, awarding the patient part of the fee paid, and another portion to the laboratories, which recorded the patient’s correct test results. Medical devices and drugs and manufacturers can dramatically reduce spending on data purchases and marketing campaigns by targeted targeting of eligible consumers, as shown in Fig. 4.10. Patients, meanwhile, will gain access to alternative care options, in addition to obtaining compensation for participating in trials. Laboratories engaged in posting results would have a new way to monetize their data. • Cost Estimation Method In terms of deploying medical blockchain, an assessment of the costs associated with implementing smart contracts for healthcare needs to be made. The ultimate aim is to develop a program with all the advantages of blockchain that can offer a feasible electronic health system. In Ethereum blockchain, all programmable calculations cost some fees to prevent network misuse and to solve other computer-related issues. The fee for running all kinds of transactions in the Ethereum blockchain is listed as gas. Gas refers to the payment or price value provided by the Ethereum blockchain

4 Securing Healthcare Data by Using Blockchain

109

Fig. 4.9 Smart contracts for healthcare reimbursement

Fig. 4.10 Clinical trials smart contracts

platform for a successful transaction or execution of a contract. The exact gas price is calculated by the miners of the network, who will refuse to process a transaction if the gas price does not reach their cap. All operations, computations, message calls, smart contract creation/deployment, and storage on Ethereum virtual machines (EVM), therefore, require gas to perform all of these tasks. Figure 4.11 presents the smart contract Metamask extension cost calculation. To perform transactions on Ethereum virtual machines, if anyone wants to do some kind of activity on EVM, they need to have a certain amount of gas in their account.

110

M. Gupta et al.

Environment Injected Web 3 Account 0c940..7c074 (2 ether) Gas Limit 3000000 Value 0

Contract Deployment $0.00 0 DETAILS DATA GAS FEE $0.18 Amount-GAS FEE TOTAL $0.18 Reject

Confirm

Fig. 4.11 Calculating smart contract cost Metamask extension

Each transaction has a gas limit, so if there is any unused gas, it will return to the user account after the transaction has been executed. If a user does not have a valid balance account, he is unable to perform any sort of operation and is therefore deemed to be invalid. In EVM Ethers, gas is purchased, and users running the transactions can set their account gas limit for the particular transaction. But again, whether they want to authorize the transaction or not, it is on the miner. If a sender opts for a higher gas price, paying for the gas will cost them a high price, and miners will get great value for the transactions. A miner then performs the computation to connect the transaction to a stack. A miner could then broadcast the new block into the network after the successful execution of transactions.

4.4 Performance Analysis 4.4.1 Experimental Setup This section discusses the way of securing healthcare data using blockchain are discussed as follows.

4.4.2 Results and Discussions The proposed system has many advantages over the existing models that have not implemented blockchain technology.

4 Securing Healthcare Data by Using Blockchain

111

1. The model is much secure as it uses smart contracts and various encryption algorithms to achieve that 2. There is no central dependency ensuring that each node participates in data flow, and the flow path cannot be predicted. 3. Timings of each and every task are reduced by much which will help to provide the best possible care to a patient. 4. Laboratory data can be directly shared with doctors thus eliminating the paper trail thus reducing errors. 5. Prescriptions are digitized making admittance of patients easier and simpler. Feature

Existing system

Proposed system

Central dependency

Yes

No

Security

Low

Moderately high

Smart contract management

No

Ethereum smart contracts

Reimbursement, lab result timings

High

Low

Encryption

No

Public-key cryptography

User privacy

Every doctor can view the record and user cannot

Doctor can only view record with patient’s consent

Error rate

Moderate

Low

Patient admittance

Time taking with long paper trails

Easy as records are digitized

4.5 Conclusions and Future Works The system thus explained will help in each and every sector of healthcare. The system proposed by the authors uses smart contracts to provide the security to data over transfer. The traditional system is much more prone to attacks as the blockchain and smart contracts are not implemented in it. Thus, in each and every sector from filling the forms to clinical trials, smart contracts are introduced. These provide encrypted data thus preventing data loss and making the transfer much more secure. The system proposed is not centrally dependent, instead uses several nodes of blockchain and uses smart contract encryption, thus making the data transfer much easier and secure and much more difficult to attack. This system can be used to replace the traditional system due to its security and various other benefits.

112

M. Gupta et al.

References Abou Jaoude, J., & George Saade, R. (2019). Blockchain applications—Usage in different domains. IEEE Access, 7, 45360–45381. Agbo, C. C., & Mahmoud, Q. H. (2020). Blockchain in healthcare. Ahram, T., Sargolzaei, A., Sargolzaei, S., & Daniels, J. (2017). B. Amaba Blockchain technology innovations. In 2017 IEEE technology and engineering management society conference TEMSCON (pp. 137–141). Al-Jaroodi, J., & Mohamed, N. (2019). Blockchain in industries: A survey. IEEE Access, 7, 36500– 36515. Alladi, T., Chamola, V., Parizi, R. M., & Choo, K. R. (2020). Blockchain applications for Industry 4.0 and Industrial IoT: A review. IEEE Access, 1. Bell, L., Buchanan, W. J., Cameron, J., & Lo, O. (2017). Applications of blockchain within healthcare. Blockchain in Healthcare Today, 1–7. Biswas, K., & Muthukkumarasamy, V. (2017). Securing smart cities using blockchain technology. In Proceedings of 18th IEEE international conference on high performance computer and communication. 14th IEEE International Conference Smart City 2nd IEEE International Conference Data Science System. HPCC/SmartCity/DSS (pp. 1392–1393) (2016). Chang, Y., Iakovou, E., & Shi, W. (2019). Blockchain in global supply chains and cross border trade: A critical synthesis of the state-of-the-art, challenges and opportunities. International Journal of Production Research, 1–18. Crosby, M., Pattanayak, P., Verma, S., & Kalyanaraman, V. (2020). BlockChain technology: Beyond bitcoin. Applied Innovation Review, 5–20. Dennis, R., & Owen, G. (2015). Rep on the block: A next generation reputation system based on the blockchain. In 2015 10th international conference for internet technology and secured transactions ICITST 2015 (pp. 131–138). Deshpande, A., Stewart, K., Lepetit, L., & Gunashekar, S. (2017). Overview report distributed ledger technologies/blockchain: Challenges, opportunities and the prospects for standards. Genestier, Jp., Zouarhi, S., Limeux, P., Excoffier, D., Prola, A., Sandon, S., et al. (2017). Blockchain for consent management in the eHealth environment: A nugget for privacy and security challenges. Journal of the International Society for Telemedicine eHealth, 5, 24–25. Gordon, W. J., & Catalini, C. (2018). Blockchain technology for healthcare: Facilitating the transition to patient-driven interoperability. Computational and Structural Biotechnology Journal, 16, 224–230. Hölbl, M., Kompara, M., Kamišali´c, A., & Zlatolas, L. N. (2018). A systematic review of the use of blockchain in healthcare. Symmetry (Basel), 10. Horst Treiblmaier, T. C. (2020). Blockchain and distributed ledger technology use cases. Kenry, J. C. Y., & Lim, C. T. (2016). Emerging flexible and wearable physical sensing platforms for healthcare and biomedical applications. Microsystems Nanoengineering, 2. Khatoon, A. (2020). A blockchain-based smart contract system for healthcare management. Electronics, 9. Khatoon, A., Verma, P., Southernwood, J., Massey, B., & Corcoran, P. (2019). Blockchain in energy efficiency: Potential applications and benefits. Energies, 12, 1–14. Khezr, S., Moniruzzaman, M., Yassine, A., & Benlamri, R. (2019). Blockchain technology in healthcare: A comprehensive review and directions for future research. Applied Science, 9, 1–28. Kleinaki, A. S., Mytis-Gkometh, P., Drosatos, G., Efraimidis, P. S., & Kaldoudi, E. (2018). A blockchain-based notarization service for biomedical knowledge retrieval. Computational and Structural Biotechnology Journal, 16, 288–297. Kshetri, N. (2018). Blockchain’s roles in meeting key supply chain management objectives. International Journal of Information Management, 39, 80–89. Kuo, T-T, & Ohno-Machado, L. (2004) Education ModelChain: Decentralized privacy-preserving healthcare predictive modeling framework on private blockchain networks (pp. 1–15).

4 Securing Healthcare Data by Using Blockchain

113

Makhdoom, I., Abolhasan, M., Abbas, H., & Ni, W. (2019). Blockchain’s adoption in IoT: The challenges, and a way forward. Journal of Network and Computation Applications, 125, 251–279. Mougayar, W. (2020). The business blockchain: Promise, practice, and application of the next internet technology. Namasudra, S. (2018). Cloud computing: A new era. Journal of Fundamental and Applied Sciences, 10(2), 113–135. Namasudra, S. (2019). An improved attribute-based encryption technique towards the data security in cloud computing. Concurrency and Computation: Practice and Exercise,, 31(3). https://doi. org/10.1002/cpe.4364. Namasudra, S., Chakraborty, R., Majumder, A., & Moparthi, N. R. (2020a). Securing multimedia by using DNA based encryption in the cloud computing environment. ACM Transactions on Multimedia Computing, Communications, and Applications (in Press). Namasudra, S., Deka, G. C., Johri, P., Hosseinpour, M., & Gandomi, A. H. (2020b). The revolution of blockchain: State-of-the-art and research challenges. Archives of Computational Methods in Engineering. https://doi.org/10.1007/s11831-020-09426-0. Namasudra, S., Devi, D., Kadry, S., Sundarasekar, R., & Shanthini, A. (2020c). Towards DNA based data security in the cloud computing environment. Computer Communications, 151, 539–547. Namasudra, S., & Deka, G. C. (2018). Advances of DNA computing in cryptography. Taylor & Francis. ISBN: 9780815385325. Namasudra, S., & Roy, P. (2017). Time saving protocol for data accessing in cloud computing. IET Communications, 11(10), 1558–1565. Namasudra, S., Roy, P., Balamurugan, B., & Vijayakumar, P. (2017a). Data accessing based on the popularity value for cloud computing. In Proceedings of the international conference on innovations in information, embedded and communications systems (ICIIECS). Coimbatore, India: IEEE. Namasudra, S., Roy, P., Vijayakumar, P., Audithan, S., & Balamurugan, B. (2017b). Time efficient secure DNA based access control model for cloud computing environment. Future Generation Computer Systems, 73, 90–105. Nir Kshetri, E. L. (2019). Blockchain adoption in supply chain networks in Asia. IT Professionals, 21, 11–15. Pandey, P., & Litoriya, R. (2020). Securing and authenticating healthcare records through blockchain technology. Cryptologia, 1–16. Pournader, M., Shi, Y., Seuring, S., & Koh, S. C. L. (2019). Blockchain applications in supply chains, transport and logistics: A systematic review of the literature. International Journal of Production Research, 1–19. Ratta, P., Kaur, A., & Sharma, S. (2020). Blockchain—Secure decentralized technology blockchainSecure decentralized technology. Rejeb, A. (2018). Blockchain potential in Tilapia supply chain in Ghana. Acta Technica Jaurinensis, 11, 104–118. Rodrigo da Rosa Righi, M. S. (2020). Antonio Marcos Alberti blockchain technology for Industry 4.0. Saberi, S., Kouhizadeh, M., Sarkis, J., Shen, L. (2018). Blockchain technology and its relationships to sustainable supply chain management. International Journal Production Research, 1–19. Saberi, S., Kouhizadeh, M., Sarkis, J., & Shen, L. (2019). Blockchain technology and its relationships to sustainable supply chain management. International Journal of Production Research, 57, 2117–2135. Sarkar, S., Saha, K., Namasudra, S., & Roy, P. (2015). An efficient and time saving web service based android application. SSRG International Journal of Computer Science and Engineering (SSRG-IJCSE), 2(8), 18–21. Schöner, M., Kourouklis, D., Sandner, P., Gonzalez, E., & Förster, J. (2017). Blockchain technology in the pharmaceutical industry. FSBC Working Paper (pp. 1–9). Shen, B., Guo, J., & Yang, Y. (2019). MedChain: Efficient healthcare data sharing via blockchain. Applied Sciences, 9.

114

M. Gupta et al.

Siyal, A. A., Junejo, A. Z., Zawish, M., Ahmed, K., Khalil, A., & Soursou, G. (2019). Applications of blockchain technology in medicine and healthcare: Challenges and future perspective. Cryptography, 3. Tamazirt, L., Alilat, F., & Agoulmine, N. (2018). Agoulmine blockchain technology: A new secured electronic health record system. In 2018 International Workshop on Advances ICT Infrastructures and Services (Vol. 134). Warkentin, M., & Orgeron, C. (2020). Using the security triad to assess blockchain technology in public sector applications. International Journal of Information Management, 52, 102090. Wu, X., & Lin, Y. (2019a). Blockchain recall management in pharmaceutical industry Blockchain management in pharmaceutical 28th recall A new methodology to physical architecture of existing products for an assembly oriented product family identification functional and recall. Procedia CIRP, 83, 590–595. Wu, X., & Lin, Y. (2019b). Blockchain recall management in pharmaceutical industry. Procedia CIRP, 83, 590–595. Xu, X., Pautasso, C., Gramoli, V., Ponomarev, A., & Chen, S. (2020). The blockchain as a software connector.

Chapter 5

Secure and Decentralized Management of Health Records Subramanian Venkatesan, Shubham Sahai, Sandeep Kumar Shukla, and Jaya Singh

Abstract The electronic Health (eHealth) record transforms the conventional healthcare domain into a digital healthcare domain that advances the service to the people. The eHealthcare gained more attention these days due to its benefits such as ease in transferring the record, available at all times, and effortless search and access. However, security and user privacy slow down the broader implementation of eHealthcare in various hospitals and countries. To utilize the effectiveness of eHealthcare and protect the data against various attacks, this chapter proposes a blockchain-based electronic health record management system. The encrypted eHealth records are stored on the cloud or Inter Planetary File System (IPFS) and the meta-data of the records on the blockchain to ensure data availability, integrity, and confidentiality. The proposed system provides immutable logging of access information for audit and regulatory compliance. In addition, the patient’s redundant account problem and data inaccessibility during the patient’s unresponsive state are addressed. The proposed system is implemented by modifying the goethereum implementation to analyze the overhead and applicability. The implementation results, security, and overhead analysis substantiate the proposed eHealthcare management system. Keywords eHealth · Blockchain · Security · IPFS · Cloud

S. Venkatesan (B) · J. Singh Department of Information Technology, Indian Institute of Information Technology, Allahabad, India e-mail: [email protected] J. Singh e-mail: [email protected] S. Sahai · S. K. Shukla Department of Computer Science and Engineering, Indian Institute of Technology, Kanpur, India e-mail: [email protected] S. K. Shukla e-mail: [email protected] © The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2021 S. Namasudra and G. C. Deka (eds.), Applications of Blockchain in Healthcare, Studies in Big Data 83, https://doi.org/10.1007/978-981-15-9547-9_5

115

116

S. Venkatesan et al.

5.1 Introduction The eHealth record management systems have several benefits over the traditional systems, such as: facilitating fast diagnosis, avoiding repetition of pathological tests, promoting advanced treatments, and ensuring the availability of the data whenever required. Overall 84 percent of US hospitals have adopted the electronic health record system (Henry et al. 2016). However, there are countries with less than 50 percent adoption of electronic health record systems although percentage will increase in near future because of broader requirements. In general, eHealth records of the patients are stored in a centralized storage server and either maintained by the hospital administration or outsourced to a trusted third party. The health records stored in a centralized server could be accessed by various agencies according to their authorization. The key question to ponder over is how to share these records among various stakeholders by ensuring integrity and privacy. The drawbacks with traditional electronic health/medical record management systems are that there is no guarantee for the integrity, privacy, and availability of the record, and need to trust a third party for managing the database. It is also not straightforward to connect various hospitals to share these records each other and connect them seamlessly for the greater good. The eHealth record management system provides several benefits when compared to the traditional paper-based record management system; however, security requirements such as patient’s record privacy, integrity, and availability minimize the large utilization. Even though there are models and systems that exist to provide the security requirements, unauthorized administrator access, redundant patient’s account, access of record during patient’s unresponsive state, etc., are not addressed. The present need of eHealth record management system and unsolved security issues triggered to develop a secure and decentralized eHealth record management system using blockchain technology thus enables larger utilization. In the past decade, it has been seen a range of applications of the blockchain technology in e-governance and other kinds of data sharing and transaction applications. It is believed that blockchain solves the problem of data sharing among the right stakeholders without compromising the privacy of data, maintaining the integrity of data throughout its life cycle, and availability through redundancy. Therefore, blockchain-based solution to health record management has a lot of potentials. In the proposed system, the immutability of blockchain and IPFS/multi-cloud is utilized to ensure integrity, confidentiality, and availability of the health record. The proposed system keeps meta-data of the health records that are the message (record) digest, hospital original or pseudo-identity, and access permissions in the blockchain and encrypted health record in the cloud/IPFS to ensure the availability. A user wishes to access the patient record need to get the access permission from the patient subsequently the proxy re-encrypted record will be provided. The remaining section of this chapter is organized as follows: Sect. 5.2 discusses the existing techniques, Sect. 5.3 presents the problem statement, Sect. 5.4 discusses the background studies, Sect. 5.5 presents the proposed system, Sect. 5.6 analyzes the

5 Secure and Decentralized Management of Health Records

117

security of the proposed system, and Sect. 5.7 discusses the implementation, experimental results, and overhead of the proposed system when compared to existing nonblockchain-based eHealth record management system. Finally, Sect. 5.8 concludes the chapter with the directions of future work.

5.2 Literature Review The Health Insurance Portability and Accountability Act of 1996, known as HIPAA (HIPPA 1996), and National eHealth Authority known as NeHA (NeHA 2018) emphasize on the confidentiality and integrity of health information. Conceicao et al. (2018) indicated the cost issue in the electronic health record management system that even records are maintained by nonprofit organizations, the maintenance of reliable infrastructure in a large scale and control access to them demands significant resources. Even though there are various existing works present in the literature for the eHealth record management system, blockchain-based solution is preferred since it ensures the decentralization, immutability, etc. In the past decade, several applications of blockchain have been witnessed; it is also believed that blockchain is one of the best solutions for securing healthcare data (Namasudra et al. 2020), and researchers implemented in different perspectives. The promising uses of the blockchain in eHealth record management system include improving the security and management of patient data, reducing the regulatory and compliance cost, optimizing the interactions between the hospital and insurance providers, etc. (Tierion, 2016). Vazirani et al. (2020) analyzed and recommended blockchain since it supports efficient management of medical records and ensures interoperability but without compromising security. Azaria et al. (2016) developed a prototype MedRec, which is a decentralized and modular health record management system that takes advantage of the Ethereum blockchain for accountability, authentication of stored information, and access. In the prototype, data is stored at a trusted third party and its meta-information in the blockchain. Even though MedRec uses blockchain technology, its security depends on the trusted third party. Yip (2016) discussed the use of blockchain in processing insurance claims in a positive way. The author suggested to keep insurance claim record on a private blockchain and provide access only to the organization that exchanges data, and has it with real-time updated. Therefore, the claims can be processed more quickly and could mitigate false claims and make sure that the final bill is correct. Shrier et al. (2016) state that the existing centralized IT systems are vulnerable to hacking and proposed a solution using blockchain. Kuo et al. (2017) discussed the advantage of using blockchain for biomedical and healthcare applications. Vian et al. (2016) discussed the issues in the Medicaid healthcare programs and the use of blockchain to solve it. Goldwater (2016) addresses the problem of storing the personal health data gathered from all kinds of new devices and software such as wearables and mobile on the cloud and proposed a solution that uses blockchain technology as a base, for bringing greater security to protect the data.

118

S. Venkatesan et al.

Theodouli et al. (2018) proposed a blockchain-based system to facilitate healthcare data sharing. The system ensures record integrity but not confidentiality; however, it ensures privacy by anonymizing the identity of the patient. A patient can upload their plain clinical data directly to the cloud with or without having an account. Since the records are plain, research centers/researchers can use it for analysis purposes even without the consent of the patient. The drawbacks of the system are: The patient has no control over record access; the cloud has the complete control of the record and no guarantee of integrity since the record sharing is managed by the cloud. Xia et al. (2017a, b) proposed the blockchain-based eHealth record sharing model using the cryptographic keys and smart contracts. However, data loss due to thirdparty malicious behavior is not considered in the proposal. Dubovitskaya et al. (2017) have proposed a secure and trustable health record sharing using blockchain. However, it needs additional overhead in sharing the public key. Peterson et al. (2016) presented the blockchain-based approach for health information exchange networks using Proof of Interoperability (PoI). It follows the Fast Healthcare Interoperability Resources (FHIR) standard (HL7 2018) for medical data representation and keeps the URL on the blockchain. It allows privacy-preserving keyword searches; however, the security is based on a third party. Khatoo (2020) proposed a smart contract-based healthcare management system for large-scale data management and to streamline the complex medical procedure. The model used the social security number to map the Ethereum address of the user. The major focus of the system is to manage the different permissions to access the data. However, this model does not considered the issues such as hash conflict, secure sharing, etc. Inefficient key sharing, unauthorized creation of records, the conflict between data and meta-data in networks, and storage failures are the issues not addressed in the existing works. The proposed eHealth record management system provides the solutions for those issues using blockchain technology, proxy re-encryption, and cloud/IPFS.

5.3 Problem Statement The important security requirements that eHealth record management systems need to ensure are confidentiality, integrity, and availability (Hasan et al. 2007). The data modification and unauthorized disclosure are always the issues in the eHealth record management system since in most cases data is maintained by the third party. The eHealth records should not be modified by unauthorized users; otherwise, treatment and analysis may kill the patient and the patient’s record privacy is an important requirement to avoid the consequent issues, such as neighbor’s activity, knowledge of regular medication, and misuse.

5 Secure and Decentralized Management of Health Records

119

• Privacy: To ensure the privacy of records, it can be encrypted by the hospital using the public key of the patients. However, Public Key Infrastructure-based key sharing is not feasible because of various factors such as cost and a digital certificate for every patient. • Integrity and availability: An attack against integrity and availability can be prevented simply by taking the message digest of health records and hosts in multiple sites. However, the Byzantine General Problem (BGP) (Lamport et al. 1982) will be a major threat. For example, the insider who generates the message digest may share different digests to different sites. A distributed system with distributed consensus is required to overcome the BGP. Also, it is not straightforward to connect various hospitals to share these records seamlessly for the greater good. Hence, the aim is to come up with a system that facilitates distributed storage, efficient key sharing, and decentralized trust. A blockchain is a natural choice satisfying these requirements, thereby our choice of technology for designing this system. Attacks that can be addressed by the proposed electronic health/medical record management system are as follows. • Unauthorized modification of record: An attacker may modify the record to harm the patient and treatment. • Unauthorized record access: An attacker may illegally access and disclose the record to unauthorized persons. • Unauthorized creation of record: An attacker may create a false record to harm the patient. • Ransomware: The software spread by an attacker may encrypt the health records, delay or stop the treatment, and claim for ransoms to provide the decryption key. • Malicious hospital administrator: A compromised administrator can make the record unusable by creating conflict between the record and meta-data.

5.4 Background Studies This section discusses the key concepts used in the proposed eHealth record management system.

5.4.1 Blockchain Types The blockchain introduced in the Bitcoin is public, which allows any user or organization to join and contribute. Later, the effectiveness of blockchain and lightweight applications motivated the researchers to develop different types. The types of blockchain are as follows.

120

S. Venkatesan et al.

Public or Permissionless: This allows any individual (node) or an organization to join the network and participate in blockchain activities such as mining, block validation, and making transaction. No prior authentication or approval required for a node to join. The consensus protocols used are Proof of Work (PoW), Proof of Stake (PoS), etc. Permissioned: It allows only the authenticated or approved users to take part in the blockchain activities. It uses consensus protocols based on Byzantine Fault Tolerance (BFT) and crash fault tolerance.

5.4.2 Ethereum The Ethereum is a blockchain-based platform for decentralized applications. It has various features including world state and smart contract. The world state is a mapping between user addresses and account states. This mapping is maintained in the Merkle Patricia Trie (MPT), and its root is part of the block header. The world state provides the updated account information of all users in the latest block, thus no need to traverse the blocks to find the account information of a user. A smart contract is a self-enforcing agreement embedded in the form of executable code managed by a blockchain. The code contains a set of rules under which the parties of that smart contract agree to interact with each other. The agreement will be enforced whenever the predefined rules are met. It is a part of the blockchain and ensures transparency and shared ledger, where they are protected from deletion, tampering, and revision. The drawback of the smart contract is not possible to update once it is hosted on the blockchain since the hash of the code is used for indexing. Hence, the smart contract code should be tested in the test network before deploying in the main network. The proposed system is implemented by modifying the goethereum, an implementation of Ethereum however not utilized the smart contract.

5.4.3 Proxy Re-encryption It is used when a party would like to share the received content, which is encrypted using its public key by another party without disclosing the private key. For example, Alice received a content encrypted using her public key from Bob. Now, Alice would like to share the content with Charlie without disclosing her private key as well as without performing decryption and re-encryption with Charlie’s public key. In this case, Alice uses the proxy re-encryption to do it. Now, Alice can generate a proxy re-encryption key using her private key and Charlie’s public key and designate a proxy to re-encrypt the encrypted content using it. The proxy re-encrypted content can be shared with Charlie. Charlie can decrypt the proxy re-encrypted content using his private key. The requirement is achieved without disclosing the content to proxy and decryption at Alice end (Qin et al. 2016).

5 Secure and Decentralized Management of Health Records

121

5.4.4 Merkle Tree In cryptography, a Merkle tree or hash tree is a tree, where leaf nodes are a hash of the data block and non-leaf nodes are a hash of its child nodes. The concept of a hash tree is named after Ralph Merkle who patented it in 1979 (Merkle Tree 2019). The sample Merkle tree is shown in Fig. 5.1. The leaf nodes (L 1 and R1 ) of Merkle tree are hash (h) value of the data blocks (MB1 , MB2 , MB3 …), and non-leaf nodes (L 2 and R2 , L 3 and R3 and Root) are the hash values of its child nodes. The root hash of the tree will be shared to manage the integrity of the data without keeping the complete tree. The hash function used in the Merkle tree is a cryptographic hash function. The Merkle tree can be used to verify the integrity of the data that is data stored, handled, and transferred in and between peer network nodes are undamaged and unaltered. Merkle tree is used in blockchain to store transactions, account balances, etc. The Practical Algorithm To Retrieve Information Coded In Alphanumeric (PATRICIA) is also a type of trie, and it was first described in 1968 by Donald R. Morrison (1968). This is similar to radix tree with radix equal to 2 and has an innovative concept to store n items in the n nodes. It is very compact that if a node is only one child for a parent then it gets merged with the parent. The way it is used in cryptocurrency especially in Ethereum [17] is with the Merkle tree known as Merkle Patricia Trie (MPT) to ensure the integrity of the data that is transactions, world state, etc.

5.5 Proposed System The architecture of the proposed blockchain-based eHealth record management system is shown in Fig. 5.2. The nodes such as hospitals are the part of the blockchain network and take active participation by doing mining, validation of transactions, etc. All hospitals maintain the growing blockchain, ensure the liveness of the application and availability of data. Also, the hospitals are connected with the cloud/IPFS to keep

Fig. 5.1 Merkle tree

122

S. Venkatesan et al.

Fig. 5.2 Architecture of blockchain-based eHealth record management system

the encrypted data and access on-demand. Along with hospitals, government organizations and insurance agencies can also take part in the blockchain activities and use the services of the blockchain by accessing the statistics and necessary authentic data in an authorized way. The system includes the following entities to maintain the record securely and make it available at all times. All entities except the cloud and IPFS are part of the blockchain and integrate the blockchain with the cloud/IPFS. • Patient: A user possessing the unique address, public and private key pair, and more importantly owner of the record. • Doctor: A user possessing the unique address, public and private key pair, and creator of the patient’s record. • Hospital: A user (or organization) having facility for medical treatment including doctors, diagnose kits, prepare eHealth records, encrypt, and store it on the thirdparty storage. Also, able to access patient records with the consent of the patient and refer for further treatment. • Agencies: A user or organization, which uses the eHealth records for statistical analysis, insurance claim, research, etc. • Cloud/IPFS: A third-party storage to keep the encrypted record.

5 Secure and Decentralized Management of Health Records

123

Whenever a patient visits the doctor of a hospital for a consultation, it is the responsibility of the hospital to prepare the patient eHealth record, encrypt using the patient’s public key, and store it on the cloud/IPFS for seamless service. At the same time, meta-data of the respective patient record needs to be generated and posted into the blockchain through a transaction, which will be validated and committed into the block. The meta-data of the patient’s record along with access information is stored in the MPT of blockchain. The structure of the patient’s record and blockchain’s MPT node for the patient and hospital is as follows. • Record structure {Pid , F id , HR, H HR , D, Did , Dsid , Pcon , H PR }: It includes unique pseudo-identity of patient (Pid ) and file identity (F id ) of the record that is unique for the patient, and it sequentially increases by one for every new record, eHealth record (HR) of a patient, record hash (H HR ), date (D) on which consultation or treatment is done, doctor identity (Did ), unique disease identity (Dsid ), patient consent (Pcon ) for the record, and previous record hash (H PR ) of the patient which will be zero for the very first record. The HR will be encrypted using the patient’s public key and stored in the cloud/IPFS. The patient personal details like name, age, parents’ name, address, guardian, etc., are not part of this record. This information will be stored separately and linked with the patient pseudo-identity to maintain privacy. • Node structure of a patient {Pid , Ppub , H HR , H id , A, HU, O}: It includes unique patient identity (Pid ) similar to Bitcoin/Ethereum address, public key (Ppub ) of the patient, which will be used by the hospital to encrypt the record, patient’s latest record hash (H HR ), hospital identity (H id ) to maintain the meta-information host identity, access structure (A) to keep the eHealth record access permission data, last hash update (HU) to maintain the patient’s last hash update block number and optional (O) field, which is used while records are stored in the IPFS. • Node structure of a hospital/doctor {H id /Did , H pub }: It includes a unique hospital/doctor identity (H id /Did ) and public key (H pub ) of the hospital/doctor, which will be used by the patient to generate proxy re-encryption key. • Node structure of a disease {DS id , St}: It includes unique disease identity (DS id ) and statistics (St) for the statistical information such as the age and region-wise count. The proposed system includes the following three different transactions, respectively, to post the meta-data (hash of the record), and grant or revoke access permission and key update. • Record (Pid , F id , H id , H HR , Pcon , sig, t): This transaction is to post the meta-data of a health record into the blockchain. The meta-data (H HR ) is the cryptographic hash of the eHealth record to ensure integrity. Any hospital of the blockchain network can create the transaction and broadcast it to the network. The miners including the transaction owner take the transaction and validate it. The validation includes signature (sig) validation, timestamp (t) validation, patient address (Pid ), and consent (Pcon ) validation. The successful transaction will be committed to the new block, and the existing meta-data, hospital identity (H id ), and file identity

124

S. Venkatesan et al.

(F id ) will be replaced with the new on the patient’s MPT node if the node exists; otherwise, a new node will be created and stored. • GrantRevoke (ty, Pid , H id , F id , sig, t): This transaction will be created and posted by the patient to grant or revoke permission to hospitals/agencies to access the records. The transaction includes the type (ty): 1 for grant and 0 for revoke, the data request hospital’s identity (H id ), patient identity (Pid ), and file (record) identity (F id ). At first, the transaction signature, identity, and timestamp will be validated and then committed to the block, if it is valid. The commit is adding the transaction in the block and updates the access structure (A) of the patient. • Key (pa |ha , H pub or Ppub , sig, t): This transaction is to update the public key (H pub or Ppub ) of the transaction owner. If the transaction is valid, then the key will be updated. The reason for keeping the public key of the hospital and patient in the blockchain is to reduce the delay in sharing the key. The public key stored in blockchain for data encryption and proxy re-encryption is different from the key pair that is used for blockchain account creation since it is advised not to use the same key for different purposes because in one attack all protection walls will be compromised.

5.5.1 Record Management The record management includes indexing, storing, accessing, and sharing of the patient’s encrypted eHealth record and equivalent meta-data. The hospital has to prepare the eHealth record of a patient and securely store it in the cloud/IPFS. Since the patient public key (Ppub ) is available in the blockchain, the hospital can encrypt the record using the Ppub , obtain C, and store it in the cloud/IPFS. The process of indexing, storing, and accessing varies for the cloud and IPFS; however, both have a similar method of sharing. Cloud: The process flow of indexing and hosting is shown in Fig. 5.3. The encrypted record (C) along with the previous/preceding record hash (H p ) is stored in the cloud with index as the patient’s identity (Pid ) and file identity (F id ). The new file identity is the increment of the previous file identity. The hash of the concatenated plain record and previous record hash sent through Record transaction will be committed in the patient’s MPT node’s record hash attribute. The record can be accessed by providing the patient and file identity to the cloud. The reason for storing the preceding record hash along with the succeeding record is to validate the integrity of preceding records since the meta-data of the records other than the latest record is not part of the latest block. IPFS: The index of a record is the hash value of it. The process flow of indexing and hosting data is shown in Fig. 5.4. The encrypted new record and the previous record index (H pi ) are hashed to create the IPFS index accordingly encrypted new record and previous record index are stored. The same index will be placed in the patient’s MPT node’s optional (O) attribute. Also, the plain record hash will be stored in the MPT’s hash attribute to validate the integrity of the record. The optional (O) attribute

5 Secure and Decentralized Management of Health Records

125

Fig. 5.3 Data indexing and hosting at cloud

Fig. 5.4 Data indexing and hosting at IPFS

index will be used to locate and access the encrypted health records from the IPFS. The function h() is the cryptography hash function like SHA 256. The latest block contains only the latest record index and thus allows accessing the latest record. A user can fetch preceding records using the index value available in the accessed records. Similarly, the record’s integrity will be verified using the meta-data present in the blockchain. Algorithm 1 (Secure eHealth Record Sharing) Input: Hospital or Agency Identity (H id ), Patient Identity (Pid ) Output: Valid Plain Health Record (HR)

126

S. Venkatesan et al.

Patient 1: Fetch the H id ’s public key (H pub ) from the blockchain 2: Compute Rk = rekey(H pub , Ppri ) 3: Share Rk with proxy/third party Third party/Patient 4: Fetch C from the IPFS/cloud by providing the patient identity or index 5: Re-encrypt C’ = reenc(C, Rk ) 6: Share C’ with Hospital/Agency Hospital/Agency 7: Decrypt HR = Dec(C’, H pri ) 8: Fetch the Pid ’s meta-data (H HR ) from the blockchain 9: if (h(HR)== H HR ) 10: return HR 11: else 12: return Invalid Secure Sharing: The process of a patient sharing the health record with a hospital or agency is given in algorithm 1. The patient wishes to share the record with any hospital that has to fetch the respective hospital public key H pub from the blockchain and generate the proxy re-encryption key RK = rekey(PPri , H Pub ) using his/her private key Ppri . The proxy (third party) re-encrypts (reenc) the encrypted record C using re-encryption key Rk and provides C’ to the hospital. The hospital uses its private key H pri and decrypts the re-encrypted version of the record C’ to get the plain record HR. Later, the integrity of the record will be verified using the meta-data available in the blockchain. If it is valid, then hospital uses the record; otherwise reject and report. Patient can do the re-encryption if the required infrastructure is available.

5.5.2 Process Flow The process of registration of a patient/hospital, data, and meta-data hosting, and sharing of the proposed eHealth record management system is shown in Fig. 5.5 with registration, record generation and hosting, and sharing phase. The system process flow is as follows: Step 1: A patient or hospital interested to take part in the proposed system has to register on the blockchain application by providing the secret passphrase. The application that runs on the user system provides the unique key pair

5 Secure and Decentralized Management of Health Records

127

Fig. 5.5 Process flow of the proposed eHealth record management system

(Bpub ,Bpri ) and user account address computed using the public key. The account address that called as the doctor/hospital/patient’s pseudo-identity is the last 20 characters of the SHA hash function output (h(Bpub )) similar to Ethereum. The key pairs are derived using the elliptic curve cryptography, and it is used for the transaction and record consent signature. To ensure that each patient creates only one account on the blockchain, the blockchain key pair can be derived from the biometric of the user that is the scalar private key from the biometric fingerprint. The biometric devices at the hospitals could also be attacked by parties and would need a high level of protection. Later, the user-generated record encryption public key (Ppub ) is stored in the blockchain through Key transaction. Step 2: On the visit of a patient, a hospital/doctor has to access the patient public key and previous record file identity from the blockchain and encrypt the prepared health record. In addition, the meta-data (hash) of the plain record should be computed and the patient’s consent for the meta-data needs to be

128

Step 3:

Step 4:

Step 5: Step 6:

S. Venkatesan et al.

taken. Then, the encrypted record has to be hosted on the cloud or IPFS, and meta-data along with other parameters will be broadcasted to the blockchain network through a Record transaction. The miners validate and commit to the block if the transaction is valid. Patients who wish to share the record with the hospital/agency have to access their public key from the blockchain and generate the re-encryption key (Rk ) through a rekey function, which takes the private key of the patient and the public key of the hospital/agency as input. The patient will share the Rk with a third party (proxy) for re-encryption of the encrypted record. The patient himself/herself can do the proxy reencryption provided enough resources. Also, update the access permission in the blockchain through the GrantRevoke transaction. The grant and revoke permission can effectively be used for future auditing. Using the respective re-encryption key, proxy, or patient can re-encrypt the permitted encrypted record and send it to the respective hospital/agency. Hospital decrypts, verifies the integrity of record by accessing the meta-data from the blockchain, and uses it for further analysis.

5.6 Security Analysis The proposed system addresses all security issues discussed in the problem statement, ensure the security and privacy of the patient’s eHealth record, and overcome the meta-data and record conflict. Confidentiality: The eHealth records are encrypted using the respective patient’s public key (Ppub ) and hosted at the cloud or IPFS. Since the private key (Ppri ) is known only to the patient that is the owner of the record, only authorized users can access the readable record. The user authorized by a respective patient through a re-encryption key/grant transaction can access the readable record. Availability: The eHealth records are encrypted and stored in IPFS or multi-cloud storage. In the case of one site failure, other sites can provide the data. Hence, the failure of one node cannot make the record unavailable. Integrity: Whenever doctors/patients/other agencies request a record from the cloud or IPFS, they will be provided along with previous record meta-data. For example, let us assume the records HR1 , HR2 ,…HRn are available for a patient. Along with records, meta-data H HR:1 , H HR:2 , H HR:3 , … H HR:n are also available. The meta-data H HR:2 of the second record is computed as h(H HR:1 ||h(HR2 )) using the SHA hash function. Similarly, the next hashes H HR:3 , H HR:4 , and so on are computed. While accessing the record, for example, HR10 , the health record HR10 and H HR:9 will be provided to the user. The user will fetch H HR:10 from the public blockchain and verify the integrity of the record by mapping the H HR:10 and h(H HR:9 ||h(R10 )). If mapping is successful, then data is not modified and accepted; otherwise reject and report to the patient. Hence, integrity of the record is achieved.

5 Secure and Decentralized Management of Health Records

129

Logging and Auditing: Since the records are encrypted and stored, without patient consent and proxy re-encryption, records cannot be accessed and used by any of the subscribers. Patient grant access to the health record for any of the hospital is stored in the immutable blockchain. The auditing can be done using the information available in the blockchain. However, patient grant permission to agencies without posting on the blockchain cannot be identified and controlled. There are insider attacks possible since the data and meta-data are in different networks or environments. The possible attack and the solution by the proposed system are as follows. (a) Unauthorized creation and posting of eHealth record: There is a possibility that malicious intended hospital or agency knowing the patient identity and public key can host the poison data on the cloud or IPFS and link the hash in blockchain. This creates uncertainty on the patient’s health record. To overcome this attack, the proposed system mandates hospital to create blockchain Record transaction with patient signature (consent of the patient) on the health record hash using Bpri . The Record transaction validation includes the patient consent validation. While accessing and using the record, in addition to record integrity verification, the client signature also verified to confirm the patient consent on the record. (b) Unauthorized modification of the encrypted record stored at cloud/IPFS by faulty nodes: The malicious intent user or compromised third party may modify the encrypted records or meta-data. This will lead to hash conflict, poisoned records, etc. Since the proposed system uses cloud/IPFS which has distributed storage, modification of record will not harm because other non-faulty nodes will provide the true copy of records. It is hard for the attacker to compromise all storage nodes to achieve the desired attack. However, it is not suggestive to store the health record in all IPFS nodes since the eHealth records are too big in size. (c) The malicious intended hospital may host the meta-data in blockchain but not in IPFS/cloud and vice versa: The solution to tolerate this fault is MPT node’s additional attribute HU. Problem I Malicious intended hospital hosts a record on IPFS/cloud but not the meta-data on blockchain. Solution In this case, the problematic record is not part of the patient’s record set. IPFS: To access the record of a patient, the hash available in the block MPT’s optional attribute (O) will be used as an index. Thus, record can be accessed; however, the problematic record will not be usable. Cloud: The patient’s Pid is used to access the latest record and the record hash is mapped with the meta-data (hash) available in blockchain. The hash conflict will occur because of a mismatch between data in storage and meta-data; thus, records cannot be used. However, it is possible to access the preceding record from the cloud using the same identity and can be verified with blockchain meta-data (hash). If again conflict occurs, then next preceding record and so on. At one stage, hashes (record hash and blockchain hash) will be matching and

130

S. Venkatesan et al.

the respective record and preceding records can be used. Hence, the malicious node behavior will not affect the complete record access and use. Problem II Malicious intended hospital hosts meta-data into blockchain but not the record on IPFS or cloud. Solution In this case, the hash available at the latest block and hash of the latest record in the cloud will not match. To tolerate the problem, fetch the preceding hash by directly accessing the block, which has the previous hash update using the HU attribute, and validate the records. If not matches, continue till it matches. Similarly for the IPFS, if the record not found for the respective hash index then try with the preceding hash index. The above solutions consume more time for record access if malicious behavior occurs. In case blockchain and IPFS validating nodes verify each other about the new update, an attack will be identified immediately and prevented. However, this is computationally heavy and infeasible because miner as well as non-miner has to verify with IPFS and validate the transaction. Similarly, IPFS nodes have to perform the task. Hence, in the proposed system only the above two solutions are considered. (d) Hospital posts incorrect record or not posts the record: Patient can verify the data availability through blockchain and IPFS/cloud. However, incorrect data cannot be identified until the patient has medical knowledge or it is cross-verified by multiple hospitals. Single account and access of record in an unresponsive state: Ensuring a single identity for a patient is a complex problem in health care, since a patient may register multiple times within the same or different hospitals under different accounts. This causes fragmentation of patient data and affects data sharing and effective use. To bring a single account, the account address or identity of the patient can be derived from his/her biometric fingerprint. Even though the patient knowingly or unknowingly tries to create multiple accounts, in blockchain, it will be stored under a single account. In the proposed system, the key pair is derived using the elliptic curve cryptosystem, where the private key (Bpri ) is a random scalar value and the public key (Bpub ) is the point multiplication of the private key and elliptic curve base point. The random scalar value can be derived using the patient’s biometric; thus getting a single account address or identity for the patient. The key escrow technique will be used to solve the problem of accessing the record when the patient is in an unresponsive state. Statistical Data Privacy: It is very important to maintain the disease/patients statistics and making the information available to the public or governing bodies without violating the privacy of the patients. The proposed system never discloses the actual identity of the patient similar to Reen et al. model (2019); however, the malicious can map the statistics information in the hospital’s Record transaction and the visit of the known patient to conclude or predict the health report. Also, specialized hospitals increase the chance of prediction. This can be mitigated by posting transactions continuously and in random order. In case, the hospital broadcasts multiple Record

5 Secure and Decentralized Management of Health Records

131

transactions continuously and randomly then it creates non-determinism and thus mitigates the attack against the patient’s privacy.

5.7 Performance Analysis 5.7.1 Experimental Setup The proposed system is implemented by modifying the goethereum tool. The goethereum (Go-ethereum) is the implementation of Ethereum protocol (Wood, 2014) using the Go language (Golang). The results are from the private network full node device with the configuration of 4 core 3.30 GHz processor, 8 GB RAM with Ubuntu 16.04 LTS, and geth version 1.8.2-stable-b8b9f7f4. For the overhead analysis, the platform used for local storage is MongoDB, the cloud is Amazon Cloud using MongoDB, and IPFS is INFURA. To compare the smart contract and core world state MPT-based storage access, a private full node device with the configuration of 4 core 3.50 GHz processor, 12 GB RAM with Ubuntu 16.04 LTS and geth 1.9.11-stable version is used.

5.7.2 Results and Discussion The implementation scenario is the hospital gives the hash of the health record to the patient, and then the patient creates a transaction by including from and to as his/her address (from: eth.accounts[0] & to: eth.accounts[0]) and health record hash concatenated with the previous record hash (H p ). Then broadcast it to the network for inclusion in the block. The successfully validated transaction will be given transaction confirmation as shown in Fig. 5.6 and then committed into the block during mining. In the implementation, the transaction is prepared and submitted by the patient; thus

Fig. 5.6 Output of the modified sendTransaction in goethereum

132

S. Venkatesan et al.

Fig. 5.7 Retrieval of health record hash and public key of a patient

Latency (in milliseconds)

by default, the hash of the record along with other parameters in the transaction is signed by the patient using his/her Bpri . Figure 5.7 shows the retrieval of latest health record hash (meta-data) and the public key of a user from the blockchain by providing the patient’s Ethereum address. These data can be accessed by any of the nodes in the network. Figure 5.8 shows the computational time (latency) consumption of goethereum node for modified sendTransaction validation and data access on the presence of a different number of participating nodes. The computational time plot HRhAc is for accessing the health record hash (meta-data) of a patient, and RTr is for the validation of modified sendTransaction. The experimental result shows that the transaction validation time is greater than the data access time. This is because of multiple validations such as signature and account existence. Also, the result in Fig. 5.8 shows that the access to meta-data and validation of the transaction are not heavy and time-consuming. Figure 5.9 shows the latency difference of smart contract (SCAcc) and core world state MPT storage (MPTAcc)-based data access. The data access includes two steps in the case of core world state MPT storage and three steps in the case of smart contract storage. In the world state MPT storage-based data access, as the first step, the trie is traversed and the patient node is located using the patient pseudo-identity/Ethereum address and as the second step data is accessed. In smart contract storage-based data 18 16 14 12 10 8 6 4 2 0

RTr Hrhacc

40

80

100

200

500

No. of Nodes Fig. 5.8 Computational latency for the transaction validation and data access

5 Secure and Decentralized Management of Health Records

133

Latency (in milli seconds)

12 10 8 6

SCAcc

4

MPTAcc

2 0 20

40

80

100

No. of Nodes Fig. 5.9 Computational latency for the world state MPT and smart contract storage data access

access, the first step is to traverse the trie and locate the application administrator node, the second step is to traverse and locate the application user (patient) node in the smart contract storage, and the third step is accessing the data. Hence, the smart contract storage-based data access latency is more when compared to the world state MPT storage-based data access. The existing systems use the smart contract-based storage, and that needs more latency for data access as shown in Fig. 5.9. Hence, the proposed eHealth record management system uses the core world state MPT storage instead of smart contract-based storage.

5.7.3 Overhead Analysis Table 5.1 shows the parameters and values considered for the overhead evaluation of the proposed eHealth record management system, which uses the blockchain technology. The blockchain considered for the analysis is the Ethereum public cryptocurrency blockchain since the proposed system uses the Proof of Authority (PoA)-based Ethereum implementation. There are four different eHealth record management systems considered for comparison: A: the eHealth record is kept at the hospital in plain format, B: the eHealth records are encrypted and kept in the hospital, C: the eHealth records are encrypted and placed in the hospital as well as in cloud, and D: the eHealth records encrypted and placed in the hospital, cloud or IPFS and meta-data on the blockchain. Table 5.2 shows the space, access time, and computational time requirement of all systems. The given computational time for eHealth record encryption, and hashing is computed through the OpenSSL since these are not part of the blockchain activities. Table 5.2 shows that the systems C and D are computationally heavy when

134

S. Venkatesan et al.

Table 5.1 Parameters for evaluation of the proposed model Parameters

Value

Number of patients

500

Total record size

2.5 GB

Avg. patient record size (only text)

50 KB

Encryption algorithm (RSA is considered in place of ECC since no significance in the systems comparison)

RSA

Blockchain size (public Ethereum size (Stat, 2018), it extends)

667.10 GB

Block count (public Ethereum (Stat, 2018), it extends)

6,542,612

Storage size of plain/encrypted records

2.5 GB

Block size considered with respect to Ethereum

33 KB

Avg. hash time of medical record

HT

Avg. record encryption time

ET

Computation, validation and access time

In milli seconds

compared with the systems A and B; however, the systems A and B are not considered for overhead analysis since it lags in confidentiality and integrity while sharing the records. Table 5.3 shows the overhead of the proposed system D over system C for storage space, access time, and record, and block sharing cost. The proposed blockchainbased system (D) needs more overhead with respect to space, data sharing, and IPFS data access. (i)

Storage space: It has storage space overhead of approximately 7 TB; however, it is not from the beginning of the blockchain application. It increased gradually from 33 KB to 7 TB in ~ 10 years, and it will further go high. In connection with Moore’s law [Moore 1965], the year it goes, the cost of memory may reduce. Hence, it will not affect the cost at a high level. Also, the proposed system provides faster access to meta-data since the copy of the blockchain is stored locally in full nodes. (ii) Access time: It has additional overhead only in IPFS access; however, if the records are accessed by different nodes then records will be in nearby storage and will achieve the quick access of record. Also, the efficient cloud data access techniques (Namasudra et al. 2020a; Namasudra et al. 2020b; Namasudra et al. 2017a; b) will further reduce the access time. (iii) Sharing cost: The overhead is only ~ 3mbps considering each block size is 33 KB and 10 nodes in the network sharing it. This overhead will not reduce the functional capability of the system. Also in today’s network, 3mbps bandwidth is not an overhead. The Proof of Authority-based block mining and validation is also the additional overhead. However, this will not delay the record and meta-data access. Even though proposed system has significant overhead with respect to storage, it achieves reliable health record sharing, public verifiability, record integrity, and fault tolerance. Also,

HT

NA

6.0

6.0

6.0

Model

A

B

C

D

11.0

11.0

11.0

NA

ET

2.2

NA

NA

NA

Blockchain data access time

16.5

NA

NA

NA

Blockchain transaction validation time

Table 5.2 Storage and computational analysis

46.5

46.5

46.5

Time for Record access from the local database

667.10 GB * 10 nodes 46.5 = 6670.10 GB ~ 7 TB

NA

NA

NA

Blockchain Size (Storage cost)

431.4

NA

NA

NA

Time for Record access from the IPFS

226.7

226.7

NA

NA

Time for Record access from the cloud

5 Secure and Decentralized Management of Health Records 135

136

S. Venkatesan et al.

Table 5.3 Overhead analysis Resource

C

D

Overhead

Storage space

2.5 GB

~7 TB

~7 TB

Cloud

226.7

226.7

0

IPFS

NA

431.4

204.7

Local storage

46.5

46.5

0

20Gbps

~3mbps + 20Gbps

~3mbps

Access time

Record and block sharing cost

blockchain of the proposed system maintains the disease statistics without violating the privacy of any patient.

5.7.4 Limitations The proposed model has the following limitations with respect to rural patient technical knowledge and insider (hospital administrator) malicious behavior. (i)

Patient ignorance and pressure may be used to access the record in an unauthorized manner. (ii) The patient may not have enough resources or technical knowledge to do reencryption or create transactions even though the interface will be provided. (iii) Hospital administration may keep the copy of the plain eHealth record without the knowledge of the patient and access it whenever required without patient consent. (iv) Hospital administrators may inject incorrect data. The limitations (i) and (ii) can be mitigated through awareness. The limitation (iii) is not going to harm the patient because the respective hospital already knows the patient details. However, if the respective storage server is compromised or the hospital shares the data with others then patient privacy is in question. Limitation (iv) is not possible to mitigate without multiple verifications.

5.8 Conclusions and Future Works This chapter proposed the eHealth record management system using blockchain to secure and efficiently share the healthcare data. The health records are encrypted and stored in the cloud/IPFS to ensure availability and confidentiality. The meta-data of the health record is stored on the blockchain to ensure the integrity and public verifiability. The proposed system achieves confidentiality, privacy, availability, and fault tolerance in the presence of inside and outside attackers. Also, it provides services like

5 Secure and Decentralized Management of Health Records

137

statistics generation, and single account for patients. The experimental results, security, and overheads analysis prove the applicability of the proposed eHealth record management system in eHealth care. The future work of this paper is to achieve the granular access control of the patient’s record. Key Terms and Definitions Blockchain: It is a distributed ledger consisting of blocks, which keeps on growing and cryptographically linked to mitigating the malicious alterations. Also, it spreads over many users of the network to ensure decentralization and availability. Cloud: It is an on-demand facility provided by third parties especially for data storage and computation without direct active management by the client. The encrypted eHealth records of the proposed record management system are stored in the cloud. Inter Planetary File System (IPFS): It is a peer-to-peer network for storing and sharing data in a distributed file system using the Distributed Hash Table (DHT). The content can be hosted on the IPFS by users using the index (hash of the data); also, it can be stored in multiple nodes. Any user in the network can access a file using its content address by approaching any peer in the network that can find and request the content from a peer that has it. Cryptographic Hash: It is a function that takes arbitrary size input and produces a fixed-size output. A small change in a message will change the hash output so extensively that the new hash value appears uncorrelated with the old hash value. The properties of the hash function are Pre-Image Resistance, Second Pre-Image Resistance, and Collision Resistance. This is used for ensuring the eHealth record integrity.

References Azaria, A., Ekblaw, A., Vieira, T., & Lippman, A. (2016). Medrec: Using blockchain for medical data access and permission management. 2nd International Conference on Open and Big Data (OBD), pp. 25–30. Conceicao, F.A., Correa da Silva, F.S., Ocha, V., Locoro, L., & Bargui, J.M.M. (2018). Eletronic health records using blockchain technology. http://www.sbrc2018.ufscar.br/wp-content/uploads/ 2018/04/07-181717-1.pdf. Last accessed on 16 June 2020. Dubovitskaya, A., Xu, Z., Ryu, S., Schumacher, M., & Wang, F. (2017). Secure and trustable electronic medical records sharing using blockchain. https://arxiv.org/pdf/1709.06528.pdf. Goldwater, J.C. (2016). The use of a blockchain to foster the development of patient—reported outcome measures. White paper, https://www.healthit.gov/sites/default/files/6-42-use_of_blockc hain_to_develop_proms.pdf. Last accessed 14 February 2018. Hasan, R., Winslett, M., & Sion, R. (2007). Requirements of secure storage systems for healthcare records. Workshop on Secure Data Management. pp. 174–180. Henry, J.W., Pylypchuk, Y., Searcy, T., & Patel, V. (2016). Adoption of electronic health record systems among U.S. non-federal acute care hospitals: 2008–2015.ONC Data Brief 35 https://dashboard.healthit.gov/evaluations/data-briefs/non-federal-acute-care-hospitalehr-adoption-2008–2015.php. Last accessed 17 February 2018.

138

S. Venkatesan et al.

HIPAA, The Health Insurance Portability and Accountability Act of 1996 (HIPAA), Online at https://aspe.hhs.gov/report/health-insurance-portability-and-accountability-act-1996. Last accessed 14 February 2018. HL7. (2018). HL7 Fast Healthcare Interoperability Resources (FHIR). https://www.hl7.org/fhir/. Khatoo, A. (2020), A Blockchain-Based Smart Contract System for Healthcare Management, Electronics, MDPI, 9(1). Kuo, T., Kim, H., & Ohno-Machado, L. (2017). Blockchain distributed ledger technologies for biomedical and health care applications. Journal of the American Medical Informatics Association, 24(6), 1211–1220. Lamport, L., Shostak, R., & Pease, M. (1982). The byzantine generals problem. ACM Transactions on Programming Languages and Systems, 4(3), 382–401. Merkle tree. https://en.wikipedia.org/wiki/Merkle_tree; accessed 10-March-2019. Moore, G.E. (1965). Cramming more components onto integrated circuits. Electronics, 38(8). Morrison, D. R. (1968). PATRICIA—Practical algorithm to retrieve information coded in alphanumeric. Journal of the ACM, 15(4), 514–534. Namasudra, S., & Roy, P. (2017). Time saving protocol for data accessing in cloud computing. IET Communications, 11(10), 1558–1565. Namasudra, S., Roy, P., Vijayakumar, P., Audithan, S., & Balamurugan, B. (2017). Time efficient secure DNA based access control model for cloud computing environment, Future Generation Computer Systems, 73, pp. 90–105. Namasudra, S., Deka, G.C., Johri, P., Hosseinpour, M., & Gandomi, A.H. (2020). The revolution of blockchain: State-of-the-art and research challenges, Archives of Computational Methods in Engineering. Namasudra, S., Chakraborty, R., Majumder, A., & Moparthi, N.R. (2020a). Securing multimedia by using DNA based encryption in the cloud computing environment, ACM Transactions on Multimedia Computing, Communications, and Applications, (in press). Namasudra, S., Chakraborty, R., Kadry, S., Manogaran, G., & Rawal, B.S. (2020b). FAST: Fast accessing scheme for data transmission in cloud computing, Peer-to-Peer Networking and Applications, (in press). NeHA, National eHealth Authority (NeHA), https://www.mygov.in/sites/default/files/master_ image/NeHA Concept Note Eng.pdf . Last accessed 14 February 2018. Peterson, K., Deeduvanu, R., Kanjamala, P., & Boles, K. (2016). A blockchain-based approach to health information exchange networks, ONC/NIST Use of Blockchain for Healthcare and Research Workshop. Gaithersburg, Maryland, United States: ONC/NIST. Qin, Z., Xiong, H., Wu, S., & Batamuliza, J. (2016). A survey of proxy re-encryption for secure data sharing in cloud computing. IEEE Transactions on Services Computing. Go-Ethereum, https:// github.com/ethereum/go-ethereum. Reen, G.S., Mohandas, M. & Venkatesan,S. (2019). Decentralized patient centric e-health record management systemusing blockchain and IPFS, In Proceedings of International Conference on Information and Communication Technology (CICT), IEEE, Prayagraj, India, pp. 1–7. Shrier, A.A., Chang, A., Diakun-thibault, N., Forni, L., Landa, F., Mayo, J., & Riezen, R. (2016). BlockChain and health IT: Algorithms, privacy, and data, White paper.https://www.healthit. gov/sites/default/files/1-78-blockchainandhealthitalgorithmsprivacydata_whitepaper.pdf. Last accessed 14 February 2018. Stat, Cryptocurrency statistics. https://bitinfocharts.com/. Last accessed on 18 October 2018. Theodouli, A., Arakliotis, S., Moschou, K., Votis, K., & Tzovaras, D. (2018). On the design of a Blockchain-based system to facilitate healthcare data sharing, 17th IEEE International Conference on Trust, Security and Privacy in Computing and Communications/12th IEEE International Conference on Big Data Science and Engineering (TrustCom/BigDataSE). Tierion. (2016). Blockchain healthcare 2016 report—promise & pitfalls. [online] https://tierion. com/blog/blockchain-healthcare-2016-report. Last accessed 14 February 2018. Vazirani, A.A., O’Donoghue, O., Brindley, D., & Meinert, E. (2020). Blockchain vehicles for efficient Medical Record management, Digital Medicine, Nature partner journals, Article No. 1.

5 Secure and Decentralized Management of Health Records

139

Vian, K., Voto, A., & Haynes- Sanstead, K. (2016). A BlockChain profile for medicaid applicants and recipient. Whitepaper, https://www.healthit.gov/sites/default/files/14-38 blockchain_medicaid_solution.8.8.15.pdf . Last accessed 14 February 2018. Wood, G. (2014). ETHEREUM: A secure decentralized transaction ledger. Yellow paper. Golang The Go Programming Language. https://golang.org/. Xia, Q., Sifah, E.B., Smahi, A., Amofa, S., & Zhang, X. (2017a). BBDS: Blockchain-based data sharing for electronic medical records in cloud environments. Information, 8(2), p. 44. Xia, Q., Sifah, E. B., Asamoah, K. O., Gao, J., Du, X., & Guizani, M. (2017b). MeDShare: Trustless medical data sharing among cloud service providers via blockchain. IEEE Access, 5, 14757– 14767. Yip, K. (2016). BlockChain and alternative payment models. White paper, https://www.healthit.gov/ sites/default/files/15-54-kyip_blockchainapms_080816.pdf. Last accessed 14 February 2018.

Subramanian Venkatesan is Associate Professor in the Department of Information Technology at Indian Institute of Information Technology, Allahabad, Prayagraj, India. He works in the area of cybersecurity and blockchain. He is Member of the Network Security and Cryptography Lab, Indian Institute of Information Technology, Allahabad, Prayagraj, India. Shubham Sahai is a Ph.D. scholar in Cyber Security Center, Indian Institute of Technology, Kanpur, and currently working with Prof. Sandeep K. Shukla and Prof. Pramod Subramanyan. His research interest lies around blockchain, formal methods, and applied cryptography. He has a keen interest in designing systems that guarantee trust and privacy among users. His peripheral interest in cryptography revolves around zero-knowledge proofs, oblivious RAMs, and homomorphic encryption, and he believes that these constructions will play a pivotal role in the development of a secure, trustworthy, and privacy-preserving digital world. Sandeep Kumar Shukla is Professor in the Department of Computer Science and Engineering, Indian Institute of Technology, Kanpur, India. He is an Associate Editor of ACM Transactions on Cyber-Physical Systems. He is an IEEE fellow and an ACM Distinguished Scientist, and served as an IEEE Computer Society Distinguished Visitor from 2008 to 2012 and as an ACM Distinguished Speaker from 2007 to 2014. He was previously the Poonam and Prabhu Goel Chair Professor in the Deparment of Computer Science and Engineering, Indian Institute of Technology, Kanpur, India, Editor in Chief of ACM Transactions on Embedded Systems from 2013 to 2020, Associate Editor of IEEE Transactions on Computers, IEEE Transactions on Industrial Informatics, IEEE Design & Test, IEEE Embedded Systems Letters, and various other journals. He was Member of the faculty at the Virginia Polytechnic Institute, Arlington, Virginia, between 2002 and 2015, and has also been a visiting scholar at INRIA, France, and the University of Kaiserslautern, Germany. In 2014, he was named a fellow of the Institute of Electrical and Electronics Engineers (IEEE) for his contributions to applied probabilistic model checking for system design. He has authored several books on systems and has edited and co-authored numerous books with Springer. Jaya Singh is a Ph.D. student in Network Security and Cryptography Laboratory, Department of Information Technology, Indian Institute of Information Technology, Allahabad, Prayagraj, India. Her research interest includes blockchain applications and lightweight authentication techniques.

Chapter 6

IoT-Based Healthcare Monitoring Using Blockchain Monireh Vahdati, Kamran Gholizadeh HamlAbadi, and Ali Mohammad Saghiri

Abstract The Internet of Things (IoT) is used to improve traditional healthcare systems in different aspects, including monitoring patients’ behaviors. Information gathered by sensors in the IoT plays an essential role in healthcare systems. Because of privacy and security issues, the data must be protected against unauthorized changes. On the other hand, Blockchain technology provides a wide range of mechanisms to protect data against changes. Therefore, IoT-based healthcare monitoring using Blockchain constitutes an exciting technological innovation, which may help mitigate security and privacy concerns related to the gathering of information during patient monitoring. In this chapter, the potential applications of IoT– Blockchain systems are studied, and then monitoring mechanisms in healthcare systems are analyzed. To this end, a novel architecture based on recently reported solutions is proposed. The proposed architecture, with the aid of computational power obtained from the IoT, Blockchain and artificial intelligence, can be used in a wide range of solutions aimed at managing the coronavirus disease 2019 (COVID-19). In order to show the potential of the proposed architecture, three case studies are presented. At the end of this chapter, other applications of the proposed architecture are summarized, which can be used in pandemic situations. Keywords Internet of Things · Blockchain technology · Artificial intelligence · Healthcare systems · COVID-19

M. Vahdati (B) · K. Gholizadeh HamlAbadi Young Researchers and Elite Club, Qazvin Branch, Islamic Azad University, Qazvin, Iran e-mail: [email protected] K. Gholizadeh HamlAbadi e-mail: [email protected] Faculty of Computer and Information Technology Engineering, Qazvin Branch, Islamic Azad University, Qazvin, Iran A. M. Saghiri Computer Engineering and Information Technology Department, Amirkabir University of Technology (Tehran Polytechnic), 424 Hafez Ave, Tehran, Iran e-mail: [email protected] © The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2021 S. Namasudra and G. C. Deka (eds.), Applications of Blockchain in Healthcare, Studies in Big Data 83, https://doi.org/10.1007/978-981-15-9547-9_6

141

142

M. Vahdati et al.

6.1 Introduction Recently, healthcare systems have been revolutionized by technologies in different fields, linked to the IoT. Monitoring is one field of healthcare that invests in the IoT technologies. IoT constitutes a powerful ecosystem, incorporating sensors, actuators and computational resources in order to organize useful monitoring systems (Saddik et al. 2020; Saghiri et al. 2020). In the next three paragraphs, problems associated with the organization of monitoring systems based on IoT are summarized. Remote monitoring is very common these days for the treatment of patients, and a key concern with such systems is maintaining security and privacy of vast amounts of data (Ajerla et al. 2019; Griggs et al. 2018; Mohammed et al. 2014), which could potentially be transferred. It is therefore crucial to guard against cyberattacks, which can cause major problems. These problems can lead to delays in patient treatment. Blockchain can be used to solve these problems (Gupta et al. 2020). However, Blockchain technology requires high bandwidth and extra computational power that are not appropriate for devices with resource constraints. In addition, the combination of Blockchain and IoT-based systems has many drawbacks, like low scalability and long latency for network transactions. Other challenges have also been identified in (Dwivedi et al. 2019b). An IoT–Blockchain combination may constitute a strong approach which can considerably smooth the way for new business models and distributed applications. According to Jamil et al. (2020), data communication is one of the major problems encountered by healthcare providers. Given the huge amount of data involved, it is almost impossible to manage in the local domain, and it has been suggested that the public domain should be used for this purpose. One problem, which is still a barrier for both patients and healers, is locating data stored in different places. Therefore, a unified and holistic healthcare infrastructure is necessary to enable interoperability and secure sharing of medical data across diverse healthcare areas, to increase collaborative healthcare services and research. Moreover, other associated issues (e.g., record sharing, data privacy, security, identity, scalability, data integrity, and patient enrollment) also present challenges for patients in healthcare ecosystems. Blockchain technology can overcome such problems. It should be noted, few systems provide the necessary data integrity and privacy in the clinical healthcare system. In Jamil et al. (2020), a patient monitoring system based on Blockchain is suggested. This system, with the introduction of Blockchain technology, not only significantly enhances the entire manufacturing process but also considers security issues. Nowadays, sensors are commonly embedded in devices and vehicles which are connected to the Internet. To simplify the treatment of patients through Remote Patient-Monitoring (RPM) technology, healthcare experts now use IoT. In recent years, increasing use of wearable devices and IoT has improved the quality of patient care outside formal clinical settings. However, there are lots of privacy and security problems, including concerns about data transfer and transactions, which may result in delays in treatment progresses. Use of Blockchain technology has been reported for managing and safeguarding data (Dwivedi et al. 2019b).

6 IoT-Based Healthcare Monitoring Using Blockchain

143

In this chapter, an architecture based on Saghiri et al. (2018) for healthcare monitoring is proposed. In addition, some solutions given in ( Abujamra and Randall, 2019; Jamil et al. 2020; Bublitz et al. 2019; HamlAbadi et al. 2017; Vahdati et al. 2018; Saghiri et al. 2020) are deployed in this architecture. This architecture solves some problems associated with security and privacy in IoT, using Blockchain technology. Because of the distributed and dynamic nature of IoT systems based on Blockchain, a wide range of management problems should be solved using smart algorithms. Therefore, the cognitive systems framework has been embedded in the proposed architecture to better organize the management processes in order to solve problems in a self-organized manner. Note that all existing algorithms suffer from complex organization of management algorithms. In other words, the proposed architecture solves the challenges of complexity in designing management algorithms using a cognitive systems approach. According to Saghiri (2020b) and Wang et al. (2020), cognitive systems are used to decrease the complexity of management algorithms in a wide range of applications. In order to study potential applications of the proposed architecture, some case studies involving the fight against COVID-19 are studied in this chapter. The structure of this chapter is as follows: Sect. 6.2 is dedicated to the literature review. Section 6.3 focuses on background studies. In Sect. 6.4, an architecture is proposed for healthcare monitoring. In Sect. 6.5, three case studies are suggested. Discussions and potential applications are given in Sect. 6.6. Section 6.7 is dedicated to performance analysis. Conclusions and future work are given in Sect. 6.8.

6.2 Literature Review Blockchain technologies in IoT have been considered in a myriad of papers. In this part, some of the primary reasons for investigation of the use of Blockchain and the IoT in healthcare monitoring services are studied (Mettler 2016; Panarello et al. 2018). Although Blockchain technologies facilitate secure administration and enable users to find data from a vast array of healthcare information (Dwivedi et al. 2019b), these technologies are still computationally costly and require a high transfer speed and extra computational power, which is not appropriate for most resourceconstrained IoT devices in smart cites. In Conoscenti et al. (2016), the use of a Blockchain in IoT is reported. The authors identify many issues associated with the trustworthiness, obscurity and flexibility of Blockchain frameworks. They find that Blockchain frameworks are secure but not appropriate for the IoT because of adaptability issues. The author of Kshetri (2017) has considered how a Blockchain could address some common IoT challenges. Furthermore, IoT and Blockchain (along with their associated problems) have been studied by Reyna et al. (2018). In addition, in Huh et al. (2017), novel use of a Blockchain has been demonstrated, featuring the Ethereum platform. It should be noted that the security of medical records is critical point when discussing health

144

M. Vahdati et al.

information. This feature is supported by Blockchain technology. Table 6.1 provides a detailed comparison of existing approaches in healthcare systems.

6.3 Background Studies 6.3.1 Overview of IoT The idea of connecting everything, anywhere, at any time, loosely describes the concept of IoT. The notion of the IoT is that it not only provides connectivity but also assists interaction between the devices to be connected. The speed with which new devices can be connected to an integrated system is very important, but it also has several serious dangers in terms of security and privacy (Gupta et al. 2020). In IoT, cloud computing leads to important features such as efficiency, time saving, cost effectiveness, pay-per-use, flexibility and scalability (Hassanalieragh et al. 2015; Namasudra and Roy 2017). Blockchain has an important role in the next generation of IoT-based applications (Dorri et al. 2017). In addition, in order to improve the security of data in IoT-based devices, some solutions are given in (Namasudra et al. 2020a, c; Namasudra 2018, 2019; Devi et al. 2020; Namasudra et al. 2017, 2018; Namasudra and Deka 2018). Wearable devices in healthcare systems are a kind of smart electronic devices, which can be worn as an accessory or even embedded in clothes. These kinds of devices are very simple, user friendly, and connection to them can be done through wireless communication. Important information which can be provided by these devices includes blood pressure, blood glucose levels and breathing patterns (Dwivedi et al. 2019b). Wearable accessories worn by patients can transmit a myriad of data to a smartphone. These data play a crucial role in preventive care and critical care, as reported in Hang et al. (2019). This technology also permits doctors to treat more patients. RPM facilitates observation and care of patients beyond the contractual clinical setting . A key advantage is that IoT promotes patient comfort. Patients can keep in touch with healthcare practitioners as required. It likewise decreases clinical expenses and improves the quality of care. Medical services suppliers are now investigating ways of extending the scope of RPM so that it can serve the majority of patients. The primary segment of RPM framework could be a uniquely planned checking device to monitor and transmit key data. Wearable devices and the IoT play a significant role in RPM and are currently being promoted as part of the creation of smart cities. Wearable devices continuously gather health information and can send it to emergency clinics or clinical organizations as part of their health interventions, enabling them to monitor disease results and the progress of treatment (Dwivedi et al. 2019b). Recently, another related concept called the “cognitive IoT” (Foteinos et al. 2013; Saghiri et al. 2018) has been described. This targets coordination of subjective advances into IoT-based frameworks in order to guarantee smart administration

A framework based on AI, the IoT and Blockchains is used to support investigation and improvement of pan-Canadian monitoring and observation activities that have an environmental impact on health

Represents a Blockchain-based medical Support patients with a comprehensive, Does not evaluate the suggested platform platform to secure electronic medical unchanging log and simple access to their across a large-scale network record management medical data over diverse departments within the clinic

Design of fog computing, Blockchains and an IoT-based continuous glucose-monitoring system for crowdsourcing mHealth

Represents a secure Blockchain architecture for healthcare monitoring applications

Bublitz et al. (2019)

Hang et al. (2019)

Fernández-Caramés and Fraga-Lamas (2018)

Attia et al. (2019)

No implementation exists

Provides a secure remote-monitoring IoT system; secured IoT architecture can be implemented in the healthcare application domain

Helps with the control of diseases; provides a transparent and trustworthy blood-sugar data source

(continued)

Needs to implement more functionality to get a complete IoT–Blockchain framework dedicated to health monitoring

Does not evaluate the suggested platform across a large-scale network

The IoT, Blockchains and AI have great No implementation exists potential in terms of supporting initiatives integrating health and environmental data, including the potential to be part of a pan-Canadian surveillance system

Identifies the key points where the IoT and Blockchains can work well together

No implementation exists

Represents the Blockchain model for IoT-based healthcare applications

Disadvantages

(Dwivedi et al. 2019a)

Makes IoT application data and transactions more secure

Represents use of a Blockchain to provide secure management and analysis of healthcare big data

(Dwivedi et al. 2019b)

Advantages

Contribution

References

Table 6.1 Comparison of existing approaches for health care using Blockchains

6 IoT-Based Healthcare Monitoring Using Blockchain 145

Demonstration of an IoT cloud-based This architecture is cost-effective, smart healthcare model, which carries scalable, supports interoperability and out monitoring patient information, lightweight access collected by different remote sensors of medical services materials

Proposal of Blockchain-based smart contracts to encourage secure examination and administration of therapeutic sensors to handle protected health information (PHI) produced by IoT gadgets

Proposal of a platform for observing crucial patient signs, utilizing smart contracts based on Blockchains

Jaiswal et al. (2018)

Griggs et al. (2018)

Jamil et al. (2020)

Provides several benefits to patients, like an extensive, immutable history log and global access to medical data from anywhere at any time

Smart contracts would trigger alarms for patients and healthcare providers as appropriate, as well as recording details about transactions on the Blockchain

Analysis of specific aspects of secure Health data are collected from users’ outdoor healthcare monitoring in a wearable sensors with the help of an smart city, using Blockchain technology unmanned aerial vehicle (UAV); user data can be encrypted using the UAV’s public key

Islam and Shin (2019)

Advantages

Contribution

References

Table 6.1 (continued)

(continued)

Lack of extensive testing in various IoT frameworks

No implementation has been reported

The platform has not been deployed in a real healthcare environment

Does not evaluate the suggested platform across a large-scale network

Disadvantages

146 M. Vahdati et al.

Contribution

Proposal of a healthcare system utilizing Blockchain-based smart contracts that support patient enrollment and specialists in a health center, subsequently expanding user cooperation in remote patient monitoring

Exploration of IoT-based Blockchain advances addressing the issue of fraud and manhandled drugs within the pharmaceutical supply chain

Presentation of a prototype Blockchain solution for private and secure individual “Omics” health data management and sharing

References

Kazmi et al. (2020)

Ahmadi et al. (2020)

Lemieux et al. (2020)

Table 6.1 (continued) Disadvantages

The project studies potential ethical, No implementation has been reported legal, social and cognitive constraints of self-organized healthcare data management and sharing, and whether such constraints can be addressed through careful user interface design of a Blockchain solution

Improves drug administration throughout No implementation has been reported the supply chain, making healthcare more effective and dependable

Their framework monitors patients from No implementation has been reported a distance and produces alerts if a crisis occurs Smart contracts are used for authorization of its devices, constituting a legalized and secure way of using medical sensors

Advantages

6 IoT-Based Healthcare Monitoring Using Blockchain 147

148

M. Vahdati et al.

through empowering collaboration and communication between the IoT and humans (Mezghani et al. 2017).

6.3.2 Overview of Blockchain Technology The Blockchain network concept is started out as a decentralized, immutable ledger framework for transactional information management (Lu 2019; Wang et al. 2019b). This technology is capable of revolutionizing a wide range of domains, from finance to administration, by promoting security, reliability and transparency, established via a decentralized and equitable computational model (Jacobsen et al. 2018); Zhang et al. 2018), with a high level of privacy guaranteed (Liu et al. 2019). Blockchain technology has recently received much critical attention from academic environment and industry due to its capabilities (Nelaturu et al. 2020). This technology was initially created to handle monetary transactions within the context of digital currency, using a peer-to-peer network (Adler et al. 2018). Blockchain technology includes some applications in different fields (Cai et al. 2018; Namasudra et al. 2020b). In Blockchain technology, consensus protocols maintain information consistency and integrity over all nodes on the network, organized in a distributed fashion. The purpose of most consensus protocols within the Blockchain is to guarantee that each distributed copy of shared information is updated correctly throughout the chain. Basically, the consensus is an agreement that needs each participant’s approval for the new block to be added to the Blockchain network (Baliga 2017; Wang et al. 2019c). Blockchain technologies use different consensus algorithms, which can be roughly divided into consensus protocols such as “proof of concept” (PoC), “proof of work” (PoW), “proof of stake” (PoS), “delegated proof of stake” (DPoS), “proof of authority” (PoA) and “Byzantine fault-tolerant replication” (Liu et al. 2020). Design of the next-generation healthcare information systems is a significant application area for Blockchain technology (Miši´c et al. 2019). Blockchain technologies provide advanced security and privacy properties to IoT-based remote patientmonitoring systems (Srivastava et al. 2019). Furthermore, Blockchain technology brings with it fundamental and unique value, such as integrity, timelessness, interoperability, irreplaceability, reliability, reduced verification costs, networking and decentralization in health care (Abujamra and Randall 2019; Gordon and Catalini 2018; Koshechkin et al. 2018; McGhin et al. 2019). As a summary, Blockchain technologies are computationally costly, requiring a high transfer speed and extra computational power. But, this technology is able to solve many serious problems in a wide range of applications including modern IoT-based healthcare monitoring.

6 IoT-Based Healthcare Monitoring Using Blockchain

149

6.3.3 Smart Contract The term “smart contract” was first coined by Szabo (1996) as “a set of promises, specified in digital form, including protocols within which the parties perform on these promises” (Szabo 1996). Smart contracts could be defined as the computer protocols that digitally facilitate, verify and exert the contracts created among parties on a Blockchain. Smart contracts are ordinarily deployed and secured by a Blockchain. Firstly, the program code of a smart contract is recorded and confirmed on the Blockchain. Secondly, the execution of a smart contract is implemented among anonymous, trustless nodes without centralized control or coordination of third-party specialists. Thirdly, a smart contract, like an intelligent agent, might have its own cryptocurrencies or other digital assets, and it can transfer them when predefined conditions are triggered (Stark 2016; Wang et al. 2019a). Recently, smart contracts have been developed to deploy multiple interactions for Ethereum using “Solidity” programing language (Nelaturu et al. 2020). Smart contract technology can solve substantial challenges associated with the healthcare domain in terms of managing and enforcing contracts without the interference of a third party in order to improve interoperability and privacy in healthcare processes. A smart contract in a Blockchain can provide a safe way to create a significant connection between a patient’s medical data and useful medical guidelines. This system reduces the costs of healthcare services and increases their accessibility (Kormiltsyn et al. 2019). In Fig. 6.1, the main objective, i.e., to share patient information through Blockchain smart contracts among hospitals, laboratories, doctors, patients, insurance companies, pharmacies and consultants is presented.

6.3.4 Algorithms and Tools for Medical Blockchain Depending on how Blockchain technology is to be used in the medical domain, different algorithms and tools are used to define solutions. Algorithms and tools can be studied from two perspectives, and these perspectives are explained in the next two paragraphs. Financial: From a financial perspective, several cryptocurrencies, such as Dentcoin (2020), are reported to facilitate financial transactions in medical domains. Since the amounts of money and number of transactions in healthcare systems are increasing, and digital money can be used to decrease the number of contacts and interactions among users, cryptocurrencies are likely to play an essential role in medical Blockchains. During the COVID-19 pandemic, this approach has been followed in several countries, such as China (Chamola et al. 2020). On the other hand, Initial Coin Offering (ICO) techniques may be used to decrease paperwork and difficulties associated with collecting money for medical problems in different fields. It is worth noting that utilizing cryptocurrencies that are customized for medical

150

M. Vahdati et al.

Fig. 6.1 Smart contract for health care

problems may help define better treatment plans using gamification techniques as a means of incentivizing those people who follow the guidelines defined by doctors. Technical: From a technical perspective, many tools and algorithms are reported in the literature to solve different types of problems. Blockchain technology facilitates three activities, as described below: • Patients’ medical records can be transferred with a high degree of security and privacy. • Management of the medicine supply chain can be done with a high level of accuracy. • Healthcare researchers can study patient records, and genetic codes can be analyzed in accordance with legal routines. From a technical point of view, some challenges can be solved by a Blockchainbased algorithm very efficiently. Moreover, such an algorithm could be integrated with other solutions. For example, in Azaria et al. (2016), secure access controls in healthcare systems are designated. Blockchain can also be used to secure data sharing, as reported in Xia et al. (2017). Medical records can be stored in Blockchain with a

6 IoT-Based Healthcare Monitoring Using Blockchain

151

high degree of security, such as one algorithm reported in Dubovitskaya et al. (2018). Recently reported studies focusing on the abovementioned activities are discussed below: • In BurstIQ 2020, a platform is reported that manages patient data considering safety and security issues handled by Blockchain technology. This platform includes information about patients’ health and healthcare activities. • In SimplyVital Health 2020, a system is reported to establish decentralized technologies for healthcare industries. It helps healthcare experts to access patient information quickly. This company recently cooperated with genomics and precision medicine company Shivom in order to organize a global healthcare Blockchain alliance to protect DNA sequencing data. • In Coral Health 2020, the author presents a Blockchain-based system to accelerate the care control process in relation to administrative processes and health outcomes. Many actors, such as doctors, scientists, laboratory technicians and public health authorities, can be connected to each other using a Blockchain based network very quickly. To ensure accuracy of the data and treatment process, this company implements smart contracts between patients and healthcare professionals. • In Medicalchain 2018, the system utilizes a Blockchain to store health records, addressing integrity and truth issues. This company also supports patient consultations with doctors using “MedTokens”. • In chronicled 2020, the author proposes a Blockchain in order to demonstrate a solution to help pharma companies track medicine deliveries and also provide a detailed review of drug shipments. • The Center for Disease Control and Prevention (CDC) works on diseases in a supply-chain-based manner utilizing Blockchain technology (CDC 2020). Blockchain technology can consider timestamps, peer-to-peer health reporting and data processing in a real-time fashion. These capabilities can be used in pandemic situations. • The EncrypGen (GENE-CHAIN 2020) is a Blockchain-based platform that focuses on the security and privacy of genetic information. This platform facilitates activities such as searching, sharing, saving, buying, and selling of genetic information. • In XMED Chain 2018, XMED Chain (XMC) is reported. This platform focuses on artificial intelligence and big data technologies. This platform can provide a sustainable, patient-oriented and intelligent ecosystem solution, which can be organized to build a more efficient global healthcare system. In this part, firstly two aspects of algorithms and tools in medical Blockchain are considered. The position of Blockchain-based algorithms in healthcare systems is then analyzed. Finally, the solutions presented by various companies in different domains are summarized.

152

M. Vahdati et al.

6.3.5 IoT Sensors for Monitoring Drugs IoT sensors play an important role in healthcare systems. The IoT supports a wide range of body sensors, including pulse rate, blood oxygen level, distance traveled, maximal oxygen consumption, body temperature, blood pressure, blood glucose level, EEG, ECG and calories burned. These sensors can be used either in wearable devices or body implants. Information gathered by these sensors may be used to different purposes such as fall detection, diabetes control, sleep monitoring and hearth attack detection. In contracts to traditional sensing elements, the IoT sensors are cheap and also small enough to be used in a wide range of devices. A type of IoT sensors that enables online drug monitoring has revolutionized healthcare monitoring systems. In healthcare systems, drug monitoring plays an important role in different fields for different actors in healthcare systems. Drug monitoring activity refers to measurement of medication levels in the blood, and this can be done using IoT sensors in an online fashion. In the literature, many algorithms based on drug monitoring using IoT sensors are given to design modern IoT-based treatments. The overdose and underdose of a drug may lead to hurtful situation for patents. A small change in insulin and glucose in the blood of patient leads to many problems. In Al-Odat et al. (2018) and Gia et al. (2017), some solutions based on IoT-based blood monitoring systems such as insulin and glucose are given for diabetic patients. In Othman (2019), an IoT-based system for medication dose calculator for children is presented.

6.4 The Proposed Architecture In this section, a novel architecture for IoT-based healthcare monitoring using Blockchain technology is proposed. This architecture is obtained from recently reported solutions given in (HamlAbadi et al. 2017; Saghiri et al. 2020, 2018; Vahdati et al. 2018), and (Abujamra and Randall 2019; Jamil et al. 2020; Bublitz et al. 2019). An overview of the proposed architecture is given in Fig. 6.2. In this figure, dashed boxes refer to areas outside the proposed architecture. Users of this architecture can be patients, nurses, and doctors. IoT sensors and other devices act as sensing elements in the architecture to support functionalities of the network layer. Three main layers are identified in this architecture: (1) the network layer, (2) the IoT/Blockchain/AI services layer, and (3) application layers. Descriptions of these layers are given in the next three subsections.

6.4.1 Network Layer This layer provides the interconnection backbone for transferring data among many entities, such as doctors, patients, laboratories, ambulances, hospitals, and smart

6 IoT-Based Healthcare Monitoring Using Blockchain

153

Fig. 6.2 Proposed architecture for IoT-based healthcare monitoring using Blockchain

homes. Some scenarios demonstrating the functionalities of this layer are given as follows. IoT sensors enable online health monitoring, and the network layer directly transmits data to IoT/Blockchain/AI services layer. A connected home can monitor the daily activities of individuals which has the capability of monitoring human health through simple wireless measuring scales. Health centers in particular hospitals and clinics have benefited from new technologies integrating the IoT into health care, which play a vital part in improving the quality of medical care, bringing comfort

154

M. Vahdati et al.

for patients and improving the management level of healing centers. In medical emergencies, smart ambulance sensors such as heart rate sensors, blood pressure and ECGs will determine the status of crucial parameters, and the status of these parameters can be sent to the hospital’s database at the same time as activity signals. Upon receiving data on the state of critical parameters, hospital specialists can then act accordingly. The network layer components are as follows: 1. Routing management unit: The routing management unit sets up a communication pathway from a source IoT device to a destination. The solution given in the Ramezan and Leung (2018) can be used in this unit. 2. Security management unit: The security management unit protects the data, a large number of devices, and interconnected systems. 3. Adaptive protocol management unit: Messaging protocols are a critical component in an IoT device, responsible for collecting data or sending commands, and they are used to transmit device messages from IoT devices to the IoT messaging hub. This unit adaptively manages the messaging protocols. 4. Connection management unit: The network communication system requires massive IoT capability, such as Wi-Fi, 2G/3G/4G, 5G, and 6G. 5. Gateway management unit: Gateway management is widely used to promote communication among smart devices.

6.4.2 IoT/Blockchain/AI Services Layer A primary challenge arising during the design of this layer is the complexity of the management processes, involving three elements: IoT, Blockchain and AI. In order to resolve this challenge, a framework for the Cognitive Internet of Things (CIoT) based on a Blockchain is utilized. This framework was proposed in Saghiri et al. (2018), HamlAbadi et al. (2017), and Vahdati et al. (2018). This framework suggests three layers, with the following descriptions, to organize management processes (Fig. 6.2): 1. Requirement layer: In this layer, the goals and behaviors of the system are determined using a language called Cognitive Specification Language (CSL). In Saghiri et al. 2018; HamlAbadi et al. 2017; Vahdati et al. 2018, the authors suggest use CSL, but it seems that any formal language (HTML) and informal language (English) can be used to determine the goals and behaviors of the system because cognitive engines can be used to extract goals and behaviors based on machine learning and natural language-processing (NLP) engines. 2. Cognitive process layer: In this layer, cognitive processes are organized. Each cognitive process may be designated to manage several tasks. In this layer, the designer develops one or more cognitive engines, and each cognitive engine has responsibility for managing certain cognitive processes. The cognitive process layer takes goals from the requirement layer and executes appropriate algorithms using sensors and actuators provided by the things’ management layer. Some essential cognitive processes are given below:

6 IoT-Based Healthcare Monitoring Using Blockchain

155

• Cognitive process for managing sensors and actuators. • Cognitive process for managing ontologies to facilitate communication among entities in healthcare systems. • Cognitive process for sharing learning models to facilitate learning in healthcare systems. • Cognitive process for authentication, identity management and privacy protection. • Cognitive process for managing smart contracts (triggering, execution and recovery). • Cognitive process for continually monitoring all entities involved in a healthcare system (doctors, patients, nurses, prescriptions, drugs, diets, and ambulances). • Cognitive process for predicting dangerous and unsafe states (such as pandemic situations and drug interactions). • Cognitive process for insurance management (Vahdati et al. 2018). • Cognitive process for securing patients’ data records. • Cognitive process for analyzing consensus algorithms. • Cognitive process for intrusion detection. • Cognitive process for processing and communication related to virtual/augmented reality devices in the thing’s management layer. • Cognitive process for managing digital twin of the system. Digital twin can be used to resolve complexities in the management algorithms. • Cognitive process for specific applications. Some application-specific cognitive processes are considered in Sect. 6.5 in relation to combating COVID-19. 3. Things management layer: In this layer, Blockchain technology is used to manage information related to the IoT. This layer has several units, as described below: • Blockchain unit: This unit manages the required information in multiple Blockchains. In this unit, several Blockchains for different types of data related to patient, drugs, DNA, and insurance are considered. In addition to healthcare-related data, information about microservices is stored in a separate Blockchain in the system. • Peer-to-peer communication unit: This unit manages peer-to-peer communication among different entities in the system. It plays an important role in managing thing-to-thing communications in Decentralized Autonomous Organization (DAO). • Smart contract unit: This unit manages issues related to smart contracts based on cognitive engines. In this unit, cognitive smart contract can be designated. • Payment unit: This unit manages financial transactions among entities in the system.

156

M. Vahdati et al.

6.4.3 Application Layer In this layer, DAO can be implemented based on distributed application logics. This layer also provides RESTful APIs to cooperate with other systems. The APIs can be used in internal parts of this architecture.

6.5 Case Study In this section, to apply the proposed architecture in different case studies, three algorithms, namely path recommendation for pandemic situations, health insurance recommendation, and fighting COVID-19 pandemic have been suggested. It should be noted that a wide range of AI and Blockchain-based solutions are given in the (Ebadi et al. 2020; Hussain et al. 2020, p. 19; Kassani et al. 2020) to combat COVID19. To implement these algorithms, different smart contracts in the cognitive engine must be provided. Table 6.2 presents descriptions of the smart contracts used for the proposed algorithms. Five Blockchains are included in the cognitive engines (see Table 6.3), and different microservices are used for the proposed algorithms. These services are available on a Blockchain platform. Table 6.4 presents a description of seven services. Three services viz path services, health insurance services and drug services are provided in this section.

6.5.1 Path Recommendation for Pandemic Situations In Algorithm 1, when a user wants to go to a particular destination, his information and location are sensed by the sensors and saved in Blockchain-users-positions. Once a destination location is confirmed by a user, the user’s commands are transmitted to the cognitive engine. In this case study, a user may send a command using his voice or a terminal, e.g., “Please recommend a safe path to travel from source X to destination Y.” In the cognitive engine, the corresponding microservices are called to interpret the commands in order to draw out the goals of the system for the user. According to the goals, that is, finding a safe path for the user, three smart contracts (e.g., the user-medical-records-contract, geographic-information-systemcontract and mass-surveillance-system-contract) can be fetched from the contractsBlockchain, and the corresponding recommendation microservice can be called. After this, the system can recommend an appropriate path for the user, and user road information is calculated based on the three smart contracts. Furthermore, the final distance for the user is computed by the systems. The user is then shown the path process for their destination. It should be noted that according to the goals determined by the user, the smart contracts are fetched based on the user’s medical records and

Contract actors Among users and some actors in the healthcare system Among users and some government actors

Among users and some actors in the healthcare system Among users, healthcare providers and health centers Among patients, healthcare providers and health centers Among users, healthcare providers and health centers

Smart contract

User-medical-records-contract

Geographic-information-system-contract

Mass-surveillance-system-contract

Doctor prescription-contract

User allergy information-contract

User DNA information-contract

Table 6.2 Smart contracts used in cognitive engines

(continued)

This contract collates information from users and health dossiers and conveys DNA information

This contract relays information about patients’ allergies to different drugs and indicates patterns of consumption

This contract collates user information and provides a doctor’s prescription

This contract collates user information and indicates patterns of movement. This concept is borrowed from (Torky and Hassanien 2020)

This contract collates user information and indicates the position of the user. This concept is reported in (Mashamba-Thompson and Crayton 2020)

This contract collates user information and provides the patient’s medical records

Description

6 IoT-Based Healthcare Monitoring Using Blockchain 157

Contract actors Among users, healthcare providers and health centers

Among users and health centers

Among users, healthcare providers and drug stores Among users, healthcare providers and drug stores

Among users and some government actors

Smart contract

Clinical test-contract

Clinic/hospital/pharmacy information-contract

Drug information-contract

Medical diagnosis and screening-contract

Tracing-contract

Table 6.2 (continued)

This contract connects individuals with each other and indicates patterns of movement and communication to government(Chamola et al. 2020)

This contract collates information relating to medical diagnoses and screening (such as testing kits, face scanners, medical imaging and voice detection systems) and sends diagnosis results to users (Chamola et al. 2020)

This contract collates information from healthcare providers and drug stores and conveys this to users

This contract collates information from medical centers and then indicates the services that are available to users

This contract collates information from users and health dossiers and returns test results such as molecular, serological (Chamola et al. 2020) and antibody (Eisenstadt et al. 2020) checks

Description

158 M. Vahdati et al.

6 IoT-Based Healthcare Monitoring Using Blockchain

159

Table 6.3 Blockchains used in cognitive engines Blockchain names

Description

User-positions-Blockchain

This Blockchain is used to maintain the positions of users

Contracts-Blockchain

This Blockchain is used to maintain the contracts

User-medical-records-Blockchain This Blockchain is used to maintain users’ medical records Communications-Blockchain

This Blockchain is used to maintain communication among users

Microservices-Blockchain

This Blockchain is used to maintain the microservices

Table 6.4 Microservices used in cognitive engines Microservices

Description

Infection-info-service

This service provides information about the COVID-19 pandemic

RS-service

The RS-service uses cognitive recommender systems to recommend items for users (HamlAbadi et al. 2017)

Fake news-service

This service tracks fake news published on Web sites, Twitter and other social networks and indicates which information is valid (Chamola et al. 2020)

Curative investigate-service

This service tracks relevant research for users, e.g., drugs and development of vaccines for different diseases such as COVID-19 (Chamola et al. 2020)

Medical-supply-chain-service

This service uses medical supply-chain information in order to track drug production (Chamola et al. 2020)

Donate-service

This service tracks individuals and organizations which provide donations (Chamola et al. 2020)

Global-economy-services

In order to suggest appropriate solutions, this service considers the effects of the COVID-19 pandemic on the global economy such as the automotive industry and tourism industry, etc. (Chamola et al. 2020)

path information. The user can finally take the safest route to his destination, i.e., in the case of the COVID-19 pandemic, a low-risk route.

160

M. Vahdati et al.

Algorithm 1: Cognitive engine for path recommendation Input: User commands; user information collected by the sensors Output: A safe path recommendation sent to the user Notations: User-Medical-Records-Contract: A smart contract as described in Table 6.2 Geographic-Information-System-Contract: A smart contract as described in Table 6.2 Mass-Surveillance-System-Contract: A smart contract as described in Table 6.2 Contracts-Blockchain: A Blockchain as described in Table 6.3 Users-Positions-Blockchain: A Blockchain as described in Table 6.3 Users-Medical-Records-Blockchain: A Blockchain as described in Table 6.3 Communications-Blockchain: A Blockchain as described in Table 6.3 RS-Service: A service provided for cognitive engines, as described in Table 6.4 Infection-Info-Service: A service provided for cognitive engines, as described in Table 6.4 01: Begin 02: Receive the user’s commands; // Command can be “P lease recommend a safe path to travel from X starting point to Y destination.” 03: Interpret the commands according to the goals of the system; 04: For each smart contract required by the cognitive engine, do 05 Fetch smart contracts from the contracts-Blockchain; 06: End 07: Call RS-Service; // Provides a list of path recommendations; 08: Calculate a safe path using smart contracts and information from the Blockchains; // All contracts, services and Blockchains introduced in the notations are used in this syntax; 09: Compute the final distance for user; 10: Execute path recommendation process using the user-selected destination. End

6.5.2 Health Insurance Recommendation In health insurance recommendations, each user has an identifier, and his/her information is saved in the Blockchain. The system goals are determined based on the user’s commands with considering user’s environmental information collected by IoT sensors. The goals of the systems can be set automatically by the system or manually by the user and is obtained by the cognitive engine. The system’s output can recommend an appropriate insurance package to the user.

6 IoT-Based Healthcare Monitoring Using Blockchain

161

In the cognitive engine, the corresponding microservices are called to interpret the commands in order to draw out the goal of recommending an appropriate insurance package for the customer. In accordance with this goal, an algorithm including three phases is executed. These phases are explained as follows. In the first phase, different smart contracts can be fetched. These smart contracts include the following: • A smart contract for users’ medical records: This smart contract can be used to produce a suitable insurance package for users, as described in Table 6.2. • A smart contract for a doctor’s prescription: This smart contract can be used to produce an insurance package according to an individual’s medical prescription, as described in Table 6.2. • A smart contract for user’s DNA information: This smart contract can be used to produce an insurance package according to an individual’s DNA information, as described in Table 6.2. • A smart contract for user allergy information: This smart contract can be used to produce an insurance package according to an individual’s allergy information, e.g., an allergy to drugs, a seasonal allergy or other allergies, as described in Table 6.2. • A smart contract for clinical test needs: This smart contract can be used to produce an insurance package according to an individual’s clinical test results, as described in Table 6.2. • A smart contract for clinical/hospital/pharmacy information: This smart contract can be used to produce an insurance package according to clinical/hospital/pharmacy information, locations, and services, as described in Table 6.2. • A smart contract for drug information: This smart contract can be used to produce an insurance package according to an individual’s medication details, as described in Table 6.2. • A smart contract for medical diagnosis and screening: This smart contract can be used to produce an insurance package according to an individual’s medical diagnosis and screening, as described in Table 6.2. In the second phase, the corresponding microservices can be called. These smart contracts include the following: • RS-Service: This service provides users with a list of insurance recommendations from the cognitive engines, as described in Table 6.4. • Infection-Info-Service: This service provides information for cognitive engines as described in Table 6.4. This service may take into consideration the COVID-19 pandemic in order to create an appropriate package. • Medical-Supply-Chain-Service: This service provides information for cognitive engines as described in Table 6.4. Calling this service is used to track medication information to create an appropriate package with high accuracy.

162

M. Vahdati et al.

• Donate-Service: This service provides information for cognitive engines as described in Table 6.4. This service can track people’s needs and then consider charitable services for these types of people. • Global-Economy-Services: This service provides information for cognitive engines as described in Table 6.4. Calling this service is used to track industrial needs and then consider supportive services for each type of industry. In the third phase, the best insurance package can be provided using smart contracts. During this phase, information can be provided from the Blockchains, and relevant discounts can be calculated for insurance packages. Finally, the requisite payment is processed, and the user’s account is updated to reflect the transaction.

6.5.3 Fighting COVID-19 Pandemic In Algorithm 2, the system goals are determined by the user’s commands with particular attention to user’s environmental information collected by IoT sensors. The goals of the system can be set automatically by the system or manually by the user and is obtained by the cognitive engine. System output can be represented on a dashboard. This dashboard utilizes data that can be used to mitigate the impact of the COVID-19 outbreak through predicting, tracking, detecting and managing the pandemic. In the cognitive engine, user commands can be organized into a system for managing COVID-19. According to the system’s goals, all smart contracts (as described in Table 6.2) can be fetched. In addition, all corresponding services (as described in Table 6.4) can be called to interpret the commands in order to draw out the goals. Then, suitable dashboards will be handled by the system for managing COVID-19 outbreak. Based on the cognitive engine, six dashboards will be represented to the user as described follows; 1) virus modeling and analysis, 2) prediction of future outbreaks, 3) virus outbreak estimation, 4) risk prediction, 5) medical development, and 6) COVID-19 test certificate. Furthermore, based on appropriate information like user’s DNA and information relating to pharmaceutical services, different treatments can be developed (e.g., drugs and vaccines). This information can be used to organize an appropriate panel. Eventually, the proposed algorithms will facilitate verification of COVID-19 antibody testing, vaccines, and then will issue a valid certificate for them. These certificates will be registered in the Blockchain in a transparent and immutable manner (Eisenstadt et al. 2020). A panel on the dashboard is dedicated to show the certificates. The Blockchain-based functionalities of the proposed architecture will be useful for equitable COVID-19 vaccine distribution.

6 IoT-Based Healthcare Monitoring Using Blockchain

163

Algorithm 2: Cognitive engine for fighting the COVID-19 pandemic Input: User commands; Output: Dashboards for managing the impact of the COVID-19 outbreak; // Several dashboards including predictions, tracking, detection and management of COVID-19 will be shown to the user. 01: Begin 02: Take the user’s commands; // Command can be “P lease organize a system to manage COVID-19.” 03: Interpret the commands in accordance with the goals of the system; 04: For each smart contract required by the cognitive engine, 05: Fetch smart contracts from the contracts-Blockchain; // Fetch all smart contracts as described in Table 6.2; 06: End 07: For each service required by the cognitive engine, 08: Call a service list from the service-Blockchain; // Call all services as described in Table 6.4; 09: End 10: Call path recommendation from cognitive engine; // Provides a list of path recommendations; 11: Organize dashboards for virus modeling and analysis; // Organize a panel to represent virus modeling and analysis; 12: Organize dashboards for prediction of future outbreaks of the virus; // Organize a panel to represent predictions of future virus outbreaks; 13: Organize dashboards for virus outbreak estimation; // Organize a panel to represent predictions of future virus outbreaks; 14: Organize dashboards for risk prediction; // Organize a panel to represent risk prediction; 15: Organize dashboards for medical developments; // Organize a panel to represent medical developments such as vaccines and drugs; 16: Organize dashboards for COVID-19 test certificates; // Issue a valid COVID-19 test certificate such as an antibody test/vaccination, and organize a panel to represent this test certification. 17: End

6.6 Discussion and Potential Applications In this subsection, potentials of the proposed architecture to solve many of the problems caused by COVID-19 are studied. To start with, a short description of this disease is given, and potential applications for the proposed architecture are presented. COVID-19 is an infectious disease caused by the coronavirus. In this disease, common symptoms include fever, coughing, shortness of breath, muscle pain, sputum production, a sore throat, indigestion, and redness of the eyes. The time between exposure to the disease and the onset of symptoms is 2–14 days. Humans may prevent this disease by keeping a certain amount of distance among themselves (Mehta et al. 2020; Schwartz et al. 2020).The proposed architecture will handle the following potential applications: 1. Smart social distance determination: The proposed architecture can determine social distances, taking into consideration high-risk humans. It seems that determining a fixed distance for all humans may not be rational because of variations in medical status from person to person. This application can be implemented using proposed architecture. Because of access to users’ medical records, IoT sensors can gather information about the environment in an selective fashion. For example, for a person with high allergy, sensors focus on allergen entities. The solution given in Devi et al. (2020) may be used to design an adaptive distance determination.

164

M. Vahdati et al.

2. Population control using gamification: The proposed architecture can be used along with gamification to change the behavior of individuals, using the concept of reinforcement learning , and mechanism design. The proposed architecture can extract the movement pattern, behavior for each person. A gamification mechanism utilizing cryptocurrencies and tokens (rewards and punishment) may be applied to encourage people to change their behavior. The proposed architecture can support the mentioned mechanism entirely through the use of smart contracts and Blockchain. Governments may use this solution in their countries. 3. Online parameter prediction: Application will enable prediction of the number of infected and cured cases in online fashion. The proposed architecture, with the aid of the IoT and AI, can predict several parameters in the system, both online and offline. 4. Pattern mining for healthcare purposes: The proposed architecture can be used to determine safe and useful lifestyles for humans using a large amount of data gathered from medical records. This information may be used to obtain valuable knowledge about finding a proper diet and establishing habits to keep infection rates low. 5. Genetic-based analyses: The proposed architecture may be used to store and handle genetic information relating to humans. Analysis of this information may be used to predict pandemic situations and also detect those people who are resistant to some diseases, by considering certain genetic features. In this architecture, DNA information may be stored in the Blockchain, and then users can share their keys with relevant experts using smart contracts based on privacy protected mechanisms.

6.7 Performance Analysis In the previous section, an architecture for IoT-based healthcare monitoring using Blockchain was proposed. This architecture is generalized, and it can be used to design a wide range of algorithms in the healthcare systems. The performance of this architecture is characterized by the following (Saghiri 2020a): • Reliability: The proposed architecture can manage data with a high degree of reliability because of the capabilities of Blockchain technology. • Decentralization: The proposed architecture can be used to design algorithms that can avoid monopolies, using certain concepts in Blockchain technology, such as consensus algorithms. • Scalability: The proposed design can support scalability using some hybrid techniques in the fusion of Blockchains and IoT systems. • User anonymity: The proposed architecture can provide anonymity for users via peer-to-peer and Blockchain technologies. • Security and privacy: Blockchain technology ensures that users’ data are protected, and confidentiality is maintained.

6 IoT-Based Healthcare Monitoring Using Blockchain

165

• Portability: Some parts of the system such as the database and back-end are based on Blockchains, and designers may organize a portable application such as DAOs using the proposed architecture, considering this feature.

6.8 Conclusions and Future Works In this chapter, a novel architecture for modern healthcare systems has been proposed. This architecture is an extension to a recently reported framework for cognitive IoT based on Blockchain considering healthcare monitoring issues. In comparison with existing solutions for healthcare monitoring systems, a main advantage of the proposed architecture is to utilize cognitive computing to organize management processes in IoT-based Blockchain systems. To show the potential of the proposed architecture, some case studies aimed at combating COVID-19 have been presented. In presented case studies, the suggested solutions are able to manage impact of COVID-19 outbreak. In future work, designing gamification algorithms to change human behaviors in relation to infection rates may be considered. As another direction in the future work, digital twin technology may be deployed by the cognitive engines of the proposed architecture. Digital twin technology may also be used to design personalized medicine in healthcare systems. Acknowledgements Last but not least, I am dedicating this chapter to my late father Mohammad Vahdati gone forever away from our loving eyes and who left a void never to be filled ever. Though your life was short, I will make sure your memory lives on as long as I shall live. I love you all and miss you all beyond words.

References Abujamra, R., & Randall, D. (2019). Chapter Five—Blockchain applications in healthcare and the opportunities and the advancements due to the new information technology framework. In S. Kim, G. C. Deka, & P. Zhang (Eds.), Advances in Computers (Vol. 115, pp. 141–154). Elsevier. https://doi.org/10.1016/bs.adcom.2018.12.002. Adler, J., Berryhill, R., Veneris, A., Poulos, Z., Veira, N., & Kastania, A. (2018). Astraea: A decentralized blockchain oracle. In 2018 IEEE international conference on internet of things (IThings) and IEEE green computing and communications (GreenCom) and IEEE cyber, physical and social computing (CPSCom) and IEEE smart data (SmartData) (pp. 1145–1152). https:// doi.org/10.1109/Cybermatics_2018.2018.00207. Ahmadi, V., Benjelloun, S., El Kik, M., Sharma, T., Chi, H., & Zhou, W. (2020). Drug Governance: IoT-based blockchain implementation in the pharmaceutical supply chain. Sixth International Conference on Mobile and Secure Services (MobiSecServ), 2020, 1–8. https://doi.org/10.1109/ MobiSecServ48690.2020.9042950. Ajerla, D., Mahfuz S., Zulkernine F. (2019). A real-time patient monitoring framework for fall detection Hindawi. https://doi.org/10.1155/2019/9507938.

166

M. Vahdati et al.

Al-Odat, Z. A., Srinivasan, S. K., Al-qtiemat, E., Dubasi, M. A. L., & Shuja, S. (2018). IoT-based secure embedded scheme for insulin pump data acquisition and monitoring. ArXiv:1812.02357 [Cs]. https://arxiv.org/abs/1812.02357. Attia, O., Khoufi, I., Laouiti, A., & Adjih, C. (2019). An IoT-blockchain architecture based on hyperledger framework for healthcare monitoring application. In 2019 10th IFIP international conference on new technologies, mobility and security (NTMS) (pp. 1–5). https://doi.org/10.1109/ NTMS.2019.8763849. Azaria, A., Ekblaw, A., Vieira, T., & Lippman, A. (2016). MedRec: Using blockchain for medical data access and permission management. In 2016 2nd International Conference on Open and Big Data(OBD) (pp. 25–30). https://doi.org/10.1109/OBD.2016.11. Baliga, A. (2017). Understanding blockchain consensus models. https://www.persistent.com/wpcontent/uploads/2018/02/wp-understanding-blockchain-consensus-models.pdf. Bublitz, M., & F., Oetomo, A., S. Sahu, K., Kuang, A., X. Fadrique, L., E. Velmovitsky, P., M. Nobrega, R., & P. Morita, P. . (2019). Disruptive technologies for environment and health research: An overview of artificial intelligence, blockchain, and internet of things. International Journal of Environmental Research and Public Health, 16(20), 3847. https://doi.org/10.3390/ijerph162 03847. BurstIQ. (2020). BurstIQ|research foundry|blockchain based healthcare data solutions. https:// www.burstiq.com/. Cai, W., Wang, Z., Ernst, J. B., Hong, Z., Feng, C., & Leung, V. C. M. (2018). Decentralized applications: The blockchain-empowered software system. IEEE Access, 6, 53019–53033. https:// doi.org/10.1109/ACCESS.2018.2870644. CDC. (2020). CDC Works 24/7. Centers for Disease Control and Prevention. https://www.cdc.gov/ index.htm. Chamola, V., Hassija V., Gupta V., Guizani M. (2020). A comprehensive review of the COVID-19 pandemic and the role of IoT, drones, AI, blockchain, and 5G in managing its impact. IEEE Access, 8, 90225–90265. https://doi.org/10.1109/ACCESS.2020.2992341. Chronicled. (2020). Chronicled. https://www.chronicled.com/. Conoscenti, M., Vetrò, A., & De Martin, J. C. (2016). Blockchain for the internet of things: A systematic literature review. In 2016 IEEE/ACS 13th international conference of computer systems and applications (AICCSA) (pp. 1–6). https://doi.org/10.1109/AICCSA.2016.7945805. Coral Health. (2020). Coral health—building a more connected future in healthcare. https://myc oralhealth.com/product/. Dentcoin. (2020). Dentacoin: The blockchain solution for the global dental industry. https://dentac oin.com/. Devi, D., Namasudra, S., & Kadry, S. (2020, July 1). A boosting-aided adaptive cluster-based undersampling approach for treatment of class imbalance problem (Article). International Journal of Data Warehousing and Mining (IJDWM). www.igi-global.com/article/a-boostingaided-adaptive-cluster-based-undersampling-approach-for-treatment-of-class-imbalance-pro blem/256163. Dorri, A., Kanhere, S. S., Jurdak, R., & Gauravaram, P. (2017). Blockchain for IoT security and privacy: The case study of a smart home. IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops), 2017, 618–623. https://doi.org/10.1109/ PERCOMW.2017.7917634. Dubovitskaya, A., Xu, Z., Ryu, S., Schumacher, M., & Wang, F. (2018). Secure and trustable electronic medical records sharing using blockchain. AMIA Annual Symposium Proceedings, 2017, 650–659. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5977675/. Dwivedi, A. D., Malina, L., Dzurenda, P., & Srivastava, G. (2019a). Optimized blockchain model for internet of things based healthcare applications. In 2019 42nd international conference on telecommunications and signal processing (TSP) (pp. 135–139). https://doi.org/10.1109/TSP. 2019.8769060.

6 IoT-Based Healthcare Monitoring Using Blockchain

167

Dwivedi, A. D., Srivastava, G., Dhar, S., & Singh, R. (2019b). A decentralized privacy-preserving healthcare blockchain for IoT. Sensors (Basel, Switzerland), 19(2). https://doi.org/10.3390/s19 020326. Ebadi, A., Xi, P., Tremblay, S., Spencer, B., Pall, R., & Wong, A. (2020). Understanding the temporal evolution of COVID-19 research through machine learning and natural language processing. ArXiv:2007.11604 [Cs]. https://arxiv.org/abs/2007.11604. Eisenstadt, M., Ramachandran, M., Chowdhury, N., Third, A., & Domingue, J. (2020). COVID-19 Antibody test/vaccination certification: There’s an app for that. IEEE Open Journal of Engineering in Medicine and Biology, 1, 148–155. https://doi.org/10.1109/OJEMB.2020.2999214. Fernández-Caramés, T. M., & Fraga-Lamas, P. (2018). Design of a fog computing, blockchain and iot-based continuous glucose monitoring system for crowdsourcing mHealth. Proceedings, 4(1), 37. https://doi.org/10.3390/ecsa-5-05757. Foteinos, V., Kelaidonis, D., Poulios, G., Vlacheas, P., Stavroulaki, V., & Demestichas, P. (2013). Cognitive management for the internet of things: A framework for enabling autonomous applications. IEEE Vehicular Technology Magazine, 8(4), 90–99. https://doi.org/10.1109/MVT.2013. 2281657. GENE-CHAIN. (2020). DNA data marketplace. EncrypGen. https://encrypgen.com/. Gia, T. N., Ali, M., Dhaou, I. B., Rahmani, A. M., Westerlund, T., Liljeberg, P., & Tenhunen, H. (2017). IoT-based continuous glucose monitoring system: A feasibility study. Procedia Computer Science, 109, 327–334. https://doi.org/10.1016/j.procs.2017.05.359. Gordon, W. J., & Catalini, C. (2018). Blockchain technology for healthcare: Facilitating the transition to patient-driven interoperability. Computational and Structural Biotechnology Journal, 16, 224–230. https://doi.org/10.1016/j.csbj.2018.06.003. Griggs, K. N., Ossipova, O., Kohlios, C. P., Baccarini, A. N., Howson, E. A., & Hayajneh, T. (2018). Healthcare blockchain system using smart contracts for secure automated remote patient monitoring. Journal of Medical Systems, 42(7), 130. https://doi.org/10.1007/s10916-018-0982-x. Gupta, S., Malhotra, V., & Singh, S. N. (2020). Securing IoT-driven remote healthcare data through blockchain. In M. L. Kolhe, S. Tiwari, M. C. Trivedi, & K. K. Mishra (Eds.), Advances in data and information sciences (pp. 47–56). Springer. https://doi.org/10.1007/978-981-15-0694-9_6. HamlAbadi, K. G., Saghiri, A. M., Vahdati, M., Dehghan TakhtFooladi, M., & Meybodi, M. R. (2017). A framework for cognitive recommender systems in the internet of things (IoT). In 2017 IEEE 4th international conference on knowledge-based engineering and innovation (KBEI) (pp. 0971–0976). https://doi.org/10.1109/KBEI.2017.8324939. Hang, L., Choi, E., & Kim, D.-H. (2019). A novel EMR integrity management based on a medical blockchain platform in hospital. Electronics, 8(4), 467. https://doi.org/10.3390/electr onics8040467. Hassanalieragh, M., Page, A., Soyata, T., Sharma, G., Aktas, M., Mateos, G., et al. (2015). Health monitoring and management using internet-of-things (IoT) sensing with cloud-based processing: Opportunities and challenges. IEEE International Conference on Services Computing, 2015, 285–292. https://doi.org/10.1109/SCC.2015.47. Huh, S., Cho, S., & Kim, S. (2017). Managing IoT devices using blockchain platform. In 2017 19th International Conference on Advanced Communication Technology (ICACT) (pp. 464–467). https://doi.org/10.23919/ICACT.2017.7890132. Hussain, A. A., Bouachir, O., Al-Turjman, F., & Aloqaily, M. (2020). AI techniques for COVID-19. IEEE Access, 8, 128776–128795. https://doi.org/10.1109/ACCESS.2020.3007939. Islam, A., & Shin, S. Y. (2019). BHMUS: blockchain based secure outdoor health monitoring scheme using UAV in smart city. In 2019 7th international conference on information and communication technology (ICoICT) (pp. 1–6). https://doi.org/10.1109/ICoICT.2019.8835373. Jacobsen, H.-A., Sadoghi, M., Tabatabaei, M. H., Vitenberg, R., & Zhang, K. (2018). Blockchain landscape and AI renaissance: The bright path forward. In Proceedings of the 19th international middleware conference tutorials, Vol. 1. https://doi.org/10.1145/3279945.3279947. Jaiswal, K., Sobhanayak, S., Turuk, A. K., Bibhudatta, S. L., Mohanta, B. K., & Jena, D. (2018). An IoT-cloud based smart healthcare monitoring system using container based virtual environment

168

M. Vahdati et al.

in edge device. International conference on emerging trends and innovations in engineering and technological research (ICETIETR), 2018, 1–7. https://doi.org/10.1109/ICETIETR.2018. 8529141. Jamil, F., Ahmad, S., Iqbal, N., & Kim, D.-H. (2020). Towards a remote monitoring of patient vital signs based on IoT-based blockchain integrity management platforms in smart hospitals. Sensors, 20(8), 2195. https://doi.org/10.3390/s20082195. Kassani, S. H., Kassasni, P. H., Wesolowski, M. J., Schneider, K. A., & Deters, R. (2020). Automatic detection of coronavirus disease (COVID-19) in X-ray and CT images: A machine learning-based approach. ArXiv:2004.10641 [Cs, Eess]. https://arxiv.org/abs/2004.10641. Kazmi, H. S. Z., Nazeer, F., Mubarak, S., Hameed, S., Basharat, A., & Javaid, N. (2020). Trusted remote patient monitoring using blockchain-based smart contracts. In L. Barolli, P. Hellinckx, & T. Enokido (Eds.), Advances on broad-band wireless computing, communication and applications (pp. 765–776). Springer International Publishing. https://doi.org/10.1007/978-3-03033506-9_70. Kormiltsyn, A., Udokwu, C., Karu, K., Thangalimodzi, K., & Norta, A. (2019). Improving healthcare processes with smart contracts. In W. Abramowicz & R. Corchuelo (Eds.), Business information systems (pp. 500–513). Springer International Publishing. https://doi.org/10.1007/978-3030-20485-3_39. Koshechkin, K. A., Klimenko, G. S., Ryabkov, I. V., & Kozhin, P. B. (2018). Scope for the application of blockchain in the public healthcare of the Russian federation. Procedia Computer Science, 126, 1323–1328. https://doi.org/10.1016/j.procs.2018.08.082. Kshetri, N. (2017). Can Blockchain strengthen the internet of things? IT Professional, 19(4), 68–72. https://doi.org/10.1109/MITP.2017.3051335. Lemieux, V. L., Hofman, D., Hamouda, H., Batista, D., Kaur, R., Pan, W., Costanzo, I., Regier, D., Pollard, S., Weymann, D., & Fraser, R. (2020). Having our omic cake and eating it too: Evaluating user response to using blockchain technology for private & secure health data management and sharing. ArXiv:2004.11502 [Cs]. https://arxiv.org/abs/2004.11502. Liu, D., Alahmadi, A., Ni, J., Lin, X., & Shen, X. (2019). Anonymous reputation system for IIoTenabled retail marketing atop PoS blockchain. IEEE Transactions on Industrial Informatics, 15(6), 3527–3537. https://doi.org/10.1109/TII.2019.2898900. Liu, Y., Yu, F. R., Li, X., Ji, H., & Leung, V. C. M. (2020). Blockchain and machine learning for communications and networking systems. IEEE Communications Surveys Tutorials, 22(2), 1392–1431. https://doi.org/10.1109/COMST.2020.2975911. Lu, Y. (2019). The blockchain: State-of-the-art and research challenges. Journal of Industrial Information Integration, 15, 80–90. https://doi.org/10.1016/j.jii.2019.04.002. Mashamba-Thompson, T. P., & Crayton, E. D. (2020). Blockchain and artificial intelligence technology for novel coronavirus disease 2019 self-testing. Diagnostics, 10(4), 198. https://doi.org/ 10.3390/diagnostics10040198. McGhin, T., Choo, K.-K.R., Liu, C. Z., & He, D. (2019). Blockchain in healthcare applications: Research challenges and opportunities. Journal of Network and Computer Applications, 135, 62–75. https://doi.org/10.1016/j.jnca.2019.02.027. Medicalchain. (2018). Medicalchain. Medicalchain. https://medicalchain.com/Medicalchain-Whi tepaper-EN.pdf. Mehta, P., McAuley, D. F., Brown, M., Sanchez, E., Tattersall, R. S., & Manson, J. J. (2020). COVID19: Consider cytokine storm syndromes and immunosuppression. Lancet (London, England), 395(10229), 1033–1034. https://doi.org/10.1016/S0140-6736(20)30628-0. Mettler, M. (2016). Blockchain technology in healthcare: The revolution starts here. In 2016 IEEE 18th international conference on e-health networking, applications and services (Healthcom) (pp. 1–3). https://doi.org/10.1109/HealthCom.2016.7749510. Mezghani, E., Exposito, E., & Drira, K. (2017). A model-driven methodology for the design of autonomic and cognitive IoT-based systems: Application to healthcare. IEEE Transactions on Emerging Topics in Computational Intelligence, 1(3), 224–234. https://doi.org/10.1109/TETCI. 2017.2699218.

6 IoT-Based Healthcare Monitoring Using Blockchain

169

Miši´c, V. B., Miši´c, J., & Chang, X. (2019). Towards a blockchain-based healthcare information system: Invited paper. IEEE/CIC international conference on communications in China (ICCC), 2019, 13–18. https://doi.org/10.1109/ICCChina.2019.8855911. Mohammed, J., Lung, C.-H., Ocneanu, A., Thakral, A., Jones, C., & Adler, A. (2014). Internet of things: Remote patient monitoring using web services and cloud computing. In 2014 IEEE international conference on internet of things (IThings), and IEEE green computing and communications (GreenCom) and IEEE cyber, physical and social computing (CPSCom) (pp. 256–263). https://doi.org/10.1109/iThings.2014.45. Namasudra, S., & Roy, P. (2017). Time saving protocol for data accessing in cloud computing. IET Communications, 11(10), 1558–1565. https://doi.org/10.1049/iet-com.2016.0777. Namasudra, S., Roy, P., Vijayakumar, P., Audithan, S., & Balusamy, B. (2017). Time efficient secure DNA based access control model for cloud computing environment. Future Generation Computer Systems, 73, 90–105. https://doi.org/10.1016/j.future.2017.01.017. Namasudra, S. (Ed.). (2018). Taxonomy of DNA-based security models. In Advances of DNA computing in cryptography (pp. 53–68). Taylor & Francis. https://doi.org/10.1201/978135101 1419-3. Namasudra, S., & Deka, G. C. (2018). Advances of DNA computing in cryptography. Taylor & Francis. https://doi.org/10.1201/9781351011419. Namasudra, S., Deka, G. C., & Deka, G. C. (2018). Introduction of DNA computing in cryptography. In Advances of DNA computing in cryptography (pp. 17–34). Taylor & Francis. https://doi.org/ 10.1201/9781351011419-1. Namasudra, S. (2019). An improved attribute-based encryption technique towards the data security in cloud computing. https://onlinelibrary.wiley.com/doi/abs/10.1002/cpe.4364. Namasudra, S, Chakraborty, R., Majumder, A., & Moparthi, N. R. (2020a). Securing multimedia by using DNA based encryption in the cloud computing environment. ACM Transactions on Multimedia Computing, Communications, and Applications. Namasudra, S., Deka, G. C., Johri, P., Hosseinpour, M., & Gandomi, A. H. (2020b). The revolution of blockchain: State-of-the-art and research challenges. Archives of Computational Methods in Engineering. https://doi.org/10.1007/s11831-020-09426-0. Namasudra, S., Devi, D., Kadry, S., Sundarasekar, R., & Shanthini, A. (2020c). Towards DNA based data security in the cloud computing environment. Computer Communications, 151, 539–547. https://doi.org/10.1016/j.comcom.2019.12.041. Nelaturu, K., Mavridou, A., Veneris, A., & Laszka, A. (2020). Verified development and deployment of multiple interacting smart contracts with VeriSolid, Vol. 9. Othman, W. A. F. W. (2019). IoT-based intelligent medication dose calculator for kids in Drugstore. International Journal of Engineering Creativity & Innovation, 1(2), 15–29. https://www.academia.edu/40791933/IoT-Based_Intelligent_Medication_Dose_Calcul ator_for_Kids_in_Drugstore. Panarello, A., Tapas, N., Merlino, G., Longo, F., & Puliafito, A. (2018). Blockchain and IoT integration: A systematic survey. Sensors, 18(8), 2575. https://doi.org/10.3390/s18082575. Ramezan, G., & Leung, C. (2018). A Blockchain-based contractual routing protocol for the internet of things using smart contracts (Research Article). Hindawi: Wireless Communications and Mobile Computing. https://doi.org/10.1155/2018/4029591. Reyna, A., Martín, C., Chen, J., Soler, E., & Díaz, M. (2018). On blockchain and its integration with IoT. Challenges and opportunities. Future Generation Computer Systems, 88, 173–190. https:// doi.org/10.1016/j.future.2018.05.046. Saddik, A. E., Hossain, M. S., & Kantarci, B. (Eds.). (2020). Connected health in smart cities. Springer International Publishing. https://doi.org/10.1007/978-3-030-27844-1. Saghiri, A. M. (2020a). Blockchain Architecture. In S. Kim & G. C. Deka (Eds.), Advanced applications of blockchain technology (pp. 161–176). Springer. https://doi.org/10.1007/978-981-138775-3_8.

170

M. Vahdati et al.

Saghiri, A. M. (2020b). A Survey on challenges in designing cognitive engines. In 2020 6th international conference on web research (ICWR) (pp. 165–171). https://doi.org/10.1109/ICWR49 608.2020.9122273. Saghiri, A. M., HamlAbadi, K. G., & Vahdati, M. (2020). The internet of things, artificial intelligence, and blockchain: implementation perspectives. In S. Kim & G. C. Deka (Eds.), Advanced applications of blockchain technology (pp. 15–54). Springer. https://doi.org/10.1007/978-98113-8775-3_2. Saghiri, A. M., Vahdati, M., Gholizadeh, K., Meybodi, M. R., Dehghan, M., & Rashidi, H. (2018). A framework for cognitive Internet of Things based on blockchain. In 2018 4th International Conference on Web Research (ICWR) (pp. 138–143). https://doi.org/10.1109/ICWR.2018.838 7250. Schwartz, J., King, C.-C., & Yen, M.-Y. (2020). Protecting healthcare workers during the coronavirus disease 2019 (COVID-19) outbreak: Lessons From Taiwan’s severe acute respiratory syndrome response. Clinical Infectious Diseases. https://doi.org/10.1093/cid/ciaa255. SimplyVital Health. (2020). SimplyVital health|F6S. https://www.f6s.com/simplyvitalhealth. Srivastava, G., Crichigno, J., & Dhar, S. (2019). A light and secure healthcare blockchain for IoT medical devices. IEEE Canadian Conference of Electrical and Computer Engineering (CCECE), 2019, 1–5. https://doi.org/10.1109/CCECE.2019.8861593. Stark, J. (2016, June 4). Making sense of blockchain smart contracts. CoinDesk. https://www.coi ndesk.com/making-sense-smart-contracts. Szabo, N. (1996). Smart contracts: Building blocks for digital markets. Extropy, 16(18), 2. Torky, M., & Hassanien, A. E. (2020). COVID-19 blockchain framework: Innovative approach. ArXiv:2004.06081 [Cs]. https://arxiv.org/abs/2004.06081. Vahdati, M., Gholizadeh HamlAbadi, K., Saghiri, A. M., & Rashidi, H. (2018). A self-organized framework for insurance based on internet of things and blockchain. In 2018 IEEE 6th international conference on future internet of things and cloud (FiCloud) (pp. 169–175). https://doi.org/ 10.1109/FiCloud.2018.00032. Wang, S., Ouyang, L., Yuan, Y., Ni, X., Han, X., & Wang, F.-Y. (2019a). Blockchain-enabled smart contracts: Architecture, applications, and future trends. IEEE Transactions on Systems, Man, and Cybernetics: Systems, 49(11), 2266–2277. https://doi.org/10.1109/TSMC.2019.2895123. Wang, W., Hoang, D. T., Hu, P., Xiong, Z., Niyato, D., Wang, P., et al. (2019b). A survey on consensus mechanisms and mining strategy management in blockchain networks. IEEE Access, 7, 22328–22370. https://doi.org/10.1109/ACCESS.2019.2896108. Wang, Y., Samavi, R., & Sood, N. (2019c). Blockchain-based marketplace for software testing. In 2019 17th international conference on privacy, security and trust (PST) (pp. 1–3). https://doi. org/10.1109/PST47121.2019.8949025. Wang, Y., Kwong, S., Leung, H., Lu, J., Smith, M. H., Trajkovic, L., et al. (2020). Brain-inspired systems: A transdisciplinary exploration on cognitive cybernetics, humanity, and systems science toward autonomous artificial intelligence. IEEE Systems, Man, and Cybernetics Magazine, 6(1), 6–13. https://doi.org/10.1109/MSMC.2018.2889502. Xia, Q., Sifah, E. B., Asamoah, K. O., Gao, J., Du, X., & Guizani, M. (2017). MeDShare: Trust-less medical data sharing among cloud service providers via blockchain. IEEE Access, 5, 14757– 14767. https://doi.org/10.1109/ACCESS.2017.2730843. XMED Chain. (2018). MED chain (XMC) is the world 1st global medical blockchain and AI big data platform, specializing in cross-border medical solutions. https://www.accesswire.com/491 915/XMED-Chain-XMC-is-the-World-1st-Global-Medical-Blockchain-and-AI-Big-Data-Pla tform-Specializing-in-Cross-border-Medical-Solutions. Zhang, K., Vitenberg, R., & Jacobsen, H.-A. (2018). Deconstructing blockchains: Concepts, systems, and insights. In Proceedings of the 12th ACM international conference on distributed and event-based systems (pp. 187–190). https://doi.org/10.1145/3210284.3219502.

Chapter 7

Healthify: A Blockchain-Based Distributed Application for Health care Pratima Sharma, Rajni Jindal, and Malaya Dutta Borah

Abstract Blockchain technology has received significant popularity, with a growing interest in various domains, including data processing, financial services, information security, and IoT to the healthcare and medical research industries. There has also been a tremendous trend in using blockchain technologies to provide efficient data protection in health care. However, through secure and efficient data storage, blockchain turns traditional healthcare approaches into a more robust means of effective treatment and cure. In this chapter, we examine both current and latest innovations in the healthcare sector through the application of blockchain as a platform. We propose a secure distributed application called Healthify, a wide-range healthcare data protection approach focused on distributed ledger technology where medical data is encoded to provide a safer environment. The objective of this approach is to provide a practical application that offers a permanent database and offers simple accessibility to the gadgets. The application’s basis is specified by the smart contract, which provides rules and regulations for the users. Also, the architecture of the distributed application promotes the delivery of secure healthcare services within the medical system. Keywords Blockchain · Distributed application · Smart contract · Health care · Security

P. Sharma (B) · R. Jindal Department of CSE, Delhi Technological University, Delhi, India e-mail: [email protected] R. Jindal e-mail: [email protected] M. D. Borah Department of CSE, National Institute of Technology Silchar, Silchar, Assam, India e-mail: [email protected] © The Author(s), under exclusive license to Springer Nature Singapore Pte Ltd. 2021 S. Namasudra and G. C. Deka (eds.), Applications of Blockchain in Healthcare, Studies in Big Data 83, https://doi.org/10.1007/978-981-15-9547-9_7

171

172

P. Sharma et al.

7.1 Introduction Blockchain technology offers a transparent, shared, and digitized ledger that Nakamoto (2008) initially proposed. It is commonly used in transactions of cryptocurrencies, such as Bitcoin (Nakamoto 2008) and Ether (Wood 2014), while it has developed as a primary technology for more innovations in various scenarios. All the entities are identical and offer shared resources without a single failing point, thereby eliminating the possibility of central point bottlenecks. The ledger includes several transactions, which significantly increases where each block holds a preceding block hash, a nonce, a time value, and some exchanges. Nodes only approve the block if all the transactions therein are legitimate. Once a block is linked to the chain of blocks, it should not be modified under certain security assumptions. In the healthcare sector, blockchain can be applied to create secure and efficient technical systems to improve the coordination and quality of care and thus, improves the well-being of individuals and society. The healthcare system is an information-intensive medical environment where large amounts of data are routinely generated, obtained, and disseminated. Due to the sensitiveness of data and restricting factors, such as protection and privacy, storing and distributing this vast volume of data is crucial, as well as significantly challenging (Griebel et al. 2015). Secure data management is essential for diagnosis in the healthcare sector and clinical settings, as well as for integrated clinical decision-making. The practice of data management is necessary to allow healthcare practitioners to store and share their patients’ clinical data to the concerned authority for rapid follow-up. In health care, protection of secure information has been innovated in the last decade through a large number of platforms, software and communication technologies. All of them concentrate to secure healthcare records, tracking illnesses and developing chronic disease prevention strategies worldwide. Jamoom et al. (2016) have first translated the health records of paper into electronic health records (EHRs). EHRs must be regularly distributed and exchanged by various healthcare centers, doctors, nurses, healthcare professionals, health insurance companies, pharmacy manufacturers, and administration to provide a realistic way of a person’s health background to give proper and prompt treatment. In the case of a conventional client–server data management healthcare system, each hospital/healthcare center maintains its own database of medical records of sick person; the delivery of EHRs becomes a slow and costly task. Treatment of an infected person lagged if an ill person travels from one hospital to another. Also, most of the time, a sick person is required to perform multiple medical tests and cardiology treatments. Web-based health information monitoring methods (Bahga and Madisetti 2013; Fernández-Cardeñosa et al. 2012; Zangara et al. 2014) have been presented to solve the accessibility, data usage, single failure point, and security issues that exist in the client–server architecture. Patient medical information from various hospitals is saved in remote online storage, making it readily available to patients and healthcare professionals. Nevertheless, this requires doctors and healthcare centers to encode complex and personal health information of patients before storing on the

7 Healthify: A Blockchain-Based Distributed Application …

173

cloud environment (Namasudra 2018). However, cloud environment also faces data security issues (Namasudra 2019). This chapter designs an application that focused on blockchain and protects health data. In this architecture, users can upload and publish health data periodically. Doctors, patients, or health analyzers can access the data at anytime and anywhere. There is a large amount of medical information with the exponential growth of the hospital’s report. It is not sufficient to document full user information in the blockchain, as the resource requirements are extremely high for each node on the blockchain. Considering each blockchain node’s limited storage capacity, an InterPlanetary File System (IPFS) supports to share document for high integrity and durability data storage. There is no single repository in IPFS, and the information is circulated and collected in various IPFS nodes throughout the Internet. Hence, IPFS has no single failure point. Without replication, a large volume of data can effectively spread in IPFS (Nizamuddin et al. 2018). The document stored on the IPFS framework has one distinct hash sequence. In the proposed architecture, complete user health information is uploaded on the IPFS file framework. Within IPFS, the only hash sequence of medical information is saved in blockchain to check the validity of the data and to map the entire data. Healthcare architecture thus promotes the collection of large-scale health data and has excellent usability. The contributions of the chapter are given below: 1. This chapter proposes a blockchain-based distributed application for the protection of large-scale healthcare data, called Healthify. In Healthify application, clients are allowed to publish healthcare information and access treatments from doctors. In the meantime, doctors are capable of reading information from users and upload diagnosis. 2. Healthify distinguishes data publishing transactions from access control transactions. The healthcare information is encoded and processed in IPFS, which may effectively decrease the overhead of processing while maintaining the protection of healthcare data. 3. Healthify supports integrity checking and enhances security of the healthcare data.

7.2 Related Works This section discusses problems relating to conventional health data monitoring systems and blockchain-based smart healthcare systems.

7.2.1 Traditional System to Monitor Healthcare Data Collection of healthcare data is crucial to provide: better treatment, reliable detection of illnesses, health records for studying and producing successful medications,

174

P. Sharma et al.

and an appropriate prevention strategy. Today, hospitals and healthcare providers are commonly using EHRs to monitor the medical data of patients using a client–server architecture (Rind et al. 1997; Schoenberg and Safran 2000; Uckert et al. 2002; Grant et al. 2006; Gritzalis and Lambrinoudakis 2004; Bonacina et al. 2007; Ibraimi et al. 2009). But the hospitals are the primary data guardians in this form of data management system for health care. This thing makes it hard for medical practitioners to give a specific diagnosis or treatment of illness whenever necessary. It is also tough for sick persons to have a clear understanding of the health records, as their prescription data mostly found in multiple health centers. Over the past few years, researchers and organizations have created several cloud-based medical information management methods (Fernández-Cardeñosa et al. 2012; Bahga and Madisetti 2013; Zangara et al. 2014) to enable a patient to monitor their medical data from different organizations. In these schemes, however, a patient maintains essential health information in a concentrated cloud-based repository that struggles from a single failure point and makes the plan vulnerable to mistakes, cyberthreats, and leakage of data. As a consequence, the present cloud-based and client server-based health information monitoring methods are suffering from device vulnerability problems, lack of transparency, protection, and security, as noted above.

7.2.2 Blockchain-Based Smart Healthcare System Blockchain is the recent developments in computer technology. Blockchain technology offers transparent, shared, and digitized ledger. All the entities participating offer shared resources without a single failing point, thereby eliminating the possibility of central point bottlenecks. Many study results have employed the technology to fix the weaknesses in the existing EHR. Many research publications (Saravanan et al. 2017; Liang et al. 2017; Patel 2018; Juneja and Marefat 2018; Griggs et al. 2018) utilized blockchain to solve the privacy and security issues of health documents by maintaining cloud information hash within the blockchain. Nevertheless, in these works, the device is prone to a single failure point due to the cloud server. However, the solution does not address the privacy issue of the health records of patients when they contained in a centralized cloud repository. Several studies suggest that blockchain is used to maintain health information in a shared database to solve the single failing point issue. Most of these studies either introduce new data encoding/decoding techniques (Wang and Song 2018; Zhang and Poslad 2018; Badr et al. 2018), or a more modern digital signature method (Guo et al. 2018), or a protected scheme of information transmission (Zhang et al. 2016; Brogan et al. 2018), or keys generator method (Hussein et al. 2018) used by the blockchain for health information. Few studies (Azaria et al. 2016; Dagher et al. 2018; Li et al. 2018; Fan et al. 2018; Dey et al. 2017) have suggested medical information schemes that use blockchain to exchange patient medical records between various health centers. In Azaria et al. (2016), writers proposed a blockchain-based information exchange system, MedRec, that interacts

7 Healthify: A Blockchain-Based Distributed Application …

175

with the existing physician data storage solutions and allows for scalability. The application enables the physicians to share on the blockchain medical records of patients. The authors use patient information as a reward for miners, keeping the security of patient information at greater liability. The authors of Dagher et al. (2018) and Li et al. (2018) proposed a smart contract-based system for accessing health information using Ethereum. The authors of Fan et al. (2018) recommend MedBlock, a blockchain-based health information delivery scheme that provides efficient accessibility and extraction of EHRs for an authenticated network. These work (Azaria et al. 2016; Dagher et al. 2018; Li et al. 2018; Fan et al. 2018) do not permit a sick person to transfer data on their health problems and activities to the blockchain network that would help healthcare professionals strengthen their treatment and follow-up. On the other hand, the writers of Dey et al. (2017), Yue et al. (2016) suggest the need for blockchain for sharing patient information. However, it only allows medical practitioners to access the health records of patients and does not allow the professionals to disseminate the medical data of patients to the network (treatments, outcomes of labs, and medication). The authors (Uddin et al. 2018) suggest a medical data network to exchange health information between different health centers and patients through blockchain. This study permits both hospitals and physicians to upload patient health records on the blockchain network, giving a full overview of a patient’s records. Shen et al. (2019) introduce a system to use blockchain and peer-to-peer networks such as MedChain to exchange medical data. This system was designed to produce healthcare data via medical inspection and collect patient data from IoT sensors and other mobile applications. Zhang et al. (2017) addressed how blockchain-based smart contracts can resolve various healthcare concerns. They introduced some initial steps to incorporate blockchain technology for specific healthcare use cases and pointed to numerous obstacles in adopting blockchain technology. They also elaborated that creating blockchain-based applications will more effectively tackle healthcare issues.

7.3 Problem Statements Blockchain is an evolving technological innovation that can offer solutions to realworld problems, including health care perceived as one of the fundamental human rights concerns. Over the past few years, blockchain technology has acquired good faith as a modern, secure distributed network in the form of distributed ledger to conduct and store records of transactions. However, according to the healthcare perspective, the stakeholders are more interested in exploring and analyzing blockchain as a tool, instead of concentrating on the healthcare problems that blockchain may tackle. Therefore, this section outlined the significant healthcare challenges that this technology can solve and then explores potential solutions via the proposed application in further sections. Various entities are associated, including patient, doctor, and healthcare professionals. Blockchain can promote the interoperability of patient’s updated electronic medical records on a timely basis, along with

176

P. Sharma et al.

many other advantages like medical data security, patient identity safety, and care management. The critical healthcare problems that blockchain technology can tackle are described below. • Ensuring security: Ensuring data protection in health care is one of the critical issues when sharing information among different stakeholders, such as doctors, research and development units, health agencies, government sectors, and information given to their caregivers. • Ensuring the integrity of health records: Improving or preserving the high degree of data integrity is essential in health care, as these documents indicate medication, laboratory check, and significant procedure. Record errors may lead to misdiagnosis and insufficient treatment. These errors can be generated during record exchange, sharing, and storage in electronic systems. • Centralized health records: Health information is exceptionally susceptible and must be protected appropriately. A centralized cloud-based healthcare solution reveals customer privacy to commercial benefit. For example, consumers only enable authorized healthcare professionals to access their health data. Still, cloud providers may release customized EHRs from users for scientific research, medication advertising, and so on, without the customer’s consent. Where there is a diagnostic conflict, the patient can assume that the main EHRs saved in the cloud altered as third-party mistrust. • Limited access to health records: In terms of the sharing of information on health care, there is restricted access to health records to ensure security; however, this often creates obstacles in investigating the study of different conditions and the results of such medications. • Interoperability of healthcare information and requests: Interoperability problems occur when it comes to accessing, sharing, and storing healthcare applications and data. It first involves confidence building between various stakeholders and maintaining safe access and transactions. It is assumed that the blockchain is capable of overcoming these challenges. This chapter also analyzes and explains how the proposed architecture handles and provides a solution for each identified problem in the analysis section.

7.4 Background Studies This section provides an outline of blockchain technology and explains basic terms and related technologies.

7 Healthify: A Blockchain-Based Distributed Application …

177

7.4.1 Overview of Blockchain Blockchain is a distributed ledger system, operated on a peer-to-peer network by various peers (Rabah 2017; Hölbl et al. 2018; Namasudra et al. 2020). This innovation works without any centralized data storage management or central administrator (McGhin et al. 2019). Information is widely distributed across multiple nodes, and data consistency is retained by redundancy and encryption (Esposito et al. 2018; Engelhardt 2017). The idea of blockchain came into existence through a white paper, written by Nakamoto (Zyskind and Nathan 2015). The key concept was to create a trustless (Nakamoto 2008) program that uses peer-to-peer distributed ledger technology to solve the double-spending problem through a mathematical confirmation of the chronological order of transactions (Curran 2018). Blockchain refers to a chain of blocks where each block preserves a collection of data (Khatoon et al. 2019; Academy 2019). Each block plays a crucial role in communicating with the previous block, and the following block, as soon as it is a part of the chain (YliHuumo et al. 2016). Block’s principal function is to register, verify, and transmit the transactions among other blocks (James 2018). This means that it is difficult to delete or modify a block in the chain because that will change any subsequent block (Beck et al. 2017; Erik et al. 2018). Therefore, the blockchain framework is a distributed information system (Meng et al. 2018; Gipp et al. 2016) that includes details about all the previous transactions and depends on a pre-selected protocol. It defines how the transactions are handled, validated, and the working of the entire network and its members (Mehdi and Ravaud 2017). Also, this network is generally termed a distributed database, because it is saved on each node running in each of the networks (Suveen et al. 2017; Ahram et al. 2017). Using hash from the previous block record (Ovais 2017), a transaction group in blockchain networks is merged into blocks of transactions linked in the chain. Hence, the primary security feature of blockchain networks is enforced as a property of immutability (Arati 2017). As far as the block lies down the chain (the older it is), the more protected are the data contained in it from adjustments (Saberi et al. 2019). When an intruder attempts to change some of the keys, the local register will automatically cease to be valid as the hash values inside the next headers of the blocks will be entirely different depending on the hash function mechanism (Chris 2018; Florian 2017).

7.4.2 Smart Contract Smart contracts are coding functions stored on a ledger. Users can specifically call or establish smart contracts to activate any action (e.g., modifying a smart contract variable through a transaction that could trigger a confirmation response to the contract). When smart contract methods are called, each entity in the network runs the code, verifying the output against other nodes through the consensus algorithm. Subsequently, the smart function call (arguments) may be added to the blockchain as a

178

P. Sharma et al.

verification transaction. However, it is necessary to remember that the code cannot be changed once a smart contract is added to the blockchain, due to blockchain’s inherent immutability property. This immutability property means conventional methods cannot be used to update code. Additionally, approaches to updating smart contracts include using intermediate smart contracts that keep the address of the most up-todate smart contracts. Intermediate smart contracts that delegate calls pose security risks and therefore need to be carefully coded, and public lists are requiring users to check regularly to ensure they have the most up-to-date smart contract address.

7.5 Proposed Work This section presents the architecture of the proposed application for secure healthcare data management. The architecture contains the main components, such as a smart contract, IPFS storage, and distributed application, as shown in Fig. 7.1. A blockchain-based smart contract is designed to check the authenticity of the users and maintain the integrity of the healthcare data. The smart contract consists of various functions that are deployed on the blockchain network. Smart contract execution triggers automatically whenever the user initiates a request to upload/access the healthcare data to check the user’s authenticity. The healthcare data is stored in the form of blocks in the peer-to-peer IPFS storage network. The application is implemented to guarantee that anybody, including the users themselves, cannot manipulate the transactions of users. The application has three types of user transactions: data transactions, data access transactions, and validation transactions. Data transactions are used to upload healthcare data, data access transactions are used for accessing data, and validation transactions are handled to safeguard data integrity.

Fig. 7.1 Architecture of blockchain-based distributed application for healthcare

7 Healthify: A Blockchain-Based Distributed Application …

179

Figure 7.1 presents a layered architecture of the application. It describes all the entities of the application in different layers showing how the data flows through them and the functionalities of each layer. Data Collection Layer The first layer, data collection layer, consisted of different users, and the user interface of the Healthify using which the users interact with the application. Firstly, users register on the platform using a distributed application (Dapp), and his/her details are stored on the Ethereum network using the smart contract. The user receives a unique address using which the user interacts on the Dapp. Through the application portal, users may collect their health data. The users may upload the data manually or can set a time after which the data will upload. The user sends data on the Dapp, where it accumulates the healthcare data in the form of files, and the user can also visualize the data and registered doctors list. Data Processing Layer The second layer is the data processing layer. The Healthify will utilize the Ethereum platform for implementation, and the blockchain user utilizes the platform’s functionalities. The users authorize by their public addresses and digital signatures, and they are generated using their private keys, which ensure the authority. User access manages using the public–private keys of each user, and the users can access the data only according to their provided access and authority. Storage Layer The last layer is the storage layer, which consists of smart contract and IPFS storage. The smart contract provides a primary application backend that governs all tasks and authorities of the user. The smart contract is responsible for creating a record, checking integrity, transferring data, and funds between users. The smart contract uses an authentication process to ensure the accessibility of security service. It can check to see if users’ transactions are valid and legitimate. A smart contract manages the authenticity of the users by checking if the legit user is using the application. The IPFS storage layer is the layer where the individual healthcare data are stored, and the user has received a unique hash of the file. The data is encrypted using the Advanced Encryption Standard (AES) algorithm before uploading it to the IPFS storage node. The IPFS is a peer-to-peer network and security procedures to store and share information in a decentralized manner. IPFS utilizes information addressing to locate each document in a global namespace that uniquely connects all computing devices. In contrast to a central server, IPFS is developed through a distributed client–operator scheme, which holds a percentage of the aggregate information, generating a robust document processing and exchanging system. The unique file hash is stored on the Ethereum network (smart contract) to maintain the user’s record.

7.5.1 Threat Model This work assumes that a protected connection exists between the system and the user node. Doctor nodes follow the criteria strictly and honestly give the diagnoses.

180

P. Sharma et al.

User and medical professional private keys are protected in storage. The shared IPFS servers used for saving data use encryption to collect data from users and doctors safely and stably. It is believed that hospitals or a person who is not part of the network could be a malicious attacker. Intruders may imitate a customer identification, generate malicious blocks or transactions, interfere with interaction, reject operations, remove or alter transaction information. The network’s critical threat groups may be divided into four categories: threats to availability, threats to confidentiality, threats to authentication, access control, and threats to integrity. Threats to availability create problems for a ledger user to view their data, while confidentiality threats create security-related issues for a user’s healthcare data. Threats to authentication involve the imitation of a client to obtain entry to his records. Threats to integrity create problems for application users to access correct healthcare data. The discussion and explanation describe how the proposed architecture handles them in the analysis section.

7.5.2 Smart Contract Modeling A smart contract is defined as a digital contract or a computerized protocol used for the transaction to implement contract terms. It minimizes the need for intermediate trust between transacting sides and the existence of accidental or false events. The smart contract runs on every node in the network independently and automatically (Sharma et al. 2019). It depends on the information to be included in the initiating operations. The smart contract supports user registration, authentication, integrity checking functions, and it is published on the blockchain afterward. The smart contract offers various features to recognize legitimate customers effectively, efficiently, and securely. The smart contract is a safe and effective programmable asset that runs as scheduled. The blockchain also publishes all tasks conducted using the smart contract. The smart contract supports the following characteristics: (1) allowing the registration of the users, (2) allowing the uploading of healthcare data, (3) allowing the access of the stored healthcare data, (4) allowing the integrity checking of healthcare data. In a proposed architecture, the smart contract consists of various functions, as shown in Fig. 7.2 for each entity: (1) controller functions: to register a new user; (2) user node functions: to upload, access, and verify the validity of the data on request. The functions are in such a way that Healthify users can execute and get access to storage services. Figure 7.2 shows all smart contract functions deployed in Healthify for different users. This section presents sample algorithms for the registration process, sharing data, file uploading, and integrity checking services. Algorithm 1 represents the function to register the user on the application. The conditional statements check if the user is already registered as a patient (or doctor) or not; if yes, then the function reverts with an error message written after the condition. If the task is completed, it emits an event PatientAdded showing the address of the

7 Healthify: A Blockchain-Based Distributed Application …

181

Fig. 7.2 Smart contract functions

currently registered user. Similarly, the same function is designed for other users of the application. 1. Algorithm to Register a User (addPatient()) Input: Registered user address Output: Successful registration of a user 1. 2. 3. 4. 5. 6. 7. 8. 9.

if (isDoc[msg.sender] == false) Print “Address is Doctor”; end if (isPatient[msg.sender] == false) Print “Address is already Patient”; end isPatient[msg.sender] == true; allPatients.push(msg.sender); emit PatientAdded(msg.sender);

Algorithm 2 represents the file uploading function. This function is called when the user is uploading the health data on the blockchain. This function stores the IPFS hash of the encrypted file on the smart contract. The conditional statements check if the function is called by a valid user only. 2. Algorithm to Upload File (addFile (_fileHash)) Input: File Hash Output: Successful uploading (continued)

182

P. Sharma et al.

(continued) 2. Algorithm to Upload File (addFile (_fileHash)) 1. 2. 3. 4.

if (isPatient[msg.sender] == true) Print “Address is not Patient”; end PatientData[msg.sender].push(_fileHash);

Algorithm 3 function is called when the user wants to share (or send) the data to any authorized user. It shows the sample function for registered patients. This function also deducts the doctor’s fee from the patient account and reverts if the user has insufficient token balance. Similarly, the function is called by the doctor/diagnostic center to send a prescription/report to the patient. Once the prescription/report is sent, the user receives the fee which is stored in the contract. 3. Algorithm to Share File (sendFile(address_doc, _fileHash, _amount)) Input: Registered user address, File hash, Token Amount Output: Successful Sharing of File 1. if (isPatient[msg.sender] == true) 2. Print “You are not Patient”; 3. end 4. if (isDoc[_doc] == true) 5. Print “Invalid Doctor”; 6. end 7. if (_amount == docFee[_doc]) 8. Print “Insufficient fee”; 9. end 10. token.approveContract(address, msg.sender, _amount); 11. token.transferFrom(msg.sender, address, _amount); 12. docPatientList[_doc.push(msg.sender); 13. docPatient[_doc][msg.sender] = true; 14. docData[_doc][msg.sender].push(_fileHash);

Algorithm 4 function is called by different users to check the integrity of the files stored on the IPFS storage. IPFS storage shared the unique hash for each saved record. This unique hash of file is used to test the validity of the files. The smart contract to audit integrity may use the stored metadata of the files. The file hash value was registered when the file was uploaded. The user will request to access stored healthcare data to the blockchain network and then automatically execute the smart contract function. Then, after checking the user’s status, a smart contract will request a file hash from the network. After this, the smart contract selects the requested file to check the integrity by recalculating the hash and compares the new hash with the previously stored hash. If they are equal, the data integrity is safe, otherwise not. In the end, the network will return the result to the user.

7 Healthify: A Blockchain-Based Distributed Application …

183

4. Algorithm to Check Integrity (checkIntegrity(file, user)) Input: File Details Output: Checking of integrity 1. var reader = new FileReader(); 2. var r = bcrypt.hash(reader.result, salt, function(err, hash){ 3. if(err) 4. Print “err”; 5. end 6. else 7. this.setState({bcryptHash: hash}); 8. end 9. reader.readAsDataURL(f); 10. varinst = this.props.state.contract; 11. inst.methods.isUnique(this.state.bcryptHash.toString()).call().then(function(res){ 12. if(res == true) 13. Print “Integrity completed”; 14. return true; 15. end 16. else 17. return false;} 18. End

7.5.3 Conceptual Scenario This section presents a model that shows how the user interacts with the Healthify application and all processes functionalities. Firstly, users register on the platform using a Dapp, and his/her details are stored on the Ethereum network using a smart contract. The user receives a unique address using which the user interacts on the Dapp. Whenever a user wants, the user can send the data to the IPFS file storage, and in return, the user receives a unique hash corresponding to the stored file. This unique file hash is stored on the Ethereum network as well (smart contract) to maintain a record of the user. If a user wants to send his data to another user, the user can transfer the file (not actual file but only the file hash) along with the fee in the form of tokens. Once the user receives the hash of the file, she/he views the file content and can send the response to the user accordingly. The application basically would consist of four separate users. They will engage in delivering improved healthcare services through the joint use of self-monitoring and specialist consultation. The shared relationship occurs as the patient will be given the option to send the data to the doctor for review, provide feedback, and then act on his advice. The model of interaction for each user is described below. Patient Patient satisfaction is an important aspect of the medical sector and the lifeline for any health-related enterprise or initiative. Personal well-being is a concern for most of us, and that is why the need for the hour is to find the most effective ways

184

P. Sharma et al.

to improve health conditions. A distributed application is one of those tools used by one in three health-conscious individuals and ailing patients. Therefore, this work introduces the Healthify application to provide instant medical services to users. Figure 7.3a represents the stepwise overall flow of the patient in the application. Step 1: Initially, the patient must register with the application by providing various personal information, including his name, age, sex, etc., and data is stored on a

Fig. 7.3 a Flow diagram of patient. b The flow diagram of doctor. c The flow diagram of diagnostic center. d The flow diagram of healthcare analyzer

7 Healthify: A Blockchain-Based Distributed Application …

185

Fig. 7.3 (continued)

smart contract. The registration phase is compulsory until the user can use the functionalities of the software. The user then logs on using his/her specific address. Step 2: Upon logging into the application, the user has a few choices on the portal. The user can upload the health data using the portal options. Before the data uploading process, data is encrypted using the AES algorithm to provide a more secure environment. After encryption, information is divided into multiple shards and stored in the distributed platform supplied by the IPFS. In response, the user receives a unique hash corresponding to the uploaded file, which is further utilized by the user for sharing the file to the doctors or for accessing the file. The data file

186

P. Sharma et al.

for healthcare is created from the consumer’s data over a given period. After this file is submitted to the application, it will allow the applicant to continue obtaining the diagnosis/prescription from the application’s registered doctors. Step 3: The user selects the doctor from the registered doctor list and sends the individual stored health data unique hash to the doctor. When sending the request, the selected doctor’s fees deducted from the patient account and save on a smart contract. The smart contract automatically transfers the stored tokens in the doctor’s account once the patient receives the prescription. Doctor The work of a doctor is essential to every medical care process, and we include the provision in our proposal to obtain input from doctors. The patient should be able to report to the selected doctor. But this feature must depend entirely on the customer’s decision whether she/he follows the doctor’s feedback. Interaction between the patients and the doctors was a significant obstacle due to the hectic schedules and availability of physicians. It is a little inconvenient for patients to call the doctors anytime of the day, given the fact that real-time contact is highly needed for treatments and cures. The medical apps, fortunately, provide instant solutions to this issue. Medical applications are provided between healthcare providers and patients to address this challenge in the industry. Doctors are actively using digital technologies to ease their day-to-day processes and provide their patients with effective, enhanced, and improved care solutions. Therefore, the proposed application provides the interaction between the patients and the doctors to combat the issues mentioned above. Figure 7.3b represents the stepwise overall flow of the registered doctor. Step 1: The doctor registers on the application using the same procedure and then uses his unique credentials to sign in to the application. Step 2: When the doctor is logged in, she/he should be able to view a patient’s data via a user interface, which allows him/her to pick the patients. After the patient’s selection, the data should be available for the review by the doctors, except that after reviewing the patient’s information, the doctor should be able to add his/her suggestions or input. Remember that the data used for monitoring will not be editable by either the patient or the physician. Doctors are allowed to view the files using the file hash shared by the patients. Step 3: Once the doctor uploads the prescriptions, the prescription sends to the patients in the same manner, and the doctor receives his fee in the form of tokens, especially design for the proposed application. After posting the doctor’s comments, the user/patient will be able to see that once after signing in to their account. Diagnostic Center One of the most tedious tasks for everyone is receiving medical records from test centers. Adding to that was the pain of taking these reports to doctors or having immediate consultation about the same. Mobile apps make electronic monitoring of their health records simple for patients. Patients may check the reports directly from the centers, and the same can be exchanged immediately with the doctors. Therefore, no more trouble picking up files from centers or carrying them to hospitals. Thus, the proposed application allows diagnostic centers to register at the

7 Healthify: A Blockchain-Based Distributed Application …

187

portal and provide quick services to the users in a more secure manner. Figure 7.3c represents the overall flow of the registered diagnostic center. Step 1: The diagnostic center starts with the registration process and obtains unique credentials. Step 2: After logging into the system, the diagnostic may store the generated reports to the IPFS storage and obtained the unique hash of the file. Step 3: The diagnostic shares the stored report hash to the registered patients by checking the details stored on the smart contract. The diagnostic center also allows to check the integrity of the shared document and ensures security. Healthcare Analyzer Healthcare experts include a wide range of specialists and practitioners who provide some form of healthcare service, including primary care practitioners such as nurses, doctors, surgeons, physical therapists, medical laboratories, healthcare researchers, scientists, and social workers. They mostly work in hospitals, healthcare centers, and other service delivery points, but often in academic training, science, and management. Health analysts play a key and essential role in enhancing the quality of health care. Based on the primary healthcare model, they provide critical services that promote wellness, prevent diseases, and provide healthcare services to patients, families, and communities. Thus, the proposed application included the interface for healthcare analyzers to provide a medium for improving the quality of health care. Figure 7.3d shows the stepwise overall flow of healthcare analyzers. Step 1: The healthcare analyzer starts with the registration process and obtains unique credentials. Step 2: After the registration process, healthcare analyzer may utilize healthcare data to improve the quality of healthcare services, tools, medications, and diagnostic methods.

7.6 Performance Analysis In this section, we are dealing with validating Healthify efficiency and viability. The section is further split into two subparts. The first subsection presented the implementation and deployment setting of the application. In the second part, we analyze the application’s performance by using the processing time required for uploading different sized files on IPFS, the computation time needed for the completion of the transactions, and the cost incurred for the deployment of the smart contract.

7.6.1 Experimental Setup The proposed architecture implements a decentralized application that supports a blockchain network with a decentralized file system (IPFS). Ethereum framework

188

P. Sharma et al.

has been used to develop smart contracts for healthcare blockchain. This is an opensource platform and presently one of the largest public blockchain networks with an active community and a large collection of public Dapp. The Dapp can detect discrepancies, unauthorized access to the data, and missing objects. Ganache tool is used to setting up Healthify blockchain network to deploy contracts, develop Dapp, and run tests. It provides the environment to perform all the actions on the main chain. Ganache also provides ten default user accounts, each with a hundred Ether. The proposed application experimental setup consists of two parts, distributed application setup and a smart contract deployment. Thus, the implementation settings are described in two tables, respectively, to explain each part. Table 7.1 describes the development environment of a distributed application. The user interface is designed using React Native as it has excellent compatibility with the Ethereum client. Node JS is used to connect with the backend, i.e., connection with Ethereum and IPFS. The deployment settings of smart contracts are described in Table 7.2. Smart contracts are developed in Solidity language, which is the primary smart contract language for Ethereum. These are designed by using online compiler remix.ethereum. The key elements of the smart contracts are functions, events, state variables, and modifiers and are written in the Solidity programming language. The remix test network is used to deploy smart contracts on the testnet, and Ethers are utilized to pay the transaction fee. Three stages are involved in the creation of smart contracts, which use Solidity programming to write, compile, and announce. The real-time compiler Solidity creates the bytecode. Ethereum wallet is used to announce smart contracts to the blockchain. Table 7.1 Development environment for the proposed application

Table 7.2 Development environment for the blockchain smart contract

Component

Description

RAM

4 GB

Operating system

Windows 10

Server

Apache Tomcat

Frontend

React native

Backend

Node JS

Host

Infura

Encryption

AES

Data storage

InterPlanetary File System

Component

Description

RAM

4 GB

Operating system

Windows 10

Ethereum

2.0

IDE

Remix Ethereum

Programming language

Solidity

7 Healthify: A Blockchain-Based Distributed Application …

189

7.6.2 Performance Evaluation This section presents the actual results of the work to assess the output of the proposed application. Several experimental tests were performed using various parameters. The processing time would include the time to send a transaction query to access the health document and the amount of time it takes for the upload process until the user receives an acknowledgment. For this test, we used different sized health files and noted the time for each file uploading process, as shown in Table 7.3. These are approximate times, and these solely depend on the number of peers and the Internet connection speed at the moment. The proposed architecture is also evaluated for computation time required for data storage, data access, and validation transactions. The computation time is the average time taken by the proposed application to execute the series of transactions requested by the users. As shown in Fig. 7.4, the Healthify application calculated the computation time for a series of hundred transactions. A total of five hundred transactions are initiated by different users to analyze the computation time of the proposed application for different types of transactions. Table 7.3 Time required for uploading different sized files

File size (x)

Time (in s)

x < 1 MB

~0.02

1 MB < x < 10 MB

~0.1–~2

10 MB < x < 100 MB

~2–~15

100 MB < x

~15