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]