Brazilian Journal of Biological Sciences, 2018, v. 5, No. 9, p. 3-12. ISSN 2358-2731 https://doi.org/10.21472/bjbs.050901
H-KaaS: A Knowledge-as-a-Service architecture for E-health
Renan G. Barreto¹, Lucas Aversari¹, Cecília Neta A. P. Gomes² and Natasha C. Q. Lino¹
¹Universidade Federal da Paraíba. Centro de Ciências Exatas e da Natureza. Programa de Pós-Graduação em Informática. Campus I. -PB. Brazil. (CEP 58051-900). ²Programa de Pós-Graduação em Modelos de Decisão e Saúde.João Centro Pessoa de Ciências Exatas e da Natureza. Universidade Federal da Paraíba. Campus I. -PB. Brazil. (CEP 58051-900). João Pessoa Abstract. Due to the need to improve access to knowledge and the establishment of means for sharing and organizing data in Received the health area, this research proposes an architecture based on January 8, 2018 the paradigm of Knowledge-as-a-Service (KaaS). This can be used in the medical field and can offer centralized access to Accepted April 30, 2018 ontologies and other means of knowledge representation. In this paper, a detailed description of each part of the architecture and Released its implementation was made, highlighting its main features and April 30, 2018 interfaces. In addition, a communication protocol was specified and used between the knowledge consumer and the knowledge Full Text Article service provider. Thus, the development of this research contributed to the creation of a new architecture, called H-KaaS, which established itself as a platform capable of managing multiple data sources and knowledge models, centralizing access through an easily adaptable API.
Keywords: Knowledge-as-a-service architecture; Health informatics; Knowledge representation.
0000-0002-0919-6957 Renan G. Barreto 0000-0003-4152-5842 Lucas Aversari 0000-0002-8131-0566 . P. Gomes 0000Cecı́lia-0003 - Neta2395 -4846 A Natasha C. Q. Lino
ISSN 2358-2731/BJBS-2018-0001/5/9/1/3 Braz. J. Biol. Sci. http://revista.rebibio.net 4 Barreto et al.
Introduction based on the Knowledge-as-a-Service paradigm in the health area is modeled; a With the advance of processing communication API that will be used to power and speed of data collection on transmit knowledge between the the internet, many organizations focus knowledge provider and the consumer on the development of tools, modeling applications is specified; and an existing techniques and the creation of structures prototype in the nephrology domain is dedicated to knowledge sharing. adapted to an implementation of the Knowledge representation, a subarea of proposed architecture in order to allow Artificial Intelligence, aims to find ways its execution and to validate our to automatically represent, store and approach. manipulate knowledge using reasoning algorithms (Brachman and Levesque, Background 2004). For this reason, the amount of Health informatics data collected in the health domain According to Hoyt et al. (2008), increases periodically, resulting in the Health Informatics can be defined as the emergence of diagnostic methods, field of science that deals with formal chemical principles, and advances in resources, equipment, and methods to molecular biology and genetics, among optimize storage, reading and other medical advances (Wechsler et al., management of medical information in 2003). problem-solving and decision making. Knowledge management and Thus, Health Informatics aims to sharing is a promising area, but it is still improve the quality of health services, inefficient in the field of health reducing costs and allowing the exchange (Sabbatini, 1998). The knowledge of medical information (Hoyt et al., generated through the experiences of the 2008). professionals of the area is not usually passed on satisfactorily, thus retained in Nephrology and chronic kidney their own minds (Silva et al., 2005). disease In this context, the Knowledge- Nephrology is an area of as-a-Service (KaaS) paradigm aims to medicine that has as its objective the provide centralized knowledge that is diagnosis and clinical treatment of normally extracted from various data diseases of the urinary system, mainly sources and can be maintained by related to the kidney (SBN, 2016). different organizations. In it, a Chronic Kidney Disease (CKD) is knowledge server responds to requests defined as damage to the renal made by one or more knowledge parenchyma (with normal renal consumers (Xu and Zhang, 2005). function) and/or renal functional The aim of this work is to impairment present for a period of three propose an architecture based on the months or more. In its last stage, the paradigm of Knowledge-as-a-Service, in kidneys are no longer able to maintain order to create a common knowledge the normality of the patient’s internal base that can be used in the medical field environment. Thus, early diagnosis and or any other health area, and to facilitate disease prevention have become the diagnosis of patients, besides the increasingly important in order to take possibility of centrally providing access preventive measures that may delay or to ontologies and other means of halt the progression of CKD (Bastos and representing and processing knowledge. Kirsztajn, 2011). In this article, the following contributions are made: an architecture
Braz. J. Biol. Sci., 2018, v. 5, No. 9, p. 3-12.
H-KaaS 5
that competes with traditional business Knowledge representation, models (Benlian et al., 2012). ontologies and reasoning From the users’ point of view, the Knowledge Representation is a use of the SaaS architecture presents subarea of Artificial Intelligence (AI) that numerous advantages, such as: cost is concerned with the way that reduction, elasticity, automatic updates knowledge can be represented and easy implementation. For software symbolically and manipulated developer companies, this architecture automatically by reasoning algorithms offers a new way of selling functionality (Brachman and Levesque, 2004). Given a to their customers and competes with structure of knowledge representation traditional business models (Benlian et and a process of reasoning, it is possible al., 2012). to draw conclusions from previously In the context of knowledge modeled knowledge. These conclusions sharing and distribution, the Knowledge- can be used to assist in decision making as-a-Service (KaaS) paradigm aims to (Ladeira, 1997). centrally provide knowledge that is The term ontology, when used in normally extracted from various data the area of computer science, in the sources and can be maintained by context of knowledge representation different organizations. In it, a systems, refers to a general structure of knowledge server responds to requests concepts represented by a logical made by one or more knowledge vocabulary (Russell et al., 1995). To infer consumers (Xu and Zhang, 2005). in ontologies, we need an inference According to Xu and Zhang mechanism called reasoning algorithms. (2005), in an implementation of the KaaS These algorithms allow the comparison architecture, we can find three main of the syntax, possibly normalized components: Data Owners, which are are structure, and concepts expressed in the responsible for collecting data from their ontology (Baader, 2003). daily transactions and for filtering and protecting the collected information; Service Oriented Architectures Knowledge Service Provider, which aims Service-oriented architectures to centralize and provide knowledge (SOA) arose from the need for business through its knowledge server, where integration and automation over the data is extracted using an extractor internet (Papazoglou, 2003). In SOA, algorithm; and Knowledge Consumers, resources are packaged as well-defined which are applications that use the “services” that produce a standardized provided knowledge in their decision- output independently of the state or making process, communicating with the context of other parts of the application server by using a previously established (Fremantle et al., 2002). protocol. The Software-as-a-Service (SaaS) paradigm describes applications and Related work software delivered as a service over the internet. This architecture has already In order to understand and become an important model for selling compare similar researches, this section and delivering software in various presents and analyses several proposals industry sectors, providing several of architectures and frameworks applied benefits to both service providers and to different domains. their users (Armbrust et al., 2010), such It was proposed by Grolinger et as cost reduction, elasticity, automatic al. (2013) the Disaster-CDM, a KaaS updates, easy implementation, and a new framework, aiming to be able to store a way of selling functionality to customers large amount of disaster-related data
Braz. J. Biol. Sci., 2018, v. 5, No. 9, p. 3-12.
6 Barreto et al.
from several sources, facilitating its Thus, when analyzing the related search and indexing in addition to work, we can see that service-based providing support and interoperability architectures can help in decision tools. Disaster-CDM has as its main form support in several domains. We can also of data storage, the use of Relational see that most architectures use a textual Databases (RDB) and NoSQL databases. format for data serialization and It communicates with consumer communication with consumers. On the applications in three ways: ontologies, other hand, we can see that the sources APIs, and services. These three forms of of knowledge vary according to the data access allow Disaster-CDM to domain and availability of data holding respond to requests in an integrated services. Thus, it is necessary to adapt manner without depending on how the each architecture to its domain, in order data is saved internally. to allow a greater use and sharing of In the Health domain, a relevant available domain knowledge. article from Yoo et al. (2014), describes a collaborative service-oriented Proposed KaaS architecture for architecture designed to facilitate E-health sharing and cooperation between health care providers, while reducing costs for Based on the study and analyses the patient. The architecture described of the architecture proposed by Xu and has three main components: centralizer Zhang (2005) for the Knowledge-as-a- of medical collaborations; consumer Service paradigm, it was investigated in applications and healthcare services this work a generic KaaS architecture providers. aimed at the Health domain. For that, a Another research focused on the similar, but extended and detailed health domain was done by Lai et al. platform, called H-KaaS, was designed. (2012), which identifies the main H-KaaS aims to centralize access characteristics of a collaborative medical to knowledge generated from several services network and, in addition, distinct data sources, allowing efficient explores ways in which KaaS could be knowledge sharing. An overview of the used to create a private network of H-KaaS architecture can be seen in medical knowledge in China. Figure 1.
Figure 1. An overview of the H-KaaS conceptual architecture, based on the paradigm of Knowledge- as-a-Service adapted to the Health domain. Source: Own Authorship.
Braz. J. Biol. Sci., 2018, v. 5, No. 9, p. 3-12.
H-KaaS 7
In the medical field, data sources In addition, within the knowledge could be considered, for instance: results extractor, auxiliary algorithms are of clinical tests, domain ontologies, responsible for several common books, periodicals, guidelines for functions for reading and manipulating diseases treatment, among others. Each information like reading text files, data source has its own characteristics loading and converting images, among and must be treated independently, in others. It is also possible that the order to facilitate the inclusion and knowledge extractor has its own data modification of new extraction rules. storage mechanism in order to index and For consumer applications, it is improve access speed for specific possible to create various solutions for queries. each interested part that exists in the In order to respond to consumer domain. For example, applications for queries, the server implements the clinical decision making processes can be communication API, providing created to improve the service provided standardized responses that can be by specialists and primary care easily understood by consumer professionals. applications. The architecture H-KaaS has been divided into modules in order to be Knowledge consumer easier to maintain, understand and The H-KaaS architecture, implement. The main modules that similarly to the KaaS paradigm, provides compose the architecture are the the possibility of being accessed by (1) knowledge service provider, different knowledge consuming (2) knowledge consumer, applications. These applications use the (3) communication API, and (4) data communication API to make queries to sources. In the next topics, we will talk the central knowledge base. Possible more about each one of them. consumer applications in the Health domain, are clinical decision support Knowledge service provider websites, mobile applications or Within the KaaS paradigm, the embedded systems, electronic medical knowledge service provider module aims records, educational systems, and others. to access and process data from the data In the security field, each source, manage knowledge models and application must have a unique private serve queries made by knowledge key that will be used during consumers (Xu and Zhang, 2005). In the communication with the service provider context of H-KaaS, the knowledge service in order to authenticate, limit and/or provider consists of two main parts: the identify the queries made by it. A failure knowledge extractor and the server-side in providing the security key will make it implementation of the communication impossible to access the knowledge API. service provider, which is responsible for Extraction of knowledge is made creating, storing and sharing the keys. as queries are performed by consumer applications, through inferences in Communication API ontologies, queries for documents or The communication between the other sources of data and knowledge. knowledge service provider and the Each data source has its corresponding consumer applications is made through extraction rules within the knowledge the communication Application extractor. Therefore, for each new data Programming Interface (API), the H-KaaS source added, extraction and access rules API. According to Masse (2011), an API is need to be written so that it can be a web service, based on well-defined integrated with the existing system. programming interfaces, which enables
Braz. J. Biol. Sci., 2018, v. 5, No. 9, p. 3-12.
8 Barreto et al.
communication between applications. In the H-KaaS API, it has been needed to other words, an API can be considered a specify two commands: medium in which communication between two computer programs is • /service: Command that receives allowed. requests of type GET and lists the services For the specification of the API, currently implemented in the platform. Each the principles mentioned by Bloch service has its descriptions, identification code and, mainly, a list of the methods (2006) were used, being the main ones: available, that can be executed at any time by an API should be small and simple; the consumer application, allowing access to errors should be reported immediately; a the available knowledge. small number of parameters should be • /service/id/method: Command kept; and all functions must be well responsible for executing a method of a documented. These help to create a good specific service. It receives requests in the communication API. POST format and therefore, in order to Recently, an architecture style for execute it, the application must provide specifying APIs was proposed by serialized information based on the input Richardson and Ruby (2008), the form present in the input key. The response of this command is a JSON serialized object Representational State Transfer (REST). containing some information about the query APIs that follow this paradigm are called performed and the result of its execution. RESTful APIs or REST APIs. This architecture uses standards similar to a Regarding the error handling and protocol that is widely used on the formatting, the H-KaaS API has a special Internet, the Hypertext Transfer Protocol object of class Error that is instantiated (HTTP). In REST APIs there are four main and returned when some critical types of commands: GET, POST, PUT and problem occurs during query execution. DELETE. As for security, for the execution of each Each command is responsible for API call, the consumer application must an operation on the data. The POST send a mandatory security key. This key command, for example, is responsible for ensures that access to knowledge is updating or appending information. limited only to authorized applications. Similarly, the DELETE command is able to remove information from the server. Data sources The GET and PUT commands The H-KaaS provides the respectively are responsible for reading possibility of multiple independent data and adding entities on the server (IETF, sources, allowing greater flexibility in 2014). obtaining information and/or knowledge Another important feature of provided by external services. The data REST APIs is their data output format, access system can vary according to its where are used semi-structured textual source and, therefore, the knowledge object serialization formats, such as extractor is responsible for JavaScript Object Notation (JSON) and implementing the necessary means to XML (Richardson and Ruby 2008). read and extract the relevant The H-KaaS API is an API based information. Access to data can take on the REST architecture and uses the place in two ways: local, in which data is JSON data format, which is a light, text- organized in the same file system where based, language-independent format for the service is running; and remote, in information transfer. This format defines which data is transferred from remote some formatting rules that allow the sources, occasionally unavailable. representation of data in a structured Because remote access is less way (Crockford, 2006). When designing reliable, it is recommended to use
Braz. J. Biol. Sci., 2018, v. 5, No. 9, p. 3-12.
H-KaaS 9
indexing and caching mechanisms in For the adaptation of the order to improve overall system ontology present in the OntoDecideDRC performance in periods of instability. For to the knowledge extractor module, it some remote data sources, information was necessary to write a command line may be mass-collected for the purpose of application, able to execute the reasoner local batch processing. Thus, even if the HermiT and infer in an OWL-type data source stops working after ontology, using queries based on obtaining the data, H-KaaS would still be Description Logic. This application was able to execute the extraction and implemented in the Java programming creation of the knowledge models from language and is part of the knowledge the previously obtained data. extractor module. In the knowledge extractor, some Case Study: Providing clinical auxiliary functions were also created to decision support to CKD execute ontology queries. One of these is the implementation of the Glomerular The objective of this case study is Filtration Rate (GFR) calculation. This to adapt an existing prototype in the calculation uses the simplified MDRD Health domain for an implementation of formula specified by Levey et al. (2000) the proposed architecture. Two and, through patient information, a prototypes were studied in order to numeric value is reached that will be choose one to be adapted to the new used during inferences in the knowledge architecture, both researches have, as model. knowledge representation system, The knowledge consumer unique ontologies, created with the help module, a website called NefroService, of specialists in the nephrology field. had the objective to test the API and The OntoDecideDRC, a platform implement the graphical interface of the based on web services, aims to support chosen prototype. The programming clinical decision to nephrology specialists language used for the implementation of and those working in primary health care NefroService was PHP and, in (Tavares et al., 2016). Another similar conjunction with the Wordpress research was done by Campos et al. framework, made possible the (2016) where EducaDRC was created, a implementation of several pages for semantic repository of learning objects login, registration, password recovery, about CKD. services list, method execution, contact, The main difference in the among others. approaches is that EducaDRC, as a When adapting OntoDecideDRC, semantic repository, needs an additional it was realized that the source code of its database for storing triples and graphical interface was not available and, metadata, used to describe external therefore, it was necessary to create a resources. Therefore, due to database new form for data entry based on the independence, the OntoDecideDRC was original specification of the prototype. chosen as the ontology and base The data provided served as the basis for prototype to be adapted to the H-KaaS the staging method of the architecture. OntoDecideDRC service on the The knowledge service provider NefroService. All form fields have been was implemented in the PHP language rewritten and organized in a similar way and, in addition to containing the to their original version. commands required for the extraction When accessing the NefroService, and inference of knowledge, also the user faces a form for inserting its implements the commands described in credentials. These credentials are the the API specification. responsibility of the consumer application, which enables the creation
Braz. J. Biol. Sci., 2018, v. 5, No. 9, p. 3-12.
10 Barreto et al.
of different levels of access to the This form is generated application, as well as better control of dynamically based on the data received how information is shared. from the communication API. When Each service has a dedicated submitted, a request is sent to the API page, which can assist the user in and, from it, the HTML code is created choosing an appropriate method. After with the response that will be shown to choosing the method, the user will face the user (Figure 2.B). If during the the data entry form and a brief processing of sending of the request, an description of how to fill it. Figure 2.A error occurs, an error message and a shows the staging method form, similar possible solution will be shown to the to that implemented in the original user. prototype of the OntoDecideDRC platform.
Figure 2. CKD staging method form (A) and an example of its response (B).
The implementation of the detailed description of each of its knowledge consumer website enabled modules. To validate this new the platform user to perform queries architecture proposed, a case study was using forms similar to those originally made, where an existing prototype in the provided by the OntoDecide-DRC domain of nephrology was adapted, platform, the prototype chosen to serve which allowed the inference in the as a source of knowledge and basis for modeled knowledge base and the the creation of the graphical interface creation of a clinical decision support forms. mechanism, similar to the original prototype. Conclusion The KaaS paradigm, although relatively new, is promising in terms of In this article, a new Knowledge- distribution and access to knowledge, as-a-Service based architecture was being possible to use it better in domains presented in the health domain, with a where, even there is a large amount of
Braz. J. Biol. Sci., 2018, v. 5, No. 9, p. 3-12.
H-KaaS 11
data being collected daily, there are still Bloch, J. How to design a good api and why it no efficient ways to share knowledge matters. Proceeds of the 21st ACM SIGPLAN satisfactorily. Symposium on Object-Oriented Program- This paper opens the way for ming Systems, Languages, and Applications, new sources of data and knowledge so p. 506-507, 2006. that they can be developed and made Brachman, R.; Levesque, H. Knowledge available more effectively. In addition, Representation and Reasoning. San Francisco: Morgan Kaufmann Publishers, new applications that use this data in 2004. interesting ways can be developed through the use of the communication Campos, S. P. R.; Pegado, C. N. A.; Lino, N. C. Q. Referatório semântico de objetos de API. aprendizagem sobre doença renal crônica. In conclusion, the development of Journal of Health Informatics, v. 8, this research contributed to the p. 417-427, 2016. Available from: emergence of a new architecture, called
Braz. J. Biol. Sci., 2018, v. 5, No. 9, p. 3-12.
12 Barreto et al.
creatinine. Journal of the American Society Tavares, E. A.; Pegado, C. N. A.; Lino, N. C. Q. of Nephrology, v. 11, suppl. 2, p. 155A, 2000. Suporte à decisão clínica no domínio da Masse, M. REST API design rulebook. doença renal crônica. Journal of Health Boston: O’Reilly Media Inc, 2011. Informatics, v. 8, p. 839-847, 2016. Available from:
Silva, R. P. Modelo de apoio ao diagnóstico no domínio médico: aplicando raciocínio baseado em casos. Brasília: Universidade Católica de Brasília, 2005. (Master dissertation).
License information: This is an open-access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.
Braz. J. Biol. Sci., 2018, v. 5, No. 9, p. 3-12.