Distributed Ledger Technology (DLT) is an emerging technology to remove middlemen from an eco-system. However, many DLT/BC projects are very technologically oriented and fail to address the business 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.
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 [
We argue that a DLT project should utilize a much more model-based
development process that starts with the business model (e.g. cf. e3value [
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 applicability 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).
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 usage of the decision tree. To conclude, Section 7 summarizes our conclusions and suggestions for further research. 2
We adopt the Technical Action Research (TAR) approach [
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 [
DL and BC technology. We consider BC as an open distributed public ledger
holding a complete list of transactions that have been executed between
participating 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 di erent from a BC, in
the sense that a BC contains the full transaction history, whereas a DLT only
contains the current world-state.
Properties of DLT/BC technology. We identify the most important
discriminating factors of DLT/BC technology that in uence decision making below, based
on [
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 su cient, 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 transactions is needed.
Related work. Several authors have provided decision trees to identify if a project
requires DLT/BC. Wust & Gervais [
The TEAM decision tree. The decision tree in this paper is part of a larger
research e ort, namely The Ecosystem Architecture Modeling Framework (TEAM)
[
Our decision tree is presented in Figure. 1. The rst question checks for information sharing between independent actors. In case of a hierarchically organized actors in terms of governance, a centralized database hosted by one of the actors 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 su ces. The third question asks for the existence of a trusted intermediate party. If this is the case, that party can host a centralized database. The last question is about the requirement to have an immutable transaction log, e.g. to avoid double spending of money. 5
5.1
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 ndings of the blockchain case at hand. 5.2
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 o ers 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. 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 di erence 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
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 uni ed system. The patient can give consent with the purpose that researchers 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
Pre-treatment. This business case is about people su ering from a stroke. When a person is treated for a stroke, patient data is exchanged between multiple (external) parties, thus con dentiality, privacy and data integrity must be guaranteed 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 justi es BC technology. Furthermore immutability is also a critical aspect in this business case.
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 o ers, 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 o ers the mechanism to create an independent and trusted system. 5.5
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 uni ed view of the data and immutability of data. By creating an uni ed 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 interviewee. 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
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 patients 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. 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
Pre-treatment. This business case focuses on private citizens in Switzerland related to giving GDPR compliant consent, more speci cally 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 initiated and governed this business case. Because of this reason, the interviewee answered 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 Foundation, and hence may not trust each other and/or The Foundation. This justi es the use of BC technology. If the interviewee would have respond "no" to the intermediary question, he would have arrived at the question about immutability, and hence BC technology would have been advised. 6
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, di erent 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 middleman 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 enterprise, usually a technology provider or closely related. This is in contrast with the underlying philosophy of DLT and BC technology namely the removal of the middleman and creating a disruptive decentralized autonomous eco-system. Instead of removing a middleman, a new one is introduced, more speci cally the party that builds the BC or DLT system. It is extremely di cult to build the initial version of such a system by a network of parties (which would t 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 e ect 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 transactions. Business case F indicated that a centralized database should be selected in favour of a DTL or BC enabled technology. The di erence 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 BCenabled 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 nd the need for a centralized database as a result of questions, question 1: not sharing the transaction store and question 2: single writer. Also we did not nd 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 gatekeeper; 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 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 7.1
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 eld of healthcare, in di erent 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 during 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 multiple 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
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 con rm relevance and validity. We are striving to test the decision tree in other sectors such as trade nance, utility and supply chain. 7.3
Is the decision tree too minimalistic? A further useful distinction would be permissioned 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 di erent technology platforms and a different 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.
The proposed questionnaire is the very rst 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. Michael 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.