=Paper=
{{Paper
|id=Vol-3067/paper1
|storemode=property
|title= Temporal Constraints in Smart Contract-Based Process Execution: A Case Study of Organ Transfer by Healthcare Delivery Drone
|pdfUrl=https://ceur-ws.org/Vol-3067/paper1.pdf
|volume=Vol-3067
|authors=Amal Abid,Saoussen Cheikhrouhou,Slim Kallel,Mohamed Jmaiel
|dblpUrl=https://dblp.org/rec/conf/tacc/0002CKJ21
}}
== Temporal Constraints in Smart Contract-Based Process Execution: A Case Study of Organ Transfer by Healthcare Delivery Drone ==
https://ceur-ws.org/Vol-3067/paper1.pdf
Temporal Constraints in Smart Contract-Based
Process Execution: A Case Study of Organ Transfer by
Healthcare Delivery Drone
Amal Abid1 , Saoussen Cheikhrouhou1,2 , Slim Kallel1,2 and Mohamed Jmaiel1,2
1
ReDCAD, National Engineering School of Sfax, University of Sfax, Sfax, Tunisia
2
Digital Research Center of Sfax, Sfax, Tunisia
Abstract
Blockchain has emerged as one of the most promising technologies in Industry 4.0. It has the potential to
improve interorganizational processes, especially by addressing lack-of-trust issues. Recently, sophisti-
cated Blockchain-based BPM systems have been proposed to enable the execution of business processes
in the Blockchain. Despite the importance of the aspect of time in process modeling, these approaches
do not provide methods to represent nor to manage temporal constraints for business processes. This
insufficiency is due to inherent limitations of Blockchain platforms which do not offer native means
of measuring time. We have proposed an approach that enables the transformation of a large set of
temporal constraints from a business process model to a smart contract code. In this paper, we aim
to validate the feasibility and efficiency of our prior work through a case study of organ transfer by
healthcare drone delivery.
Keywords
Blockchain, BPM, Healthcare Drone Delivery, Organ Transfer, Temporal Constraints
1. Introduction
In today’s business world, organizations are likely to experience new challenges on account
of the evolution of modern technologies such as Cloud Computing, Cyber-Physical Systems,
Internet of Things, and Blockchain in Industry 4.0. Particularly, Blockchain has attracted high
interest as a distributed storage and computing technology for building the next generation of
applications. Indeed, Blockchain-based smart contracts have the potential to perform decentral-
ized, transparent, and inviolable process execution which is relevant to address lack-of-trust
issues in inter-organizational processes [1].
Some advanced work has emerged along this direction, enabling modelling and execution of
business processes (BPs) in the Blockchain [2, 3, 4]. However, these approaches usually omit
the essential aspect of time, which is of paramount importance in both process models [5]
and contractual agreements. More precisely, temporal constraints such as deadlines have
Tunisian Algerian Conference on Applied Computing (TACC 2021), December 18–20, 2021, Tabarka, Tunisia
$ amal.abid@redcad.org (A. Abid); saoussen.cheikhrouhou@redcad.org (S. Cheikhrouhou); slim.kallel@redcad.org
(S. Kallel); mohamed.jmaiel@redcad.org (M. Jmaiel)
0000-0003-0669-8406 (A. Abid); 0000-0003-4607-7452 (S. Cheikhrouhou); 0000-0002-2824-167X (S. Kallel);
0000-0002-2664-0204 (M. Jmaiel)
© 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org)
to be properly considered by different stakeholders to accomplish a common business goal.
Although process modeling languages usually offer a variety of elements to express such
temporal constraints [5], Blockchain platforms do not provide methods to represent nor to
manage temporal constraints for BPs. More specifically, transaction completion time is not fixed,
it can take from a few seconds to several minutes. This insufficiency is due to mining protocols,
inherent limitations of smart contracts, and the absence of a native means of measuring time on
common Blockchain platforms. Consequently, when executing some BP’s tasks/ activities via a
smart contract code, it does not offer any means to check whether BPs’ temporal constraints
are respected or not.
In our prior work [6], we have extended Caterpillar [2], which is an open-source blockchain-
based BPMN execution engine, to enable the transformation of a large set of temporal constraints
from a business process model to a smart contract code. This prior work is the first research
attempting to consider BPs temporal constraints in Blockchain smart contract code. However,
it lacks the validation of its feasibility and effectiveness. This paper aims to validate the prior
work through a suitable case study. We consider organ transfer by healthcare drone delivery,
which a very time-sensitive case study. All involved actors and assets such as emergency blood
supplies, vaccines, medicines, diagnostic samples, and organs, are constrained by hard timing
requirements. These requirements are of paramount importance and should be considered from
the beginning of the process modeling step. For example, the flight time is a strict requirement
for drones where a missed deadline may lead to critical situations. Statistics given in [7] show
that 20% of emergency patients’ deaths were caused by traffic jams in traditional road transport
infrastructure. Besides, drones can be preferred for medical supplies, since an ambulance drone
can perform a 93% faster response time in rural areas and 32% in urban areas than conventional
methods [8]. For organ transfer, in particular,an organ should be harvested from the donor as
soon as possible, since it become progressively less healthy over time. Therefore, the transfer
time is decisive to the success of the surgery. Moreover, about 1.5% of donor organ transfers
did not reach their target destination, and about 4% had an unexpected delay of more than two
hours, according to the United Network for Organ Sharing [9]. The proposed approach takes
properly into account a wide range of temporal constraints, reducing thus organ transfer time
to just a few minutes instead of several hours or even days.
To prove the feasibility and efficiency of the proposed approach, this paper proceeds the
following steps : (i) Modelling and configuring the business process, (ii) Generating and de-
ploying smart contracts, (iii) Creating and executing a process instance, and (iv) Evaluating the
proposed solution with respect to financial cost.
The rest of this article is organized as follows : Section 2 briefly introduces some concepts
upon which our work is built. Section 3 provides an overview of the organ transfer case
study. Section 4 illustrates the modelling and configuration of the organ transfer process.
Section 5 details process’s generation and execution. Section 6 evaluates our approach. Section 7
summarizes related work. Section 8 concludes and suggests future directions.
2. Background
This section introduces the main concepts and definitions related to Caterpillar and the Temporal
Constraints extension.
Caterpillar is a blockchain-based process execution engine that runs on top of Ethereum.
Caterpillar is mainly composed of a Compilation Tools module, an Execution Engine, and an
Execution Panel as shown in Figure 1. Caterpillar’s Execution Engine allows the deployment of
smart contracts as well as the creation and execution of process instances in the Blockchain,
while Caterpillar’s Execution Panel enables the tracking of process instances graphically.
Figure 1: Architecture of Caterpillar [2]
The “Compilation Tools” module of Caterpillar establishes a comprehensive BPMN-to-Solidity
mapping. Given a BPMN model in standard XML format, this module generates a smart contract
in Solidity, which encapsulates the workflow routing logic of the process model. Caterpillar
supports not only basic BPMN control flow elements (i.e. tasks and gateways), but also includes
advanced ones, such as subprocesses, multi-instances and event handling. However, we denote
that Caterpillar does not support temporal constraints on BPs. Consequently, the generated
smart contract code could be undetermined, and thus temporal constraints could be violated.
Our prior work [6] extends the Caterpillar compiler by several temporal constraints like duration,
temporal dependency, temporal constraint over cardinality, and start/end temporal constraints.
In order to translate BPMN model to smart contract code we must proceed with the following
mapping rules of Caterpillar. (i) Marking variable: A variable that encodes the overall distribution
of tokens across the sequence flows, (ii) Step function: A function that allows making steps
during a whole business process execution, and (iii) Bit-wise operations: Operations that are
used to ensure all the queries/updates on the process state.
To extend Caterpillar, we have proposed our mapping rule for the transformation of a BPMN
model containing Temporal Constraints to solidity code. This transformation contains a Time
variable, a Time function and a time guard to keep harmony with the mapping rules of the
Caterpillar compiler, which are detailed as follows. (i) Timer variable: When a process model
holds a timer event or an advanced temporal constraint, a corresponding variable will be
generated at the creation of the contract, (ii) Timer function: This function will be invoked
by the activity to check its conformance with its temporal constraint, (iii) Timer guard: An
extra timer guard will be generated to basically check timestamps and thus meet the timer
requirements. Figure 2 illustrates the proposed extension through an example of the duration
constraints. We refer the reader to [2, 6] for more details.
Figure 2: Temporal Constraints extension for Caterpillar
3. Organ transfer case study overview
This section presents an overview of the organ transfer case study, which implies various
safety and effectiveness considerations including medical and air traffic issues. By harnessing
a Blockchain-based infrastructure for healthcare drone delivery, the proposed approach en-
sures trusted information availability, which is crucial in both aviation processes and medical
standards. Besides, the proposed approach takes into consideration additional complexity of
rapidly evolving, sensitive, and time-critical processes as would be the case for an organ transfer
by drone. These processes include drone data recording on the Blockchain, efficient drones’
communication, and drone crash analytics (see Figure 3).
In addition, organ transfer processes imply different actors as well as various types of inter-
dependencies. Involved actors include the Air Traffic Control (ATC), the drone operator, the
drone enclosing the organ container, the organ-supplying hospital, and the receiving hospital.
Each actor requires different types of access to the Blockchain (i.e., read from the Blockchain,
write to the Blockchain, or both). The data maintained securely on the Blockchain includes the
drone’s position (e.g., course, speed, altitude, etc.), the drone’s intent (i.e., planned/ subsequent
route and altitudes), the drone’s status (e.g., fuel level or state of charge, etc.), the organ itself
(e.g., the donor’s blood type and age, time of harvesting, etc.), and the organ container on board
the drone (e.g., the container’s temperature, humidity, vibration level, etc.). Table 1 clearly
illustrates the relation between involved actors, access types and data stream.
Organ transfer processes are detailed as follows :
- Data recording on the Blockchain: An Organ delivery drone can store key sensor and
flight telemetry on the Blockchain. This data is encrypted and only available to the appropriate
actors. Using the Blockchain as a storage of all drone telemetry data, we can maintain a
chronological record of events on-chain. Hence, all authorized actors in the delivery process can
access this data. Furthermore, an organ delivery drone can only perform actions if appropriate
Table 1
Data and access types required by all actors
Data maintained on the Actors need to read some data Actors need to write some
Blockchain from the blockchain data on the blockchain
Position ATC, Operator, Receiving hospital Drone
Intent Drone, ATC Operator
Drone status Operator Drone
Organ Receiving hospital Organ-supplying hospital
Container Receiving hospital, Drone
Organ-supplying hospital,
Operator
permission is given in the form of a signature on-chain by the operator that owns it, authorizing
only that operator to control the drone.
- Secure and efficient Drones’ Communication through the Blockchain: For the
purpose of coordination, the communication with other drones can occur publicly. Here, the
Blockchain can serve as a distributed communication for drones. Other aircrafts can also
interface with the Blockchain to view the blocked/ open zones and if any issues have occured
during flights that other aircraft need to be aware of. Therefore, drones, regardless of their
operators can access a shared pool of flight and airway information on the Blockchain. This
pool of information is specific to the area in which the drone is currently operating. This allows
the drone to be aware of updated information such as telemetry and environmental conditions,
and thus can make traffic adjustments, decrease flight time and enhance the management of
temporal constraints. This would be interesting specifically in case of organ transfer.
- Drone Crash Analytics: As the number of drones flying in the skies has increased,
accidents will be inevitable. Insurance companies will need access to historical drones’ flight
data to deduce accident reasons. A drone can record all its flight details on the Blockchain,
which keeps the traceability and helps thus to track any crash or malfunction, similarly to the
blackbox on an airplane. This data can then be harnessed to enhance functionality as well as
safety in future drone deliveries.
Figure 3: Organ transfer case study overview
4. Modelling and configuration of the organ transfer process
Figure 4 shows a simplified BPMN model of the organ transfer case study. Five actors are
represented: (1) Organ-supplying hospital, (2) Drone, (3) Drone operator, (4) ATC, and (5)
Receiving hospital. Initially, the organ-supplying hospital provides some data about the organ
to transplant in order to mitigate the likelihood of medical errors at the receiving hospital. This
data includes the donor’s blood type and age as well as the time of harvesting. Besides, the
organ-supplying hospital prepares organ container requirements and requests for the drone
flight. Once the drone takes flight, it regularly sends both flight telemetry and environmental
conditions (e.g. each 5 minutes). Consequently, the drone operator decides to update the flight
path of the drone based on newly updated environmental conditions data. The drone notes the
new flight plan and adjusts flight path and altitude. Once the Air Traffic Control is aware of
the new flight path, it makes traffic adjustments accordingly. Meanwhile, the drone’s organ
container adapts its internal pressure, humidity, temperature and vibration level data when
reaching new altitudes. The drone periodically updates organ container data, allowing the
receiving hospital to monitor the health of the organ based on updated data. Afterwards, the
drone updates the time of arrival. The organ must be delivered as soon as the organ is harvested.
Otherwise, the organ health would degrade dramatically. Therefore, the drone must deliver
the organ before the deadline. If the deadline is exceeded, the drone must report the reasons
of delay to enhance future drone deliveries. Finally, once the organ is delivered, the receiving
hospital can adjust the surgery schedule according to new arrival time due to flight plan change.
Within this case study, the temporal perspective is critical since temporal constraints must
be respected. The associated temporal constraints are as follows :
• The flight time should not exceed a given deadline (e.g. 30 minutes). The drone should
deliver the organ as soon as possible while respecting a given duration (e.g. between 5
and 30 minutes), since the organ health would degrade dramatically over time.
• The duration of each synchronization task (e.g. “Send flight telemetry and environmental
conditions”, “Update organ container information”, “Update the flight path”, “Make traffic
adjustments”, “Update the arrival time”) is between 15 and 30 seconds. This duration is
affected by Blockchain congestion.
• Some activities have a recurrent behaviour that must be repeated every 5 minutes and no
more than five times. These activities include “Send flight telemetry and environmental
conditions”, “Update organ container information”, “Update the flight path”, “Make traffic
adjustments”, and “Update the arrival time”.
The “Modeling Tool” of Caterpillar is developed on top of Camunda’s BPMN modeler. To
make the models executable, some configurations should be applied. In particular, code needs
to be added such as process variable definitions, Solidity codes for script tasks, and codes
identifying the information exchange (i.e. from/to user/service tasks). For example, to indicate
that an organ-supplying hospital must provide donor’s health information via the task, a snippet
should be added in the BPMN documentation element under this task (see Listing 1). This
snippet indicates that an organ-supplying hospital must provide donor’s health information
(e.g. via a web form as shown in Figure 6b in section 5.2). The second part of the snippet is used
Figure 4: Organ Transfer Business Process Model
to generate code that copies the information into process variables. Equivalent snippets are
assigned to the remaining tasks of the process model.
1 ( b y t e s 3 2 _bloodType , u i n t 2 5 6 _age , u i n t 2 5 6 _ h a r v e s t i n g T i m e ) : ( b y t e s 3 2 bloodType ,
u i n t 2 5 6 age , u i n t 2 5 6 h a r v e s t i n g T i m e ) − > b l o o d T y p e = _ b l o o d T y p e ;
2 age = _ a g e ; _ h a r v e s t i n g T i m e = h a r v e s t i n g T i m e ; }
Listing 1: Snippet for the task “Provide donor’s health information”
5. Generation of smart contracts and execution of the organ
transfer process
This section validates the feasibility of the proposed approach. We first explain the generation
of smart contracts, and then we illustrate the creation and execution of a process instance in
the Blockchain.
5.1. Generation of smart contracts
To generate “OrganTransfer” smart contract from a BPMN model, we use the “Compilation
Tools” module of Caterpillar which establishes a comprehensive BPMN-to-Solidity mapping.
Given a BPMN model in standard XML format, this module generates a smart contract in
Solidity, which encapsulates the workflow routing logic of the process model. The proposed
temporal constraint extension allows to Caterpillar to support, in addition to basic BPMN
control flow elements (i.e. tasks and gateways), a large set of temporal constraints, such as
duration, temporal dependency, temporal constraint over cardinality, and start/end temporal
constraints. To generate smart contracts of the organ transfer case study, we need to perform
the following steps.
(i) Run Caterpillar using Glup, a toolkit that automates tasks in a development workflow
(Figure 5a).
(ii) Submit the BPMN model using a HTTP POST request on the URI “/models” with a JSON
message that includes the model name and the model serialized in the BPMN 2.0 XML
format (Figure 5c). Here, we use Postman a HTTP client that tests HTTP requests. Conse-
quently, the smart contract generation and compilation will be triggered (Figure 5b).
(iii) Enable the process to interact with external services. To do so, a corresponding smart
contract/address must have been previously registered using a HTTP POST request on
“/services”. This is required because the service’s smart contract address is compiled into
the process’s smart contract.
Listing 2 shows an excerpt of the generated OrganTransfer smart contract implementing
the duration temporal constraint. The generated smart contract of the proposed use case is
available at [10].
1 u i n t marking = 1 ;
2 uint taskTimer_duration = 0 ;
3 f u n c t i o n t a k e F l i g h t ( u i n t minTime , u i n t maxTime ) r e t u r n s ( b o o l ) {
4 u i n t l o c a l M a r k i n g = marking ;
5 u i n t s t a r t T i m e = now ;
6 i f ( localMarking & 2 != 2) return f a l s e ;
7 flight () ;
8 u n i t endTime = now ;
9 t a s k T i m e r _ d u r a t i o n = c a l c u l a t e _ d u r a t i o n ( s t a r t T i m e , endTime , minTime , maxTime ) ;
10 step ( localMarking & uint (~2) | 4) ;
11 return true ; }
Listing 2: An excerpt of the generated OrganTransfer smart contract
(a) Configuration of Organ Transfer Process (b) Compilation and generation of smart contracts
(c) Submission of the BPMN model using a HTTP POST request
Figure 5: Steps of smart contracts’ generation
5.2. Creation and execution of a process instance in the Blockchain
To execute a process instance of the “OrganTransfer” process in the Blockchain, we use Cater-
pillar’s Execution Engine. Through this Execution Engine, we can deploy the smart contract
generated by the Compilation Tools. Consequently, we can create instances of the deployed
process model, to identify enabled tasks and to control their execution. Meanwhile, executing
script tasks and triggering external service calls are performed by the Execution Engine auto-
matically. Besides, to create and track process instances graphically we can use Caterpillar’s
Execution Panel. To execute a process instance of the organ transfer case study, we need to
perform the following steps.
(i) Create a new instance using a HTTP POST request on the URI /models/:mid, where :mid
is the identifier rendered at the registration of the process model.
(ii) As a response to this request, Caterpillar will return a hyperlink as a reference to the newly
created process instance and “201” as a HTTP status. The returned hyperlink has the form
/processes/:pid, where :pid represents the Ethereum address assigned to the instance of
the process smart contract (Figure 6a).
(iii) Use the execution panel to reproduce graphically the results of the state of a process
instance and also to enable the execution of user tasks. Here, enabled tasks are displayed
in dark green, while activities in execution are depicted in light green (Figure 6b).
(iv) Execute an enabled task by clicking on it and submitting the required parameters, as
illustrated in Figure 6b. Only user tasks and catching messages are depicted in the execution
panel, because the execution of other types of BPMN elements (e.g. gateways, throwing
events, script tasks, etc.) is performed internally by Caterpillar.
(a) Creation result of the process instance (b) Enabled task execution by the Execution Panel
Figure 6: Steps of the execution of a process instance
6. Evaluation
In this section, we evaluate the proposed solution with respect to financial cost to assess its
feasibility for use within a real-world setting.
Transactions on the Ethereum Blockchain induce a certain transaction fee. Ethereum uses a
unit called gas to measure the amount of operations needed to perform a task, e.g., deploying
a smart contract or executing an ABI. It is always essential to estimate the gas costs while
developing a smart contract and so as to avoid extra charges. Fortunately, Caterpillar’s Compiler
module generates optimized smart contract codes through its mapping rules. Indeed, mapping
rules which include the marking variable, the step function, and the bit-wise operations (see
section 2), address the gas consumption cost issue and generate minimized and optimized codes.
The mapping rules of the proposed temporal constraints extension contains a time variable,
a time function and a time guard to keep harmony with the mapping rules of the Caterpillar
compiler, and thus remaining optimized for future expansion. Table 2 lists the transaction cost
for some operations including deploying smart contracts, and executing some tasks such as
“Provide donor’s health information”, “Send flight telemetry and environmental conditions”,
and “Update the arrival time”
Table 2
Operations’ Gas Cost
Operation Gas
Smart Contract Deployment 1,350,248
Provide donor’s health information 165,730
Send flight telemetry and environmental conditions 204,410
Update the arrival time 86,449
7. Related Work
Temporal constraints are a well studied topic in BPM [5]. However, prominent blockchain-
based BPM systems such as Caterpillar [2], Lorikeet [3], and other work [4] do not mention
temporal constraints at all. Some approaches are aware of time related issues and leave them
for future work [1, 11]. A limited number of work take into account temporal constraints in
blockchain-based BPM systems. Initial work have performed the simulation and prediction
of temporal aspects in blockchain-based process execution. Yasaweerasinghelage et al. [12]
use process simulation to send transactions to a private Blockchain in order to evaluate the
confirmation time as well as latency. Haarmann et al [13] estimate, through manual simulation
techniques, the total duration of choreography models in face of changing inclusion times and
block times. However, both work assume that there is a readily available measure of time and
ignore the real source of the timing information. Mavridou et al. [14] generate Solidity code from
a finite-state machine based model while taking into consideration delayed processes. However,
the latter work is still not mature enough and needs more development to cover a richer set
of temporal constraints for business processes. Recently, Ladleif et al. [15] introduce a set of
time measures available on Blockchain platforms such as block timestamp, block number, smart
contract parameter, storage oracle request-response oracle. They also provide a systematic
discussion and evaluation through important metrics like accuracy, trust, immediacy, cost,
and reliability. Finally, our prior work [6] extend Caterpillar to support the modeling and
execution of various temporal constraints for business processes such as duration, temporal
constraint over cardinality, temporal dependency and start/end temporal constraints. The
proposed implementation on Ethereum uses time-guards checking and block timestamps to
evaluate these temporal constraints. This prior work is the first research attempting to consider
BPs temporal constraints in Blockchain smart contract code. However, it lacks the validation of
its feasibility and effectiveness. The objective of this paper is to provide implementation and
technical details of a particular case study to our prior work to show its feasibility.
8. Conclusion
In this paper, we introduced a Blockchain-based case study of organ transfer by healthcare
drone delivery, which is highly time sensitive and constrained by hard timing requirements.
This case study was implemented using Caterpillar combined with our proposed extension that
enables the transformation of a large set of temporal constraints from a business process model
to a smart contract code. In future work, we plan to explore further techniques that enable time
measures in Blockchain platforms in order to accurately deal with temporal constraints. This
would improve time management in critical systems as organ delivery drones.
Acknowledgments
This work was partially supported by the LABEX-TA project MeFoGL:"Méhodes Formelles pour
le Génie Logiciel".
References
[1] I. Weber, X. Xu, R. Riveret, G. Governatori, A. Ponomarev, J. Mendling, Untrusted business
process monitoring and execution using blockchain, in: International Conference on
Business Process Management, volume 9850 of LNCS, Springer, 2016, pp. 329–347.
[2] O. López-Pintado, L. García-Bañuelos, M. Dumas, I. Weber, A. Ponomarev, Caterpillar: a
business process execution engine on the ethereum blockchain, Software: Practice and
Experience 49 (2019) 1162–1193.
[3] A. B. Tran, Q. Lu, I. Weber, Lorikeet: A model-driven engineering tool for blockchain-
based business process execution and asset management., in: International Conference on
Business Process Management (Dissertation/Demos/Industry), 2018, pp. 56–60.
[4] L. García-Bañuelos, A. Ponomarev, M. Dumas, I. Weber, Optimized execution of business
processes on blockchain, in: International Conference on Business Process Management,
volume 10445 of LNCS, Springer, 2017, pp. 130–146.
[5] S. Cheikhrouhou, S. Kallel, N. Guermouche, M. Jmaiel, The temporal perspective in
business process modeling: a survey and research challenges, Service Oriented Computing
and Applications 9 (2015) 75–85.
[6] A. Abid, S. Cheikhrouhou, M. Jmaiel, Modelling and executing time-aware processes in
trustless blockchain environment, in: International Conference on Risks and Security of
Internet and Systems, Springer, 2019, pp. 325–341.
[7] T. Nation, 20 per cent of emergency patient deaths blamed on traffic jam delays, 2019. URL:
nationthailand.com/national/30304268.
[8] M. Rucker, The potential of drones providing health services, 2020. URL: verywellhealth.
com/potential-of-drones-providing-healthservices-4018989.
[9] S. Scutti, First drone delivery of a donated kidney ends with successful transplant. cnn.,
2019. URL: cnn.com/2019/05/01/health/drone-organ-transplant-bn-trnd/index.html.
[10] SC, Organ transfer smart contract, 1. URL: github.com/amal-abid05/OrganTransfer.
[11] J. Ladleif, M. Weske, I. Weber, Modeling and enforcing blockchain-based choreographies,
in: International Conference on Business Process Management, Springer, 2019, pp. 69–85.
[12] R. Yasaweerasinghelage, M. Staples, I. Weber, Predicting latency of blockchain-based
systems using architectural modelling and simulation, in: International Conference on
Software Architecture, IEEE, 2017, pp. 253–256.
[13] S. Haarmann, Estimating the duration of blockchain-based business processes using
simulation., in: Central European Workshop on Services, 2019, pp. 24–31.
[14] A. Mavridou, A. Laszka, Designing secure ethereum smart contracts: A finite state machine
based approach, arXiv preprint arXiv:1711.09327 (2017).
[15] J. Ladleif, M. Weske, Time in blockchain-based process execution, in: International
Enterprise Distributed Object Computing Conference, IEEE, 2020, pp. 217–226.