Building Continents of Knowledge in Oceans of Data: The Future of Co-Created eHealth 401 A. Ugon et al. (Eds.) © 2018 European Federation for Medical Informatics (EFMI) and IOS Press. This article is published online with Open Access by IOS Press and distributed under the terms of the Creative Commons Attribution Non-Commercial License 4.0 (CC BY-NC 4.0). doi:10.3233/978-1-61499-852-5-401 Architecture and Initial Development of a Knowledge-as-a-Service Activator for Computable Knowledge Objects for Health

Allen J FLYNNa,b 1, Peter BOISVERTb, Nate GITTLENb, Colin GROSSb, Brad IOTTa, Carl LAGOZEa, George MENGa, and Charles P FRIEDMANa,b,c a School of Information, b Medical School Department of Learning Health Sciences, and, c School of Public Health at the University of Michigan

Abstract. The Knowledge Grid (KGrid) is a research and development program toward infrastructure capable of greatly decreasing latency between the publication of new biomedical knowledge and its widespread uptake into practice. KGrid comprises digital knowledge objects, an online Library to store them, and an Activator that uses them to provide Knowledge-as-a-Service (KaaS). KGrid’s Activator enables computable biomedical knowledge, held in knowledge objects, to be rapidly deployed at -scale in environments for improved health. Here we present the Activator, its system architecture and primary functions.

Keywords. Knowledge Objects, Digital Library, Activator, Knowledge Management, Knowledge , Learning Health System, eHealth

1. Introduction

This work addresses the latency between biomedical knowledge discovery and its widespread uptake into practice [1]. We believe fully computable (i.e., computer- actionable) biomedical knowledge is needed to achieve Learning Health System (LHSs) [2, 3]. Without it, inadequate health care outcomes will persist because slow dissemination of human-readable knowledge thwarts rapid, system-wide learning [1, 4]. In 1999, Cheah and Abidi discussed the growing significance of Knowledge Management (KM) in healthcare [5]. They described a 7-part KM framework [6], including a “Share/Disseminate” process to move previously stored knowledge throughout the health care enterprise [5]. Since that time, to help share and disseminate knowledge, cloud computing architectures have emerged that enable persistent, online Knowledge-as-a-Service (KaaS) [7]. KaaS combines computable knowledge and data in a cloud environment to generate advice on-demand [8]. However, before KaaS platforms can enable scalable sharing of routinely updated computable biomedical knowledge for LHSs, they must meet healthcare’s security, reliability, data format, and other requirements [9]. KaaS platforms that meet these requirements may help overcome longstanding problems with interoperability and computable knowledge sharing [9].

1 Allen J. Flynn, Department of Learning Health Sciences of the Medical School, University of Michigan, 300 North Ingalls Building, 1161C, Ann Arbor, Michigan, USA, 48109; E-mail: [email protected] 402 A.J. Flynn et al. / Architecture and Initial Development of a Knowledge-as-a-Service Activator

The Knowledge Grid (KGrid, www.kgrid.org), a computable biomedical knowledge platform under development at the University of Michigan, includes digital knowledge objects (KOs) that follow a published formal specification [10], a digital library within which to manage and steward KOs [11], and an Activator capable of being deployed in cloud environments to provide KO-based KaaS. The Activator is so named because it puts computable biomedical knowledge stored in Knowledge Objects to work via online webservices, thereby activating it. The Activator enables realization and scaling of biomedical KaaS. This paper describes the system architecture of the KGrid Activator, which has been realized over 9 months of software development using Agile methods.

2. Research Question

The research question motivating the initial work to design and develop KaaS capabilities for the Knowledge Grid -- in the form of its Activator -- is this: What constitutes a minimum set of necessary and sufficient logical-technical components that, when integrated, result in stable, scalable, rapidly deployable, secure, traceable, activated Knowledge Objects thereby enabling KGrid to provide performant, reliable on-demand knowledge services for health using cloud computing environments?

3. Materials and Methods

