Microservice chatbot architecture for chronic patient support

Abstract

Chatbots are able to provide support to patients suffering from very different conditions. Patients with chronic diseases or comorbidities could benefit the most from chatbots which can keep track of their condition, provide specific information, encourage adherence to medication, etc. To perform these functions, chatbots need a suitable underlying software architecture. In this paper, we introduce a chatbot architecture for chronic patient support grounded on three pillars: scalability by means of microservices, standard data sharing models through HL7 FHIR and standard conversation modelling using AIML. We also propose an innovative automation mechanism to convert FHIR resources into AIML files, thus facilitating the interaction and data gathering of medical and personal information that ends up in patient health records. To align the way people interact with each other using messaging platforms with the chatbot architecture, we propose these very same channels for the chatbot-patient interaction, paying special attention to security and privacy

Telemonitoring System for Infectious Disease Prediction in Elderly People Based on a Novel Microservice Architecture

“…In a study by Roca et al [25], a chatbot architecture was proposed for chronic patient support based on three pillars: scalability through microservices; standard data exchange models through HL7 fast healthcare interoperability resources (FHIR); and modelling of standard conversations using AIM. These three pillars relied on a microservicesbased logic that aimed to process user information and perform automated tasks to provide scalability in a healthcare chatbot ecosystem.…”

“…Before considering the design of the different microservices for the development of different medical platforms (such as the SPIDEP platform) based on this architecture, it is important to take into account the hierarchy and consolidation of the clinical information of the patients. This is not only necessary for generating standard reports, but can also influence decision making using parameterised, consistent and verified indicators of the collected data in conjunction with other medical information systems [25], [45], [46] that aim to correctly filter the data to minimise false alarms by the recommender systems.…”

“…The main strengths of the microservices are as follows: • Microservices can be implemented in a given language and can use the libraries that are best suited to provide the functionality needed [25], [29]. • The structure of the platform allows for different types of databases depending on the requirements [25].…”

“…The main strengths of the microservices are as follows: • Microservices can be implemented in a given language and can use the libraries that are best suited to provide the functionality needed [25], [29]. • The structure of the platform allows for different types of databases depending on the requirements [25]. • This allows for the agile scaling of individual microservices, which are widely used by replication based on several containers, without needing to replicate underutilised services [19].…”

“…The microservices developed in PHP use the Laravel framework, while the those developed in Python use the Django framework. It should be noted that all microservices developed in SPIDEP have an asynchronous HTTPS server based on TLS for client authentication [25], [54], and the databases applied to each one were SQL (MariaDB) and NoSQL (Cassandra or MongoDB). As a complement to this microservicesbased architecture, we use the "service instance per container" and "database per service" implementation patterns [64].…”