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) (Gopal, Suter-Crazzolara, Toldo, & Eberhardt, 2019).
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 (Fidopiastis, Venta, Baker, & Stanney, 2018).
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 (Hasselgren, Kralevska, Gligoroski, Pedersen, & Faxvaag, 2020).
With the aim of reaching such an objective, health processes have to be completely and correctly digitized (Russo, Ciampi, & Esposito, 2015). as workflows of planned tasks, some executed sequentially and others in parallel. Monitoring the correct execution of the designed processes, registering all the digital clinical information produced at each task, as well as capturing data linking the several tasks, would avoid losing contextual data. For this purpose, it is important to gather not only business data, but also capturing the event logs produced by the information systems that are involved in the execution of the various tasks of a healthcare process. This indeed facilitates data mining activities, which can reconstruct the actual healthcare process by analysing audit logs. In particular, analysts can detect gaps between planned and actual tasks, so to achieve improvements in healthcare processes. (Fox, Aggarwal, Whelton, & Jhonson, 2018).
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 (Bittins, et al., 2021).
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 (HL7 International, 2021). More in detail, the proposed architecture permits to automate and control tasks to be executed in dynamic health processes, in order to make possible the verification of their correct implementation, the state management, as well as the capture of business and security data usable for process mining purposes. The paper shows an effective use of the proposed architecture in a health case study.
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 (Belotti, Božić, Pujolle, & Secci, 2019), and many academic and industry works concerning blockchain technologies and their applications have been performed in various sectors besides Fintech. Healthcare and the supply-chain industry are probably the two other sectors which have received the higher prospects and attention so far. A recent systematic review concerning frameworks, prototypes and implementations of blockchain systems in the healthcare sector (Chukwu & Garg, 2020) has identified a total of 143 scholar contributions from January 2010 to May 2019, with the first contribution published in 2015 and the highest number of publications (86) being in 2018. Among these contributions, 82 (57%) are papers proposing new concepts, models or frameworks; 54 (38%) are works discussing workbench tests either through a simulation software or by configuring the system in a laboratory environment; whilst 7 (5%) papers discuss real-life implementation, pilot testing or evaluation of an implementation. From a different perspective, a global analysis of current commercial deployments, major industry collaboration on pilot projects, and funding trends (Frost & Sullivan, 2019) 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 (Ciampi, Esposito, Marangio, Schmid, & Sicuranza, A blockchain architecture for the Italian EHR system, 2019) was a blockchain architecture designed for facing the integrity and traceability issues concerning the current national EHR framework for the interoperability of the regional systems in Italy. This work was further extended in (Ciampi, Esposito, Marangio, Schmid, & Sicuranza, Integrating Blockchain Technologies with the Italian EHR Services, 2020), where the implementation of a prototypical permissioned blockchain was described. The proposed network was designed to operate synergically with the federated EHR Italian system, so to support its information exchanges and to easily and effectively control its operation in a verifiable and correct manner. Finally, with a view to supporting and monitoring the health process itself rather than controlling the interactions between different systems archiving health-related information, an approach for the integration of a blockchain platform with some of the services and resources considered by the IHE Dynamic Care Profile was provided (Ciampi, Esposito, Marangio, Schmid, & Sicuranza, Modernizing Healthcare by Using Blockchain, 2021).
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 (The European Union Blockchain Observatory & Forum, 2020). However, to the best of our knowledge there is not a relevant body of work from the scientific community on these topics. The rest of this section discusses some previous contributions having some relevance with respect to the above issues and our approach.
In (Wang, et al., 2018), blockchain technology is used to support a parallel healthcare system (PHS) framework through the construction of a consortium linking patients, hospitals, health bureaus, and healthcare communities for comprehensive healthcare data sharing, medical records review, and care auditability. The PHS uses artificial healthcare systems to model and represent patients' conditions, diagnosis, and treatment process, applies computational experiments to analyse and evaluate various therapeutic regimens, and then implements parallel execution for decision-making support and real-time optimization in both actual and artificial healthcare processes. (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. (Alomi, et al., 2017) presented a tele-monitoring healthcare framework for the diagnosis and treatment of cancer tumours for remote patients, utilizing smart contracts and blockchains to ensure the validity and security of the patient's data at specialized medical centres and in-patient homes. (Mannaro, Baralla, Pinna, & Ibba, 2018) designed a blockchain-based e-health platform within the DermoNet project, whose goal is to provide dermatological services directly by the general practitioner with the purpose of virtually shortening the distances between patients and dermatologists. Within that scope, the authors' intent was to allow patients to bypass the general practitioner and self-manage their own medical records. (Griggs, et al., 2018) proposed blockchain-based smart contracts to perform real-time analysis and log transaction metadata for medical sensors in a wireless body area network. The smart contracts evaluate information collected by a patient's IoT healthcare device based on customized threshold values, triggering alerts for the patient and healthcare providers as appropriate, as well as recording details about the transaction on the blockchain for verification of EHRs.
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.
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 (Chiaravalloti, et al., 2015). To this aim, technical specifications produced by international Standards Developing Organizations have been localized so that the digital health data are represented in such a way as to guarantee both syntactic (i.e. respecting common data structures) and semantic (i.e. using shared terminology coding systems) interoperability. However, the solutions currently available have several limitations, as they have not been designed to consider the health processes within which such data are produced, thus not allowing healthcare professionals to be aware of the contextual data produced during the exams carried out by their own patients.
Fast Healthcare Interoperability Resources (FHIR) (HAPI FHIR, 2021), the last standard produced by HL7, is spreading worldwide as it permits not only to represent digital health data in easily exchangeable ways, but also to link such data among them. It was built with the aim of simplifying implementation by using an incremental and iterative approach. Although it is not compatible with the previous HL7 Version 2 and Version 3, several mappings are provided. The FHIR specification is based on the modern architecture styles and open Internet standards like Resource-Oriented Architecture and REST. According to such paradigms and technologies, FHIR defines the key health entities as "resources", which are a collection of information models specifying data elements, constraints and relationships for the "business objects". All the resources are defined in the standard specification. The last stable FHIR specification is based on the FHIR Composition Framework that currently includes 145 resource types covering many clinical and administrative concepts of the healthcare sector. Each resource type permits to represent a number of properties related to a specific concept. In order to facilitate a homogeneous representation of the data into these resources, the FHIR specification provides a concrete formalization of them in three different data formats: XML, JSON, and TTL. An important component of the FHIR specification is represented by the RESTful APIs, which are a collection of well-defined interfaces for making different applications able to interoperate. Definitely, the FHIR specification is a platform specification: to implement a FHIR-based solution for a specific subdomain of healthcare, able to consider different regulations, requirements, etc., the FHIR specification requires further adaptations. These ones, typically specified in Implementation Guides (IGs), include a localization of the particular standard resource elements that are used, possible additional elements, the APIs and terminologies to use, and so on.
The concept of blockchain was theorized as early as 1991 (Haber & Stornetta, 1991), but the first application was in 2008 regarding the use for the cryptocurrency BitCoin (Nakamoto, 2009). Blockchain belongs to the family of distributed ledgers, which are replicated and synchronised on multiple parties without the support of a central control authority: a consensus protocol ensures the agreement of all parties on the state of the ledger. The state changes are proposed to the system through transactions, sent by the network participants. In a blockchain, transactions are stored in blocks, and each block contains the hash of the previous block, this results in a time-oriented, tamperproof database linking all transactions. In permissionless blockchains like Bitcoin and Ethereum, anyone can connect to the network anonymously and participate in the consensus, which has to face sybil attacks (Douceur, 2002) thanks to Proof-of-X algorithms (Xiao, Zhang, Lou, & Hoy, 2020), which can be expensive in terms of resources and with poor performance. In permissioned blockchain, instead, the ledger is managed by a small number of parties with a bond of trust, and consensus can be reached through efficient Byzantine fault tolerant (BFT) protocols (Xiao, Zhang, Lou, & Hoy, 2020). A blockchain of permissioned type turns out to be suitable for situations in which more companies go to merge in so-called consortia so that the decentralization and security of the blockchain are integrated with business needs. Blockchains can also be classified as public or private depending on the fact that transactions can be read by anyone or authorized users. Smart contracts (Szabo, 1997) are pieces of code containing instructions that are executed when certain circumstances are met, and are key elements in a business-oriented blockchain network, where they are used to define the life cycle of the assets managed through the network. A smart contract encodes indeed the logic of transactions that manage a specific asset in the network, so that they can be launched not only by human actors but also by equipment and sensors, going to automate in a safe and traceable way a multiplicity of processes.
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 (Hyperledger Fabric, 2020) is able to meet all the previous requirements. It also has adequate performance for the application domain considered. (Wang & Chu, 2021) have measured throughput on the order of 3,000 transactions per second, where each transaction requires 2 write and 2 read low-level operations. On the other hand, as shown in Section 5, current statistics for the given case study result in less than one transaction per second.
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.
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.
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 (HAPI FHIR, 2021). Thus, extending the architecture proposed in (Ciampi, Esposito, Marangio, Schmid, & Sicuranza, Modernizing Healthcare by Using Blockchain, 2021), 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.
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 (AIFA, 2019) , of which 72% served by the national health service (SSN). We can estimate that on average these represent of about 5,000 pharmaceutical prescription processes per day. Managing digital pharmaceutical processes in Italy, currently means managing about 500 prescription processes every hour. For the case study represented in Figure 2, each process requires 3 transactions, each one consisting of about 2 write and 2 read low-level operations. According to (Nakaike, Zhang, Ueda, Inagaki, & Ohara, 2020), an optimized Hyperledger Fabric implementation can sustain more than 3,000 of such transactions per second, which is more than 3,000 times the current load. 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 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 (HAPI FHIR, 2021), a framework that implements the FHIR standard aligned with the last version of its the standard specification. This framework provides an important feature, namely the interceptor, which permits to "catch and handle" a request sent from a client to a server.
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.