To create an encompassing architecture for the KGrid Activator, one that delineates a set of necessary logical-technical components and is extensible, we analyzed various cloud computing architectures [7-9] and studied the differences between a Remote Procedure Call (RPC), Remote Method Invocation (RMI), and the network-based RESTful architectural pattern for a stateless, scalable, generic networked interface with HTTP- based semantics (i.e., GET, PUT, POST, etc.) [12]. A logical-technical component is a single part of the system architecture that can be implemented by technical means. The KGrid Activator is an independent component built with the Spring Framework for Java [13]. Using Spring’s Web module, and Maven for Java project build automation, we have built the Activator by combining a series of interdependent Java classes and object instances to bring about Knowledge Object based end-user KaaS capabilities. We have successfully deployed the Activator on Cloud and . The KGrid Library works in conjunction with the Activator. The Library’s system architecture has been previously published [11]. Fedora, version 4.x, provides KGrid’s Library with a repository for native Resource Description Framework (RDF) linked data and binary files [14]. Via the Library’s application programming interfaces (), it receives requests from the Activator for specific KOs, serializes KOs in JavaScript Object Notation (JSON), and delivers them to the Activator, which enables KaaS. Knowledge Objects (KOs), each hold a computable biomedical knowledge payload along with service-interface specifications and descriptive metadata [10]. Payloads can include computer-actionable statistical prediction models and computable guidelines. As a specific example, we have created a KO that holds executable pharmacogenomic drug dosing knowledge. When activated, this KO provides genetic information to compute dosing advice. Using such executable payloads, the Activator provides persistent online KaaS to compute predictive scores and case-specific guideline-based advice on demand. A.J. Flynn et al. / Architecture and Initial Development of a Knowledge-as-a-Service Activator 403 4. Results

4.1 Functional Requirements

The two basic KaaS functions are (1) to enable use of computable knowledge downstream by disseminating knowledge resources in digital formats “as is” and (2) to apply computable knowledge, as part of the service, by accepting instance data as input, combining those data with computable knowledge, performing an execution step, and returning a computed result as new information to answer a question [7-9]. The Activator can perform both of these KaaS functions. It can either share a KO payload directly with a requestor, for computation external to KGrid, or it can process instance data, using one or more KO payloads, to generate an answer for the requestor automatically. In addition, in our work to design and develop KGrid’s Activator, we are evolving a specific model of computable biomedical knowledge activation to extend the two most basic functions of KaaS by including several other functions we believe are minimally necessary to deploy computable biomedical knowledge safely, effectively, and efficiently to improve health. These other activation-related functions are access control, knowledge object integrity checking, activation policy setting, activation policy enforcement, and knowledge object utilization logging. A system architecture for a KaaS Activator is shown in Figure 1.

Figure 1. System Architecture of a KaaS Activator for Computable Knowledge Objects for Health

4.2 Payload Agnostic Activator Functions

KGrid’s Activator provides access controls for all users. It also provides several functions to Knowledge Management Administrators via APIs. These general functions 404 A.J. Flynn et al. / Architecture and Initial Development of a Knowledge-as-a-Service Activator are not KO payload specific, but instead are payload agnostic Activator functions. These payload agnostic Activator functions are associated with the four APIs depicted to the left of the vertical dashed orange line in Figure 1. The Shelf API enables users to load and unload knowledge objects (KOs) into and out of the Activator, respectively. The Activator maintains a persistent KO Shelf, which is currently implemented as a simple dedicated file folder. The Policy API enables users set, edit, remove, and apply policies to govern aspects loading KOs and providing KaaS using them. For example, the Policy API can enforce a rule that only KOs from certain trusted sources can be loaded into the Activator. The Logging API provides users with a mechanism to collect knowledge service utilization data. If logging is turned on within the Activator, a new data stream is implemented and log data are stored outside of the Activator in a separate data store. The Adapter API enables sharing and use of KO payloads. An Adapter is a plug-in that enables the Activator to meet the two basic types of KaaS service requests. The Adapter API allows users to plug one or more Adapters in to an Activator instance. Four specific Adapters are shown in Figure 1. The simplest one is the Share Payload Adapter that sends the payload of a KO out to an external system upon request. Local Execute Adapters are software language-specific. When they are plugged-in, various Local Execute Adapters enable the Activator to execute Python, JavaScript, and code in other languages. In a similar way, Proxy Execute Adapters engage external services to execute code in various languages. Finally, Workflow Adapters provide the Activator with a mechanism to orchestrate execution of the multiple KO payloads in repeatable ways. One set of functions that are not controlled by an API are the internal Checking functions of the Activator. For safety and security, the Activator has the capabilities to check the integrity of any KO, using various fixity and checksum routines. The Activator can also check that incoming instance data are a match for any KO’s service interface.

4.3 Payload Specific Activator Functions

