=Paper=
{{Paper
|id=Vol-2586/paper2
|storemode=property
|title=A Minimalistic Decision Tree for Blockchain
Business Cases in Healthcare
|pdfUrl=https://ceur-ws.org/Vol-2586/paper2.pdf
|volume=Vol-2586
|authors=Fadime Kaya,Jaap Gordijn,Roel Wieringa,Georgios Koutsopoulos,Martin Henkel,Janis Stirna,Georgios Koutsopoulos,Niklas Kjellvard,Jonathan Magnusson,Jelena Zdravkovic,Nikhitha Rajashekar,Simon Hacks,Nuno Silva,Björn Skoglund,Erik Perjons,Johannes Wichmann,Monique Snoeck,Janis Stirna,Hans Weigand,Henderik A. Proper
|dblpUrl=https://dblp.org/rec/conf/ifip8-1/KayaGW19
}}
==A Minimalistic Decision Tree for Blockchain
Business Cases in Healthcare==
https://ceur-ws.org/Vol-2586/paper2.pdf
A minimalistic decision tree for blockchain
business cases in healthcare
Fadime Kaya1 , Jaap Gordijn1,2 , and Roel Wieringa2
1
Department of Computer Science, Vrije Universiteit Amsterdam, De Boelelaan
1081, 1081 HV Amsterdam, The Netherlands f.kaya,j.gordijn@vu.nl
2
The Value Engineers Soest, The Netherlands jaap,roel@thevalueengineers.nl
Abstract. Distributed Ledger Technology (DLT) is an emerging tech-
nology to remove middlemen from an eco-system. However, many DLT/BC
projects are very technologically oriented and fail to address the busi-
ness case and the re-design of its eco-system. Therefore, many DLT/BC
projects do fail. We propose a minimalistic decision tree to check whether
a business case is suitable for implementation by DLT/BC technology
and evaluate the tree in the healhtcare domain.
Keywords: Blockchain · Business case · Decision tree · Healthcare.
1 Introduction
Distributed Ledger technology (DLT) replicates data storage over a number of
actors, as opposed to storing the data centrally by an intermediate party. DLT
can be disruptive if it replaces the intermediate party, e.g. the bank in case of
the Bitcoin.
In the recent past, many companies have developed Proof-of-Concepts (POCs)
that demonstrated the use of DLT for a particular case. However, many of the
POCs end very quickly. Deloitte evaluated a large number of BC projects on
Github [6]. As of October 2017, there were 80.036 projects about BC or closely
related. Only 8% of these projects were actively maintained, and the average
lifetime of BC projects was about 1.2 years.
We argue that a DLT project should utilize a much more model-based devel-
opment process that starts with the business model (e.g. cf. e3 value [2]) of the
disruption of the eco-system. However, before embarking on such a model-based
development process, we should know which cases are worthwhile to model in
the first place. Therefore, we propose a minimalistic decision tree to evaluate
whether a particular business use case is a potential candidate for the implemen-
tation of DLT technology. Moreover, we evaluate the decision tree by assessing
a number of DLT initiatives in the healthcare sector worldwide and suggest
improvements.
This paper is structured as follows. Section 2 presents our research approach.
Concretely, the problem to be solved is how to assess a business case for appli-
cability of DLT/BC technology in a light-weight manner, which is discussed in
Copyright © 2020 for this paper by its authors. Use permitted under
Creative Commons License Attribution 4.0 International (CC BY 4.0).
2 F. Kaya et al.
Section 3. A possible solution in terms of a decision tree, which we consider as
a treatment, is introduced in Section 4. Section 5 applies the decision tree to
series of DLT/BC projects in the healthcare sector. Section 6 evaluates the us-
age of the decision tree. To conclude, Section 7 summarizes our conclusions and
suggestions for further research.
2 Research approach
We adopt the Technical Action Research (TAR) approach [8] in the context
of Design Sciences [3]. TAR consists of: (1) problem analysis, (2) treatment
design, (3) treatment, and (4) evaluation. Our problem is how to efficiently
assess a business case’s suitability for DLT/BC technology. The treatment is a
minimalistic decision tree. To assess the usability of the tree, we apply it in a
series of DLT/BC business cases in healthcare.
3 Problem analysis: Business case assessment for
blockchain
Eco-system oriented projects may consider DLT/BC technology for information
sharing. However, DLT/BC technology is an expensive solution, compared to a
centralized solution. Hence, there should be a sound business case to justify the
high costs for DLT/BC technology. The research of Deloitte [6] claims that only
a few (about 8 %) of DLT/BC projects are active after some months. We argue
that this is the case because many DLT/BC projects do not have a sound busi-
ness case. Therefore, business cases for DLT/BC technology need to be assessed
for appropriateness in an efficient way. This leads to the following research prob-
lem:
P1: How to efficiently assess a business case for the suitability of DLT/BC
technology?
4 Treatment design: A minimalistic decision tree for
BC/DLT business cases
DL and BC technology. We consider BC as an open distributed public ledger
holding a complete list of transactions that have been executed between par-
ticipating actors. A ledger can be considered as a table with tuples containing
the data; in contrast to a centralized database, this table is distributed over a
number of nodes. Formally a distributed ledger (DLT) is different from a BC, in
the sense that a BC contains the full transaction history, whereas a DLT only
contains the current world-state.
A minimalistic decision tree for blockchain business cases in healthcare 3
Properties of DLT/BC technology. We identify the most important discriminat-
ing factors of DLT/BC technology that influence decision making below, based
on [4, 1, 5].
1. Data sharing. DLT/BC systems (and database systems) support the
need to share data with a number of independent actors who need not to trust
each other. If there is no need for trusted data sharing, there is no need for
DLT/BC.
2. Multiple writers. DLT/BC systems have multiple writers.
3. Trusted parties. Essentially, DLT/BC is suitable for eco-systems with
parties who do not trust each other.
4. Immutability. Immutable data can not be changed or deleted. It can
only be created, and then exists permanently. Immutability is a property of BC
technology, not of DLT.
The outcomes of the decision tree can be threefold:
1. Centralized data store. A traditional (distributed) database technology
is sufficient, governed by only one single actor.
2. Decentralized ledge technology. Tables need to be decentralized, from
a governance point of view, but no transaction history is needed yet.
3. Blockchain technology. On top of DLT, an immutable record of trans-
actions is needed.
Related work. Several authors have provided decision trees to identify if a project
requires DLT/BC. Wüst & Gervais [9] give a decision flow of six questions. The
Linux Foundation published a list of seven somewhat different questions based
on experience with Hyperledger Fabric proof-of-concept projects [11]. Also, a
recent NIST report [10] gives a list of seven, again slightly different questions,
based on an extensive technology survey. These questionnaires focus mainly on
BC technology and do not fully take other options such as database technology
in consideration. Compared to other decision trees, we have incorporated also
other options and we chose specifically for a minimalistic approach, in order to
execute the questionnaire efficiently.
The TEAM decision tree. The decision tree in this paper is part of a larger re-
search effort, namely The Ecosystem Architecture Modeling Framework (TEAM)
[7]. The goal of TEAM is to support design of peer-to-peer eco-system design.
Fig. 1. TEAM decision tree for blockchain business cases.
4 F. Kaya et al.
Our decision tree is presented in Figure. 1. The first question checks for infor-
mation sharing between independent actors. In case of a hierarchically organized
actors in terms of governance, a centralized database hosted by one of the ac-
tors can be used. The second question concerns multiple writers. In case of just
one writing actor that actor can be responsible for the consistency of the data
and a traditional database suffices. The third question asks for the existence of
a trusted intermediate party. If this is the case, that party can host a central-
ized database. The last question is about the requirement to have an immutable
transaction log, e.g. to avoid double spending of money.
5 Treatment: Assessment of blockchain business cases in
healthcare
5.1 Treatment protocol
We apply the decision tree to six BC projects in the healthcare industry. The
treatment takes the form of an interview and has three parts: (1) pre-treatment,
(2) treatment and (3) post-treatment. The pre-treatment questions are focused
on understanding the business problem, its objectives, the blockchain case and
the positioning of the project. The treatment part is the application of the
decision tree as described in Section 4. In the post treatment part we evaluate
the recommendation of the decision tree compared to findings of the blockchain
case at hand.
5.2 Treatments
Business case A: Blood donation tracking with IOT and Blockchain
Pre-treatment. In India, the blood donation eco-system is severely disrupted and
blood is being illegally traded in black markets. Parties are seeking a DLT/BC
solution enabled by Internet of Things (IoT) tracking devices to prevent that
blood is being stolen and traded illegally. BC was selected as a technology as it
offers immutability of data, establishing trust within the healthcare eco-system
and enabling trusted data exchange. At the stage that blood donations requires
transport, it is being tracked with IoT devices; this is also logged at the BC and
at the moment that the IoT device does not follow the predetermined Global
Positioning System (GPS) route an alert is sent to the authority.
Treatment. The decision tree advised that this business case does not require BC
technology, but database technology, because it is simpler. The third question
in the decision tree ”is there a trusted intermediary? ” was answered with a yes
by the interviewee. One of the requirements of applying BC is that there is
no trust between the actors within the eco-system. However, in this case there
is an overarching trusted institution who oversees the whole blood donation
framework.
A minimalistic decision tree for blockchain business cases in healthcare 5
Post-treatment. The long term goal is to eliminate the overarching institute with
the aim to create a self governed blood donation tracking system. Therefore the
difference between the result of the decision tree and the vision in the business
case can be explained because the decision tree takes into account the current
state only, and does not include the future vision of the business case.
5.3 Business case B: Patient consent for permitting electronic
health records usage for research
Pre-treatment. The goal of this BC business case is to obtain and record consent
from the patients to collect their electronic patient health records for research
purposes. The objectives are: (1) immutability of the collected consent (2) easy
administration of consent and traceability, (4) storage of patient consent in a
trusted unified system. The patient can give consent with the purpose that re-
searchers can access the patients electronic health record for research purposes.
In the BC, the consent of the patient will be stored. Ethical data collection for
research purposes will be guaranteed by applying BC.
Treatment. The decision tree advised BC for this business case because because
this BC case requires immutability guaranteed by an algorithm and there is no
trusted intermediary to guarantee immutability.
Post-treatment. The decision tree advised to continue with the BC business case.
This corresponds with the expectations of the interviewee as it was acknowledged
again that patient consent is a crucial aspect in ethical data collection. Also since
BC creates an audit trail and trace-ability. The interviewee also commented that
the hospital is not perceived as the trusted party, since researchers from other
hospitals also request access to consented patient health records.
5.4 Business case C: Improved treatment of a brain stroke enabled
by blockchain
Pre-treatment. This business case is about people suffering from a stroke. When
a person is treated for a stroke, patient data is exchanged between multiple
(external) parties, thus confidentiality, privacy and data integrity must be guar-
anteed and here is were the BC component of this business case is integrated.
The role of BC in this business case is to provide immutable data, a clear audit
trail and authorized chain of participants in the eco-system.
Treatment. The decision tree advised that this business case should be enabled
by BC technology. One of most important requirements of this business case is
to establish trust between several actors in the eco-system. This is organized
without any intermediate party, which justifies BC technology. Furthermore im-
mutability is also a critical aspect in this business case.
6 F. Kaya et al.
Post-treatment. The decision tree advice is in line with the actual BC business
case and conform expectation of the interviewee. There is no trusted party in
this case, also it is aimed to extend this software application to other hospitals
as well. There is no central actor in this eco-system. Next to the immutability
that BC offers, it also creates a trusted audit trail and every transaction is time
stamped. The patients brain images are a mission critical aspect in this project
and that needs to be managed very carefully and BC offers the mechanism to
create an independent and trusted system.
5.5 Business case D: Patient consent documentation for clinical
trials
Pre-treatment. This case is aimed at decreasing time to market for introducing a
new medicine by supporting clinical trials for patient consent must be recorded.
The consents are stored on the BC. Additionally, every phase of the clinical trial
will be stored in the BC to ensure an unified view of the data and immutability
of data. By creating an unified system actors within the eco-system can easily
access the requested documentation.
Treatment. The decision tree advised that this business case should be supported
by BC technology in order to create a system which is chronically time-stamped
and immutable. Multiple actors are involved in clinical trials and due to this
fact a single source of truth is an important requirement for this project. Due to
the immutability element, the process of of a medicine approval can be executed
much faster.
Post-treatment. The recommendation is in line with the expectation of the inter-
viewee. It was acknowledged during the interview that by enabling BC we know
which actor wrote the data and this is a powerful mechanism to establish trust
in the eco-system. Besides, an audit trail is created and can be easily accessed
by the FDA during the audit which can contribute that a new medicine can be
approved faster.
5.6 Business case E: Motivating patients with BC technology
Pre-treatment. This business case is about sharing and collecting electronic
healthcare data. This business case objective is that patient data is recorded
in one system which can be accessed by actors within the health eco-system. In
terms of DLT, this is implemented by a permissioned ledger that stimulates pa-
tients with healthy behavior through tokens. The BC system is a self sovereigned
electronic health record where personal data, personal health information and
self reported parameters are stored.
Treatment. The decision tree advised that this project should be enabled by BC
technology. One of most important requirements of this project is establishing
trust between several actors in the eco-system and trusted transaction exchange
which can be achieved by BC technology.
A minimalistic decision tree for blockchain business cases in healthcare 7
Post-treatment. The decision tree advice is in line with the actual BC business
case. As the main reason for this project to use BC is the trust-less environment,
DB does not satisfy the requirements.
5.7 Business case F: Registering citizen consent in a trusted system
Pre-treatment. This business case focuses on private citizens in Switzerland re-
lated to giving GDPR compliant consent, more specifically about organ donation.
Treatment. The decision tree advised that this business case should be enabled
by database technology and not by a distributed ledger such as BC. This advice
by the decision tree was given due to the answer to the question ”Is there a
trusted intermediary?” This was answered by the interviewee with a ”yes”.
Post-treatment. After analysis, we conclude that the interviewee misunderstood
the question. There is a trusted set of actors, called The Foundation, who initi-
ated and governed this business case. Because of this reason, the interviewee an-
swered there is a trusted intermediate party, and due to this answer the decision
tree advice is database technology and thus no need for DLT or BC technology.
However, a running system, may have actors who are not part of The Founda-
tion, and hence may not trust each other and/or The Foundation. This justifies
the use of BC technology. If the interviewee would have respond ”no” to the in-
termediary question, he would have arrived at the question about immutability,
and hence BC technology would have been advised.
6 Treatment evaluation: A revised decision tree
For the business cases B,C,D and E, the decision tree produced the same answer
as the people executing the BC business case, regarding applicability of BC and
DLT. For business cases A and F, different answers were produced.
Observation 1. Long term vision of the business case is not included. Regarding
business case A, the discrepancy between the answer produced by the decision
tree and the people working on the business case can be explained by the fact
that the decision hierarchy does not take long-term vision into account. For this
business case it is the long term goal to create a self governed system and for
implementation purposes a central orchestrator is required. This is consistent
with experiences we have with other DLT and BC projects; a known problem
with DLT and BC business cases is often how to start these projects and with
which governance structure. Often, the long-term goal is the removal of the mid-
dleman from the eco-system and creating a self governed BC system. However,
on the short-term, the DLT and BC business cases require implementation on
a relevant platform, and to our experience, this is often done by a single enter-
prise, usually a technology provider or closely related. This is in contrast with
the underlying philosophy of DLT and BC technology namely the removal of
8 F. Kaya et al.
the middleman and creating a disruptive decentralized autonomous eco-system.
Instead of removing a middleman, a new one is introduced, more specifically the
party that builds the BC or DLT system. It is extremely difficult to build the
initial version of such a system by a network of parties (which would fit better
to the philosophy of DLT and BC technology). What should however catered
for, is a governance structure in which actors participate, in order that the DLT
or BC system can evolve into a truly decentralized eco-system.
Change 1. Emphasize that the long term vision should be used. As part of the
decision tree instruction, it should mention clearly that the long term vision
should be used while answering the questions. This eliminates the effect that
many BC projects start with a few parties only, and hence a TTP often can be
used to start the project.
Observation 2. Intermediate parties should be considered in the scope of transac-
tions. Business case F indicated that a centralized database should be selected
in favour of a DTL or BC enabled technology. The difference can be explained
by the interpretation of the context of the intermediate party. If a BC project
starts, many parties may be involved. Observation 1 already highlighted that
often a single enterprise acts as a coordinator for the process to build a BC-
enabled eco-system. In this particular instance, the eco-system was built by a
consortium called “The Foundation”. However, the actors who are part of the
initial consortium not necessarily need to coincide with the actors who do the
actual transactions.
Change 2. Intermediate party question needs to be considered in the scope of
transactions. The question about the existence of a trusted intermediate party
needs to be considered in the scope of who is doing transactions, and not in the
scope of who is building the eco-system. Hence, instruction for the decision tree
needs to mention clearly the scope.
Observation 3. Minimalistic decision tree. For business case A, the decision tree
suggest a centralized database because of the existence of a trusted intermediate
part. For the other cases B-F, the decision tree selects BC technology due to
immutability (after correcting business case F for wrong interpretation by the
interviewee).
In the six cases we have considered, we did not find the need for a central-
ized database as a result of questions, question 1: not sharing the transaction
store and question 2: single writer. Also we did not find the need for a mutable
transaction store as result of question 3: a mutable transaction store. Does that
mean that these questions can be removed from the decision tree? That would
result in a more minimalistic decision tree. We argue that this is not possible.
Question 1 (need for sharing of transaction store) functions as a kind of gate-
keeper; it prevents all single enterprise cases from further exploration. We have
not included such cases in the six business cases we have selected. As we have
not found single writer cases. Nevertheless, it is easy to think of an example, e.g.
A minimalistic decision tree for blockchain business cases in healthcare 9
a website with static pages managed by a single enterprise. In such a case, no
DLT/BC technology is needed. Also, we have not found a business case where no
transaction log is needed, but instead only the current world state. Nevertheless,
business cases can be thought of, for example voting in a community without a
central authority. This argues for keeping question 4.
7 Conclusion and further research
7.1 Conclusion
This paper proposed a minimalistic decision tree, to decide whether DLT/BC
technology is useful for a particular business case. The decision tree is based on
earlier work, but scrutinizes this work to arrive at a minimalistic tree, which is
easy and tractable to use.
The decision tree was applied to a series of six DLT/BC business cases in
the field of healthcare, in different stages of maturity, In most cases, the decision
tree selected the answer that also was chosen without the tree by the BC cases
we have discussed.
We learned that some questions need to be more precisely positioned dur-
ing the interview. Firstly, it should be made clear to the interviewees that the
question should be answered in the context of a up-an-running system with mul-
tiple parties, and not in the context of a system that yet has to be developed,
often by a single enterprise. Secondly, and related, we found that is important
to mention the interviewees that the question about intermediate parties should
be considered in the context of a running system creating transactions, and not
in the context of a consortium that builds the DLT/BC system.
7.2 Limitations
This research considers only six business cases for DLT/BC technology located in
various countries in the discipline of healthcare. More blockchain business cases
need to be tested, and it needs to be repeated in other industries, to confirm
relevance and validity. We are striving to test the decision tree in other sectors
such as trade finance, utility and supply chain.
7.3 Further research
Is the decision tree too minimalistic? A further useful distinction would be per-
missioned verus non-permissioned blockchain technology. Permissioned blockchains
are about closed consortia, whereas non-permissioned blockchains are open to
anyone (e.g. the Bitcoin). Both require different technology platforms and a dif-
ferent business model, hence it would be useful to distinguish these blockchain
types in the decision tree.
This research is part of a larger research program on a design approach for
peer-to-peer eco-systems, which can be possibly enabled by DLT/BC technology.
10 F. Kaya et al.
The proposed questionnaire is the very first step to explore business cases for
DLT/BC technology. The TEAM framework, as mentioned before, has to goal to
develop and design various eco-systems, which ultimately can be used to generate
code for DLT/BC platforms.
Acknowledgements. The authors wishes to thank Dr. Michaël Verdonck from
Ghent University, Belgium for testing the interview questions and providing
valuable feedback regarding the interview structure and the decision tree. We
would also express our gratitude to the persons who have contributed to this
research by sharing data and insights about their BC project.
References
1. Antonopoulos, A.: Mastering Bitcoin: Programming the open blockchain. O’Reilly
(2017)
2. Gordijn, J., Akkermans, H.: Value Webs - Understanding e-Business Innova-
tion. The Value Engineers (2018), https://www.thevalueengineers.nl/product-
category/publications/e3value-ref/, [Online; accessed june 15th, 2019]
3. Hevner, A., Chatterjee, S.: Design science research in information systems. In:
Design research in information systems, pp. 9–22. Springer (2010)
4. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008),
https://www.bitcoin.org/bitcoin.pdf, [Online; accessed june 15th, 2019]
5. Narayanan, A., Bonneau, J., Felten, E., Miller, A., Goldfeder, S.: Bitcoin and
Cryptocurrency Technologies: A Comprehensive Introduction. Princeton Univer-
sity Press (2016)
6. Trujillo, J.L., Fromhart, S., Srinivas, V.: Evolution of
blockchain technology - Insights from the GitHub platform.
https://www2.deloitte.com/insights/us/en/industry/financial-services/evolution-
of-blockchain-github-platform.html (2017), [Online; accessed may 17th, 2019]
7. Wieringa, R., Engelsman, W., Gordijn, J., Ionita, D.: A business ecosys-
tem architecture modeling framework. In: Proceedings of CBI 2019 (2019),
http://research.e3value.com/docs/bibtex/pdf/TEAM CBI 2019.pdf, [Online; ac-
cessed june 15th, 2019]
8. Wieringa, R.J.: Design science methodology for information systems and software
engineering. Springer (2014)
9. Wüst, K., Gervais, A.: Do you need a blockchain? 2018 Crypto Valley Conference
on Blockchain Technology (CVCBT) pp. 45–54 (2017)
10. Yaga, D., Mell, P., Roby, N., Scarfone, K.: NISTIR 8202 Blockchain Technology
Overview (2018), https://nvlpubs.nist.gov/nistpubs/ir/2018/NIST.IR.8202.pdf,
[Online; accessed june 15th, 2019]
11. Zubko, H., Bohner, T.: How Blockchain Technology Is
Disrupting The Art Economy As We Know It (2018),
https://www.hyperledger.org/blog/2018/04/19/lessons-learned-from-hyperledger-
fabric-poc-projects, [Online; accessed june 15th, 2019]