Healthcare is presumably one of the sectors which will have the higher prospects in the near future by adopting blockchain technologies. Indeed, blockchain technologies permit to keep track of the clinical consents, plans, and protocols related to a clinical trial or examination, so to get up-to-date and tamper-proof documentation which can be shared only among the patient and the healthcare personnel which was authorized for that clinical trial or examination. Moreover, smart contracts can be deployed and executed within various phases of the above processes in order to ensure their transparency and compliance to some guidelines and/or standards. This paper presents a novel blockchain and smart contract-based architecture, designed for allowing health professionals and decision-makers to be aware of both the tasks of a health process currently carried out for the care of a patient, and the possible deviations made with respect to the planned process. In this way, it is possible not only to register in an immutable way the health and audit data related to a specific health task, but also to analyse the reasons for which some health processes were not carried out as initially scheduled.
In the last decade, the health sector has undergone intense computerization, due mainly to the
spread of always more lightweight and easily implementable ICT technologies, a better understanding
and awareness of the benefits of digitization by health operators and managers, and the availability of
suitable e-health standards and common technical specifications (like HL7 and IHE). This innovation
has promoted some important novelties, like the representation of medical data produced by
healthcare facilities into digital human- and machine-readable documents and, even more, the
systematic collection of these digital documents for creating patient Electronic Health Records
(EHRs)
The possibility to exchange health records among the numerous health information systems
involved in a health process like a care plan according to interoperable communication protocols, data
formats, and standard terminologies is concretely permitting to improve the quality of care and to
reduce medical errors and ambiguities
However, the architectural approach currently used presents several limitations in presenting
health professionals with the clinical context where the EHR data are produced. This information
would provide physicians with important knowledge about the patient, as it would allow them to
become more aware of the history of the patient-related clinical events occurred, thus not considering
the resulting health documents as silos
With the aim of reaching such an objective, health processes have to be completely and correctly
digitized
Blockchain technology is increasingly applied to many sectors, for its ability to enforce a
decentralized management through both consensus mechanisms and the immutability of data and
programs registered on distributed ledgers. Many efforts have been made so far by researchers to use
blockchain technology for facing specific health issues, like access control, secure management of
health records, and so on
Smart contracts are widely used along with blockchain technology to link the off-chain and onchain transactions, thanks to their ability to enforce the automatic execution of a contract by means of if/then conditional rules.
This paper proposes a novel architecture based on blockchain technology and smart contracts for
tracking and verifying the implementation of health processes in a way that meets the specifications
of the most recent health informatics standards, like HL7 FHIR
The rest of the paper is organized as follows. Section 2 outlines the related work, whereas Section 3 provides some background. Section 4 illustrates the proposed architecture. Section 5 shows the benefits of this novel architecture in a health scenario. Finally, Section 6 concludes the paper.
Since the launch of Bitcoin in January 2009, several variants of blockchain have been introduced
HIE goal is to allow health care providers and patients to appropriately access and securely share a patient’s vital medical information electronically, improving the speed, quality, safety and cost of patient care. Nowadays, despite the widespread availability of secure electronic data transfer, most medical information worldwide is still stored on paper - in filing cabinets at various medical offices, or in boxes and folders in patients’ homes - whilst that stored in digital form is often difficult to share among the different healthcare professionals that could be involved in a care plan provision. When the medical information related to a patient is shared between providers that usually happens by mail, fax or by patients themselves, who frequently carry their records from appointment to appointment. The above circumstances can seriously prevent the completeness of patient’s records, with a big detrimental effect on the quality of care, since past history, current medications and other information cannot be jointly reviewed during visits.
These are the reasons why our recent research in the healthcare sector has been focused in the use
of blockchain technologies to support a patient’s diagnosis, therapeutic regimen and treatment
process. Our first contribution to this topic
The relevance that transaction-oriented ledgers and smart contracts can have for the automation
and control of different processes - along with the fact that automation and control can be big drivers
of quality gains and cost reduction, holding great promise in a number of healthcare industry use
cases - is being recognized by more and more authoritative sources
In
(Zhuang, Sheets, Shae, Tsai, & Shyu, 2018) implemented a private blockchain with the goal of having timely and reliable information exchange during clinical trials, which could have multiple benefits for patients’ healthcare, such as decreasing rates of readmission, avoiding medication errors, improving diagnosis, and decreasing duplicate testing. They make use of clinical sites as “miners”, in order to perform automatic validation of blockchain integrity, whilst smart contracts are used to encode and deploy clinical trial agreements structured to reward the contribution of blockchain mining resources.
Differently than the above works, the aim of the present contribution is the automation and control of the tasks relative to health processes. In this way, it will be possible to track the process state, verify its correct implementation, and collect useful data for mining purposes.
This section provides some background information both on the main open issues and IT standards for the healthcare domain, and the main characteristics of blockchain technology and smart contracts. 3.1
In the last years, many efforts have been made for making health information systems able to
systematically collect digital health information in a structured and semantically interpretable way, by
adopting the most consolidated e-health standards and best practices
Fast Healthcare Interoperability Resources (FHIR)
The concept of blockchain was theorized as early as 1991
The business needs of healthcare ecosystems require private and permissioned blockchains: on the one hand the data processed is of a sensitive nature, on the other hand it is necessary to ensure adequate scalability in terms of system users. These users are patients and healthcare professionals who are consumers of the system, while healthcare institutions and organisations will have to manage it. Therefore, the nodes that exercise consent can be chosen according to the healthcare ecosystem of reference: departments in the case of a single hospital, hospitals in the case of health districts, etc. As for the kind of smart contracts to be implemented, the management of healthcare workflows requires a programmed logic more complex than that of cryptocurrencies: it is not enough to manage the change of ownership of an asset, but it is necessary to be able to define its life cycle through appropriate changes of state.
From the above considerations, it follows that an architecture such as the one that characterizes
Hyperledger Fabric
The aim of this contribution is to sketch an architecture where permissioned blockchain technologies support the integrity and compliance of sequences of care requests and responses carried out within a more generic and long-term healthcare workflow. In the context of resource-driven process modelling approaches like that provided through the FHIR standard, therapeutic requests and responses are resources which are created or upgraded by patients and healthcare personnel, whereas workflows are sets of resources referencing each other according to the process they implement.
Therefore, the proposed system architecture is usable by the health information systems involved in care processes, in which healthcare-related activities - instantiated, accessed and managed through appropriate resources at the application layer - have a counterpart in terms of blockchain assets in a way to keep track of their creation, upgrading and time-varying mutual relationships in the ledger. This way, the blockchain ledger, thanks to a set of suitable transactions and related smart contracts, is able to trace the lifecycle of generic healthcare workflows giving support to the integrity, monitoring and auditability of these processes at the application layer. Accordingly, the proposed system consists of Service Layer and Blockchain Layer, as shown in Figure 1, which interoperate through smart contracts and transactions involving the resources provided within a workflow. 4.1
The Service Layer includes the application components of the platform, which are in charge of: i) capturing the data produced during the execution of the various tasks of a health process, produced by authorized users and represented according to the specific data format used in the healthcare scenario (e.g. FHIR resources satisfying a specific implementation guide); ii) identifying the corresponding health process and related task with respect to the known process templates represented in OMG BPMN 2.0 standard and creating of the related transactions (named requestTask); iii) sending the requestTask transactions to the Blockchain Layer and capturing the resulting transactions (named responseTask); iv) verifying the correct execution of the process by analysing both the corresponding process template and the previous executed tasks by interacting with the Blockchain Layer; v) returning the results to the user, in terms of transactions registered on the blockchain for logging purposes and possible deviation from the planned process.
The components of the Service Layer are described below:
REST Interface: is the interface of the platform, which provides web functionalities for registering the requests on the process activities on the Blockchain Layer and replying the results of the verification of the adherence of the activity with respect to the planned process. Access Control Module: implements the authorisation phase able to grant or deny access to the platform to the requesting users, according to specific access policies.
Process Request Manager: is able to receive a request through the REST Interface, collect and organise all the information useful to identify the process to be considered as a template, and send this information to the Information Manager module.
Information Manager: manages information related to health business process templates. This module identifies the business process template to be used for verifying the compliance with the real task executed. It uses the information received from the Process Request Manager module, thanks to which the tasks are recorded at the Blockchain Layer by the activation of the creation and update transactions on the Blockchain Layer. After the registration phase, the module performs the consistency verification phase by interacting with the Workflow Verification module.
Workflow Verification: allows validating and verifying the adherence of the list of activities received in input with the process template. This module is able to request the activation of specific read transactions at the Blockchain Layer. This interaction allows the retrieval of all the activities already carried out for the specific process. This information allows the module to effectively check the adherence between the activities received in input and the process template. The result of the validation is returned in response to the REST Interface. Storage Manager: This module allows the management of the information stored in the database managed by the Resource DB module, such as the sequence of tasks for a specific health process or the required resources.
Resource DB: is a database containing the resources managed by the platform and the information about clinical business processes.
Process Template DB: is a database containing the templates of the health business processes known by the platform, formalized according to the machine-readable OMG BPMN 2.0 standard. 4.2
Tasks performed in the context of a healthcare workflow are codable through suitable data structures and their mutual relationships, whereas the workflow itself can be modelled through the changing of these data and relationships over time. For example, a large proportion of the FHIR resources are devoted to the description of activities which fall into the realm of workflow; in particular, requests and events are the two kinds of resources used to describe things that are desired to be done or that have been done, respectively. These resources are encoded as data structures that, besides their own specific records, have reference records pointing to external resources in relation to them. Since resources are already stored and managed by FHIR servers, replicating them on the Fabric ledger would only result in a harmful computational and storage overhead. Moreover, it is often the case that a FHIR resource contains many references to other resources, thus fully reproducing these interdependencies at the blockchain layer would be too complex and useless. Instead, by coding blockchain assets as the hash digests of such resources plus the set of references they contain, the ledger stores a “fingerprint” of the activities and their mutual relationships over time with integrity protection, a sort of tamper-proof acyclic graph representing what happened at the application layer. On the other hand, by querying the ledger through appropriate view masks, a human or a system can check - in terms of consistency, completeness or what else - the actions (and their concatenations) carried out at the application level. For example, it is possible to check if an order for both supply of the medication and the instructions for administration of the medicine to a patient has been fulfilled by the patient (or his/her caregiver), and when the patient actually consumed the medicine. Similarly, it is possible to check the average, minimum and maximum times for which a certain health service is provided in relation to the population of users of a given health ecosystem. The coding of blockchain assets can be implemented through the createTransaction and updateTransaction, which write on the ledger to create the hash digest and the reference list of a new instance of a resource or its update, respectively. The different view masks are instead realized thanks to a set of appropriate read operations of the data stored on the ledger, which are implemented through readTransaction_1, …, readTransaction_n (see Figure 1).
In order to achieve proper coupling of this component with the layer and application functionality
described in Section 4.1, a platform such as Hyperledger Fabric can be interfaced with mechanisms
such as the interceptors of FHIR's HAPI
This Section illustrates a case study where the proposed platform, opportunely invoked by the information systems involved in a health process, permits to i) register clinical and logs data on the process tasks performed, and ii) provides information on the implementation of the health process, by comparing the performed activity (that is, a visit or a prescription) with respect to the one scheduled. It is worth noting that the scheduled processes are preventively loaded by the competent healthcare personnel.
The scenario considered requires that in the context of a pharmaceutical prescription process, a task concerning the dispensation of a drug containing cholecalciferol has to be performed. The proposed system is in charge of registering on the blockchain the execution of this task and its validation against the template health business process. It is important to note that a deviation from the standard or planned process is not necessary a problem. However, it is relevant to provide the health professionals and decision-makers with a tool that permits them to know all the possible variations performed (in some cases due to decisions made by physicians, in other by the same patients), in order to verify if the designed processes have to be tuned.
The template health process is represented using the OMG BPMN 2.0 standard and shown in Figure 2. In the diagram, the tasks Medical consultation, Drug prescription, and Pharmaceutical dispensed have the aim of requesting the registration of the transaction on the Blockchain Layer.
There are rules associated with creating the Drug Prescription task. In this case, where a cholecalciferol is prescribed, a diagnosis of hypocalcemia is performed. This information is represented in a FHIR Observation resource associated with the task, in which the value of Vitamin D in the blood of the patient is less than a threshold.
Therefore, for the scenario under consideration, once the request for registration of the Pharmaceutical dispensed task has been carried out and the registration at the Blockchain Layer has been requested, a createTransaction is issued. This results in saving an asset on the ledger encoding the task and its mutual relationships with the assets derived from information like Patient, Prescription, Observation. After that, the verification of the adherence with the healthcare process represented in the BPMN template is initiated. Through one or more readTransaction instances, it is possible to query the ledger to retrieve the tasks already started related to that specific process, thanks to view masks obtained by querying suitable keywords (labels) in the stored assets.
Assuming therefore that the process is taking place correctly, the Drug Prescription task consistent with the Pharmaceutical dispensed and the Medical consultation tasks is retrieved. For the Drug Prescription task, it is necessary to verify that the rules related to the creation of the task are met: this happens at the Service Layer and in particular through the interaction between the Information Manager and the Workflow Verification modules. The verification permits to derive that the drug can be prescribed and that there is a data structure (represented as a FHIR Observation resource) associated to the previous Medical Consultation task - retrieved through the Blockchain Layer - with the necessary information. The scenario therefore highlights how the verification of both the sequentiality of the tasks and the presence of rules with additional information about the tasks (Observation for the Medical Consultation task) is carried out.
The sequence diagram in Figure 3 illustrates how the proposed system reacts to the registration request of the Pharmaceutical dispensed task. According to this scenario, a user sends the registration request related to the drug with cholecalciferol: the request contains information related to the identifiers for the Pharmaceutical dispensed, Patient, Prescription, as well as the FHIR Observation Resource. Considering that the user has the right to be authorised by the Access Control module, the Process Request Manager organises all the information collected, taking the information of interest from the FHIR resources and forwards it to the Information Manager module. This one carries out the registration of the task on the Blockchain Layer by providing the identifiers of the Pharmaceutical dispensed, Patient, Prescription information. Subsequently, the module identifies the template of the health business process and collects all the rules associated with it and its tasks. At this point, the Information Manager module performs a verification request to the Workflow Verification module. The Workflow module, by querying the Blockchain Layer, retrieves the tasks already registered and related to the process in question. In this case, the module gets specific tasks such as Medical consultation and Drug Prescription in response. Then, the workflow module checks the correct sequence of activities and the rules associated with the activities. In this case, after having verified the correct sequence in the activities, it must verify that the Drug Prescription activity can be created and in particular that there is a FHIR Observation resource associated with both the previous activity and the information relating to the rule to be verified. Finally, the response related to the registration and verification of adherence is provided in output to the request.
In Italy, in 2019 there were 2.2 million pharmaceutical treatments
Sketch of a possible Implementation
Figure 4 sketches a possible implementation of the proposed architecture for the given case study.
Each node represents a healthcare organization (HO) with all the actors taking part in the healthcare process, such as physicians and patients, the FHIR resources provided by the healthcare service, and the software modules that make up the proposed system. The architecture consists of server based on a REST interface and the components described in Section 4, which allow intercepting requests sent by the authorized actors to the health service in a transparent manner. In fact, patients can interact with the system by using a web portal or mobile app, whereas health professionals can also use integrated applications provided by their own health organizations or thirdparty companies.
Such applications interact with the REST interfaces for memorizing health data according to the
business processes, directly or indirectly by using mediator nodes. An enabling technology to
implement the FHIR-based information system for the Process request manager, Information Manager
and Workflow Verification components is HAPI FHIR
One possible reason to use interceptors is to perform access control. In our case, we use interceptors for capturing a request sent by a client to a server for business purposes, in order to store the most significant information contained in the message requests and responses on the blockchain in a transparent way. The information represented according to the FHIR resources is first handled by the interceptors and then by the smart contracts, that send it to the blockchain after verification. Thus, the integration of a blockchain network into IT systems used in the healthcare domain can be achieved in a non-invasive way.
As described in Section 3, a blockchain platform suitable for this case study is Hyperledger Fabric, which is used for managing and storing all the information produced by the tasks related to this scenario.
This paper has presented a system architecture composed by both application and blockchain layers, which aims at registering the different tasks executed by health professionals for the implementation of healthcare processes in a dependable way. In fact, in the healthcare sector, the planned health processes are often subject to variations. On the one hand, this is a desirable aspect, considering the dynamic nature of such processes due to the patient’s conditions. On the other hand, the health activities (prescriptions, visits, etc.) are carried out not always taking into due consideration the scheduled process. The proposed system architecture allows to the health tasks carried out to be tracked in an immutable way on a blockchain network using specific smart contracts and to verify if such activities are performed according to the planned process. To this end, an ex post verification is made, with the aim of fulfilling dynamic health needs. A case study shows how the proposed system allows the dynamism of the health processes to be handled in a non-invasive way, without causing obstacles to the execution of the tasks, but at the same time providing all the variations performed. In this way, the health decision-makers concerned have the relevant information that allows them to be aware, also through additional process mining techniques, of the real type and number of health activities carried out in a different way from what was initially foreseen. An implementation of the proposed system with the HAPI FHIR interface and HLF Java chaincode is in progress, after which a comprehensive benchmarking will be carried out. Zhuang, Y., Sheets, L., Shae, Z., Tsai, J. J., & Shyu, C.-R. (2018). Applying Blockchain Technology for Health Information Exchange and Persistent Monitoring for Clinical Trials. AMIA Annual Symposium Proceedings (p. 1167). American Medical Informatics Association.