The Activator’s KO enabled, payload-specific KaaS capabilities are made available via its Activation API, which is directly supported by a series of logical-technical components that extend to the right of the dashed orange line in Figure 1. When a standard HTTP request (i.e., GET, PUT, POST, etc.) is received by the Activator’s RESTful Activation API, that request is handled by the Knowledge Object Service Model layer. If the needed KO is already on the Activator’s Shelf, and the needed Adapter to provide the requested service is already plugged into the Activator, then the Checking functions are performed and, if all checks are passed, the request is fulfilled. If the needed KO is not on the Shelf, then the Activator can automatically initiate a search for the KO at the KGrid Library to which it is connected (Three KOs are depicted on the Shelf in Figure 1 and many more can be added). The Activation API provides a set of error responses and troubleshooting support whenever a KaaS request cannot be fulfilled.

5. Discussion

We have described the logical technical components of the KGrid Activator and their core functions. Our work is informed by efforts to make and share complex compound digital objects in other domains but it specifically advances KaaS functions for LHSs. A.J. Flynn et al. / Architecture and Initial Development of a Knowledge-as-a-Service Activator 405 6. Conclusion

Much better knowledge dissemination is needed to establish LHSs [1-3]. Cloud-based KaaS has the potential to improve knowledge dissemination for health. However, most commercial KaaS platforms have not been purpose-built for health care. They do not provide needed security, knowledge integrity checking, and technical policies to safely and effectively deploy computable biomedical knowledge [5,7]. A system architecture for a KaaS Activator with the potential to support KaaS for health has been reviewed. It exhibits capabilities to make KaaS a more feasible infrastructural solution for LHSs.

References

[1] Z. S. Morris, S. Wooding, and J. Grant, The answer is 17 years, what is the question: understanding time lags in translational research., J Royal Soc. Med 104.12 (2011), 510–520. [2] C. P. Friedman, J. C. Rubin, and K. J. Sullivan. Toward an information infrastructure for Global Health Improvement. Yearbook of Medical Informatics 26.01 (2017), 16-23. [3] C. P. Friedman, J. C. Rubin, J. Brown, M. Buntin, M. Corn, L. Etheredge, C. Gunter, M. Musen, M., R. Platt, W. Stead, and K. Sullivan, Toward a science of learning systems: a research agenda for the high- functioning Learning Health System. Journal of the American Medical Informatics Association 22.1 (2014), 43-50. [4] E. A. McGlynn, S. M. Asch, J. Adams, J. Keesey, J. Hicks, A. DeCristofaro, and E. A. Kerr, The quality of health care delivered to adults in the United States. New England journal of Medicine 348.26 (2003), 2635-2645. [5] Y. Cheah and S.S.R. Abidi, Healthcare Knowledge Management Through Building and Operationalising Healthcare Enterprise Memory, Medical informatics in Europe (1999), 726-730. [6] C. O’Dell, C.J. Grayson, If We Only Knew What We Know: Identification and Transfer of Internal Best Practices, Best Practices White Paper, American Productivity & Quality Center, 1997. [7] R. Abdullah, Rusli, Z. D. Eri, and A. M. Talib. A model of knowledge management system for facilitating knowledge as a service (KaaS) in cloud computing environment. Research and Innovation in Information Systems (ICRIIS), 2011. [8] K. Grolinger, M.A. Capretz, E. Mezghani, and E. Exposito, Knowledge as a service framework for disaster data management. IEEE 22nd International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (2013), 313-318. [9] A. Ryan, and P. W. Eklund, The health service bus: An architecture and case study in achieving interoperability in healthcare. MEDINFO 2010, 2010, 922-926. [10] A. Flynn, C. P. Friedman, P. Boisvert, Z. Landis-Lewis, C. Lagoze Knowledge Object Reference Ontology, http://bioportal.bioontology.org/ontologies/KORO, NCBI, Accessed February 4, 2018. [11] A.J. Flynn, N. Bahulekar, P. Boisvert, C. Lagoze, G. Meng, J. Rampton, and C.P. Friedman. Architecture and Initial Development of a Digital Library Platform for Computable Knowledge Objects for Health. Stud Health Technol Inform. 235 (2017); 496-500. [12] R. T. Fielding and R. N. Taylor. Architectural styles and the design of network-based software architectures. Doctoral dissertation: University of California, Irvine, 2000. [13] R. Johnson et al. The spring framework–reference documentation. Interface 21 2004, accessed on October 22, 2017 at https://docs.spring.io/autorepo/docs/spring-framework/3.2.17.RELEASE/spring- framework-reference/pdf/spring-framework-reference.pdf. [14] C. Lagoze, S. Payette, E. Shin, and C. Wilper, Fedora: an architecture for complex objects and their relationships, Int. J. Digit. Libr. 6.2 (2006), 124–138.