medAL-suite: A software solution for creating and deploying complex clinical decision support algorithms

Abstract

Background

Sub-optimal healthcare quality in low-resource settings is attributed in part to poor adherence to clinical guidelines. Clinical decision support systems (CDSS) help to integrate guideline-based algorithms into logical workflows and improve adherence to evidence-based recommendations, and hence quality of care. However, the process of translating paper-based guidelines into electronic algorithmic formats is often complex, inefficient, expensive, and error-prone due to reliance on advanced software development skills and clinical knowledge.

Methods

In response to these challenges, we developed open-source software called the Medical Algorithm Suite (medAL-suite), consisting of four components, with a primary goal of increasing efficiency, accuracy, and transparency of CDSS creation by giving experienced clinicians, rather than software developers, greater control over the process. At the heart of the software suite is the medAL-creator that allows clinicians to design algorithms using a code-free drag-and-drop interface. Algorithms are subsequently automatically deployed in medAL-reader to service level clinicians in health facilities. CDSS implementers use medAL-data and medAL-hub to manage configuration, versioning, and deployment.

Results

Since its development, the medAL-suite has been used to digitalize complex primary care guidelines and deployed in large-scale clinical studies in Tanzania, Rwanda, Kenya, Senegal, and India, leading to notable outcomes such as the reduction of inappropriate antibiotic prescriptions and improvement in care quality. Over 300,000 pediatric outpatient consultations have been completed in Rwanda and Tanzania to date using the digital algorithm.

Discussion

The medAL-suite focused on democratized development, process-centric design, point-of-care utility, touch-screen interface, low cost, and low power consumption to contribute to sustainable digital systems in low-resource settings. Important future developments and adaptations as the software evolves should emphasize interoperability and scalability, primarily via integrating CDSS functionality into electronic medical records for a streamlined user experience that supports improved service quality at the point-of-care.

Clinical trial number

Not applicable.

Background

Sub-optimal quality of healthcare in low-resource settings is attributed in part to inaccurate diagnoses, inappropriate or unnecessary treatments and inadequate or unsafe clinical practice [1]. Clinical guidelines synthesize medical evidence and expert opinion into actionable information [2], and when adhered to, can standardize patient management and improve quality of care [3]. However, adherence to paper-based guidelines, particularly in outpatient settings, is low [4, 5] due to their narrative nature and typical focus on a single condition [2], whereas patients often present with multiple complaints, requiring complex integration of several guidelines [4, 5]. In recent years, electronic clinical decision support systems (CDSS) have shown promise in achieving a complex integration of primarily knowledge-based diagnostic algorithms into logical workflows, guiding clinicians through patient consultations to recommended diagnoses and treatments. CDSS have demonstrated improved adherence to guidelines [6–8], reduced antibiotic prescriptions [9–11], and better clinical outcomes [8, 9], albeit often in research conditions.

Despite the potential benefits for patients and health systems, the process of translating paper-based clinical guidelines into electronic formats is often inefficient, especially for complex algorithms. To help address this problem, WHO developed Standards-based, Machine-readable, Adaptive, Requirements-based, and Testable (SMART) guidelines to guide CDSS developers and implementers through a 5-step process of translating evidence-based narrative guidelines (L1) into operational, software-neutral documentation of operational and functional requirements (L2), machine-readable structured specifications, code, terminology and interoperability standards (L3), software able to execute static algorithms and interoperable digital components (L4), and finally executable dynamic algorithms trained and optimized with advanced analytics (L5) [12]. Each step of this process requires advanced IT expertise and know-how. The coded clinical logic can be complex and difficult to understand, making stakeholder review and validation slow and error-prone, and limiting the capacity for updates to keep up with advances in medical evidence and guidelines [4, 5]. It further increases the dependence of digital health systems on advanced software development skills that for now tend to remain concentrated in the global North, thereby keeping the cost of implementation and maintenance of CDSS high and inhibiting autonomy of digital systems in low-resource settings.

In response to these challenges, a unique open-source software called the Medical Algorithm Suite (https://medal-suite.com/) was developed. The primary goal of the medAL-suite was to increase efficiency, accuracy, and transparency of the L2 to L4 conversion process for CDSS (Fig. 1). The target users of the software suite include: 1) health program-level clinicians who normally design or update algorithms (users of medAL-creator); 2) service-level clinicians who benefit from decision support logic in their daily clinical practice (users of medAL-reader); and 3) implementers or deployment managers of CDSS who manage the configuration and deployment of IT tools in health facilities, create and maintain users, and monitor performance of the system (users of medAL-data and medAL-hub).

Fig. 1.

Digital algorithm creation (solid line arrows) and adaptation (dashed line arrows) process following a traditional pathway (bottom) and using the medAL-suite (top). Icons were obtained from the Noun Project (CC BY 3.0) https://thenounproject.com and https://healthicons.org

With a code-free interface, health program-level clinicians can create complex decision logic tailored to local guidelines, epidemiology, and implementation context using their clinical decision logic skills without advanced programming skills (Fig. 2). Clinical elements are defined within the design environment (medAL-creator) and decision logic is created using a drag-and-drop approach. The algorithms are deployed in an Android tablet-based application (medAL-reader), while preserving a logical consultation flow for end-users – such as nurses or clinical officers in health facilities. medAL-data is a database and hosting platform that facilitates the deployment process by enabling functions like creation of unique health facility identifiers, facility-specific algorithm versions, user assignments, device allocations, algorithm setups, performance monitoring and troubleshooting. medAL-hub is a local server based in health facilities that enables communication among multiple devices via a local network to support task-shifting and team-based care. It enables multiple users to access and update the same medical case in sequence (Fig. 2).

Fig. 2.

Overview of the main components of the medAL-suite and their configuration within the health system. Client-server mode of operation is shown (with medAL-hub). Icons were obtained from the Noun Project (CC BY 3.0) https://thenounproject.com and https://healthicons.org

The software solution is designed for low-resource settings to run on inexpensive, low power, widely available hardware. It can be deployed in two modes: client-server (with medAL-hub) or standalone (without medAL-hub), depending on the implementation setting. In standalone mode, tablets (medAL-reader) communicate directly with medAL-data, whereas in client-server mode, many functions are facilitated by the medAL-hub (Fig. 2). Each of the four main components of the medAL-suite is further detailed in the subsequent sections. The goal of this manuscript is to present the main features of the software and discuss future directions in the context of the current digital health landscape. Large-scale evaluation studies of the tool have been completed and are published separately.

Features and specifications

medAL-creator

Concept and definitions

The goal of medAL-creator is to enable building complex diagnostic decision tree algorithms and package them for deployment to the end-user (service level clinician) in medAL-reader. medAL-creator uses the Ruby on Rails framework for its backend, React for its frontend development and a PostgreSQL database. In the platform, a user is assigned to a project, which contains one or more algorithms used for versioning. An algorithm is a series of decision trees. A decision tree is a component of the algorithm consisting of a set of variables linked together through decision logic to reach a diagnosis as a terminal node or endpoint (Fig. 3). Decision trees are designed individually, and lead to one or more diagnoses. Decision trees are also designed for each individual diagnosis to propose treatments and managements. Treatment decision trees consider patient characteristics, other diagnoses and treatment availability. Once the full algorithm (all decision trees and links among them) is designed and configured, medAL-creator builds a JavaScript Object Notation file (JSON), an open standard file format using human readable text to store and transmit data objects. The JSON file is fed into medAL-reader to display the clinical decision support logic to the end-user in a health facility. A significant advantage for the users of medAL-creator is interacting with simpler, individual decision trees for groups of clinical syndromes or diagnoses rather than the whole, complex algorithm of all possible diagnoses at once. The flip side of this advantage is the difficulty in detecting conflicts among diagrams due to the inability to see the entire algorithm at once. There currently isn’t a known solution in the landscape of algorithm authoring tools that overcomes this challenge for very large and complex diagnostic algorithms. The combination of medAL-creator and medAL-reader simplifies the user experience by synthesizing the complexity of the full algorithm content and presenting it to the end-user in a logical consultation flow.

Fig. 3.

An example of a diagnostic diagram for pharyngitis [A]; expanded definition of a scored predefined syndrome Cape Town clinical decision rule (CDR) [B]; and treatment diagram for the management of bacterial acute pharyngitis [C]. Note: CDR definition is adapted to consider tonsillar swelling, which must be present, separately in panel A, in addition to at least one of the other signs or symptoms included in the CDR in panel B

Design area and mechanics

The diagram creation page consists of a repository of building blocks and a diagram area. Users drag and drop building blocks from the repository into the diagram area and connect them with arrows to define the decision logic. The building block categories include variables for patient clinical characteristics (e.g., demographic information, medical history such as exposures and chronic conditions, symptoms and physical exam findings for the current medical problem), “predefined syndromes” (i.e., sub-diagrams consisting of a predefined combination of several variables), diagnoses, treatments, and managements (Table 1). In a diagnostic algorithm, a basic diagram has one or more diagnoses as its terminal nodes. Other building blocks are linked together to reach the diagnoses (Fig. 3). The logical operator AND is represented by linking two building blocks sequentially; the OR operator, always interpreted as an inclusive OR, is represented by parallel branches. Age cutoffs can be set for each arrow to define specific age conditioning. Managements and medicines associated with each diagnosis, as well as chronic or past medical conditions that may modify its severity or treatment plan, are built using a separate treatment diagram that is linked to and can be opened from the diagnosis in Fig. 3.

Table 1.

Building blocks and element types in medAL-creator

Type	Description	Attributes	Example usage
Variable
Demographic	Personal information that may or may not be used in diagrams (some used for identification)	- Answer types (binary, categorical, integer, decimal, formula, date, string) - Complaint category - Body organ system - Indicates emergency? - Is mandatory? - Is linked to patient identity? - Value can be not feasible, unavailable, or unknown - Label, description and accompanying media (image, video, sound) - Lower and upper limits for clinically relevant warning (e.g., oxygen saturation of 88% is low warranting referral) - Lower and upper limits for possible data entry errors (e.g., weight of 1 kg for a 5-year-old child is not possible)	Date of birth, sex, village of residence
Basic measurement	Routine body measurements taken during consultation; used in calculations		Weight, height, MUAC
Symptom	Based on the subjective report from a patient or caregiver		Cough, diarrhea, runny nose
Physical exam	Based on the physical examination performed by the clinician		Enlarged lymph nodes, jaundice
Vital sign	Important vital measurements that are often assessed before the consultation		Temperature, respiratory rate
Unique triage	Symptoms or signs triggering an expedited consultation to manage an emergency		Convulsing, unconscious
Exposure	Potential contact with a source of infection or toxicity		Risk factors for vertical HIV transmission, dog/bat bite, recent close contact with TB patient
Chronic condition	A long-standing, persistent disease that can impact how the case is managed		Cerebral palsy, sickle cell disease
Background calculation	Calculation performed using previously entered numerical variables		Weight-for-age or weight-for-height z-score
Assessment or test	A paraclinical test performed to aid in the diagnosis or detection of disease		Rapid diagnostic test, laboratory test, x-ray
Treatment condition	Additional question asked before the treatment section to account for limitations that impact management		Is ceftriaxone available? Can the patient swallow?
Medical condition
Predefined syndrome	Sub-diagram (or calculated variable based on combination of other variables) that decongests the visual display, makes it easier to reuse content, and gives the user ability to create scores	- Cutoff values used to set thresholds and assign weights to variables to calculate a severity score.	Dehydration risk score, moderate or severe malnutrition, Cape Town Clinical Decision Rule (CDR)
Diagnosis
Diagnosis	A diagram can contain one or more diagnoses; diagnosis exclusions can also be applied (so that a more severe diagnosis, e.g., severe anemia excludes a milder diagnosis e.g., mild/moderate anemia).	- Level of urgency (1–10)	Severe anemia, pneumonia, malaria
Management
Management	Non-pharmaceutical actions recommended for the clinical case, such as immediate actions, counselling, follow-up or referral.	- Level of urgency (1–10)	Urgent referral, give salbutamol now, ensure adequate fluid intake at home, follow up in 3 days
Treatment
Medicine	Automated medicine dosing recommendation, using two approaches: calculated and fixed. - For calculated dosing, the user selects the formulation, and for each formulation the appropriate information (e.g., administration route, number per day, volume, maximum daily dose, etc.). - For fixed-dose, only administration route, number per day and number of applications.	- Formulations (tablet, capsule, syrup, suspension, suppository, drops, solution, powder for injection, patch, cream, ointment, gel, spray, inhaler, pessary, dispersible tablet, lotion). - Breakability attribute for tablets (possible values: in 2, in 4, not breakable)	Amoxicillin 250 mg tablet for the treatment of bacterial pneumonia: administer orally, 2x per day, maximal dose 100 mg/kg/day, tablet breakable in 2, duration 5 days.

Configuration

After building all the individual diagnostic algorithms, variables can be assigned to consultation stages, and further arranged in a specific sequence, which determines in what order they appear. Variables (or entire diagrams) can further be assigned to complaint categories (further described in the medAL-reader section), which are selected at the start of the consultation by the end-user based on the main presenting symptoms and serve as entry points into specific diagrams. It is possible to download a data dictionary with all variable definitions, as well as to download and upload a full translation file in.xlsx format to facilitate deployment of the clinical content in multiple languages.

Unique feature highlights

Versioning: A user of medAL-creator can maintain multiple versions of an algorithm by copying the entire set of decision trees and making any number of desired modifications. A specific version of an algorithm can be assigned to an individual health facility in medAL-data, making it possible to deploy algorithms adapted to their unique setting (e.g., malaria endemicity, level of resources). Algorithm version is subsequently reported in medAL-data with each completed medical case.

User notification: When modifying a particular variable, the user is notified where in the algorithm that variable is used, prompting an evaluation of the impact of the change. However, referential integrity mechanisms are also in place, forbidding changes on variables used in a version that is (or ever has been) deployed in the field.

Exclusions: Exclusions for diagnoses can be set in two ways: by drawing arrows between diagnoses that exclude each other within a diagram; or by specifying the exclusion on a dedicated page for diagnoses that exclude each other across different diagrams. For instance, pneumonia would exclude “common cold” in case the patient presentation met criteria for both diagnoses. Similar logic is applied to establishing a hierarchy of medicines and managements. For example, it is possible for a child to have severe pneumonia, for which the algorithm prompts to administer injectable gentamicin and ampicillin and to refer the patient urgently to a hospital, and a concurrent milder diagnosis such as complicated acute ear infection for which oral amoxicillin and home-based care are recommended. In such cases, the medAL-creator user can set injectable ampicillin and gentamicin to override oral amoxicillin and urgent referral to override home-based care so as not to provide unnecessary, redundant or conflicting recommendations to the end-user.

Automated validation checks: Every time a new element is added to a diagram, the system checks for consistency within the diagram. As an example, if the symptom ‘sore throat’ wasn’t connected to the following question ‘runny or blocked nose’ in the pharyngitis diagram (Fig. 3), this would trigger an alert prompting the user to check the algorithm and make sure that there are no “floating” variables without links, resulting in a dead-end. The system also detects attempts to create circular references.

medAL-reader

Overview

The goal of medAL-reader is to offer the clinical end-users a comprehensive tool that guides them through a patient consultation to one or several diagnoses and the corresponding management plan. medAL-reader is built using the widely used JavaScript framework React Native, enabling the use of a single codebase for both iOS and Android platforms. The workflow is organized into the following consultation stages: registration, initial assessment, consultation, assessments and tests, diagnoses, treatments and managements, as per a typical outpatient consultation workflow. Presently, the application is configured to store and display historical patient consultations, with the ability to search for an existing patient using a name or a Quick Response (QR) code and add a new consultation to his/her patient record. Prior to starting to use the application, the user can select the desired language (of those into which the algorithm content has been translated in medAL-creator) in the ‘Settings’ page.

Question sequence

Question sequence is defined at several levels, including the consultation stage, complaint category, and to some extent algorithm logic. At the highest level, questions are allocated to consultation stages to align with the healthcare provider’s typical workflow, or order in which consultations are conducted. Within the consultation stages, questions are further organized according to the complaint category to which the corresponding algorithm has been assigned. For example, the outpatient algorithm used in Rwanda and Tanzania to treat children between 2 months and 14 years of age includes 9 complaint categories: Fever, Respiratory, Gastrointestinal, Ear/Nose/Mouth/Throat, Eye, Neurological, Skin/Hair, Genitourinary, and Accident/Musculoskeletal (Fig. 4; panel 1). Additionally, the algorithm contains questions asked to every patient, regardless of their main presenting complaint, as required by relevant clinical guidelines, for triage purposes for instance. While the consultation stages are currently hard-coded in medAL-reader, complaint categories can be defined by the user in medAL-creator according to the type of algorithm being designed. In theory, all inputs in the application are mandatory; however, provisions have been made to accommodate some measurements that are sometimes not feasible to perform (e.g., weight, height, MUAC, respiratory rate in Fig. 4; panels 2 and 5). For these, the healthcare provider can mark that the measurement is not feasible to ascertain, with modifications made in the algorithm to adapt to the missing information.

Fig. 4.

Progression of the consultation workflow in medAL-reader (some screens are omitted)

Unique feature highlights

Error and warning messages: As described in Table 1, when variables are created, two types of thresholds are set for numerical variables, one to indicate a clinically relevant warning to prompt healthcare provider action (e.g., low MUAC warranting referral to a malnutrition program, Fig. 4; panel 2), and another to indicate a probable erroneous value that should be revisited and corrected (e.g., oxygen saturation of 20%). The messaging helps to improve data quality and compliance with clinical protocols.

Information buttons: Elements in the algorithm can be accompanied with additional text, images, sound clips, gif animations or mp4 videos that are accessible via an “i” (information) button that appears next to the element (Fig. 4). This content can serve as learning material (e.g., an image that helps to identify a particular skin condition) or a reminder (e.g., a list of symptoms for which to bring a child back to the health facility) to the healthcare provider.

Ability to accept or reject diagnoses and treatments: Healthcare provider autonomy has been described as a major barrier to acceptability and uptake of digital health tools [13–15]. As such, medAL-reader allows the users to agree or disagree with one or more of the proposed diagnoses and treatments, or to select another diagnosis in place of the proposed ones. The user can select from a drop-down menu another diagnosis that is present in the algorithm and thus receive the relevant management and treatment recommendations, or add a custom diagnosis entered as free text for documentation purposes, for which management and treatment recommendations are not provided by the system (Fig. 4; panels 6 and 7). The same mechanism of agreeing, disagreeing, or manually adding (from the dropdown list with dosing information or as free text without dosing information) applies to medicines. This also serves as feedback to algorithm developers, signaling to review clinical content and determine whether adaptation to a specific clinical context (e.g., medicine availability) or additional training or supportive supervision (e.g., for inappropriate addition of antibiotics) may be needed.

medAL-data

medAL-data has two main objectives: first, it facilitates a secure deployment of clinical algorithms on electronic devices in health facilities; and second, it hosts the clinical data generated through its regular use (Table 2). medAL-data is developed with the Laravel framework and a PostgreSQL database, running on a NGINX web server. Among the different packages used in the application, the most significant ones are: AdminLTE to develop the user interface, Passport to secure the exchanges of data with medAL-reader and medAL-creator, Laravel Auditing to monitor and supervise changes in the database, Google2FA for Laravel to implement two-factor authentication, and Laravel-permission to define user roles and permissions. The database follows an entity-attribute-value (EAV) model; this characteristic is required by the fact that medAL-creator generates a dynamic data structure (as the user can add or remove variables in various algorithm versions at any time), meaning that the collector of the data needs to be dynamic as well.

Table 2.

Main features of medAL-data

Security

User rights management Passport authentication

Deployment

Create health facilities with attributes (country, region, GPS coordinates) Create devices (tablets and hubs) with attributes (model, operating system, MAC address) Create medical staff users with attributes (cadre) Assign and manage devices and users associated with each health facility Assign and manage algorithm versions (from medAL-creator) in each health facility Generate unique IDs (QR codes) specific to each health facility

IT system monitoring

Load data coming from medAL-reader and store them in the data model Monitor data flow from health facilities (time stamps of last synced cases) Access information about JSON files of medical cases that failed to load in the database Monitor update status of hubs and tablets (to verify all updates have been deployed) In case of outdated devices, access error messages for updates that failed to deploy Assign access tokens to all devices to authorize communication with medAL-data (security feature) Assign a unique 4-digit passcode to each health facility to unlock tablets (security feature)

Data management

View patients, medical cases, diagnoses, and medications, liked by unique medical case ID Identify duplicate cases, compare them side by side and remove one case based on completeness Identify duplicate patients (same patient registered multiple times) and merge them Drop individual medical cases, patients, or health facilities (in a cascade manner) from analysis Export data in relational and flat.csv formats (de-identified and identified exports available)

The heart of the software is what is called a loader; its role is to process all JSON data files received from medAL-reader, perform quality checks, and load them in the data model. The loader is updated at regular intervals through an API available in medAL-creator in order to always be up-to-date with the latest version of the algorithm. In case of a failed process, the JSON is moved to another folder (failed folder) and the data manager can manually analyze the medical cases that failed to load in the database to understand any inconsistencies.

The deployment manager can create health facilities, devices (tablets and local Raspberry Pi servers called hubs), and users (healthcare providers), and assign devices, users and algorithm versions (from medAL-creator) to health facilities in medAL-data. Within the health facility management page, it is also possible to generate unique patient ID labels (QR codes) for printing in case patient identification is required by the implementation scenario.

The deployment manager can also monitor the data flow based on the most recent sync dates, as well as the status of devices, particularly the hubs, to make sure that the most recent updates have been deployed. In case of outdated devices, it is possible to access error messages for updates that failed to deploy to determine if a manual push of updates or a field visit to the health facility is needed. Management of security features, such as device pin codes and authentication tokens that allow devices to communicate with medAL-data are also supported.

The data management functionalities include exporting data in relational or flat.csv formats, dropping of medical cases, patients (with their associated medical cases) or entire health facilities (with their associated patients and medical cases) from analysis, and reviewing patient and medical case duplicates. Medical case duplicates are automatically flagged based on multiple consultations created for the same patient on the same day. The data manager can review two cases at a time side by side and retain the more complete entry, while the other is marked as ‘duplicate’ and subsequently dropped from the database. Patient duplicates are flagged based on matching first and last name and/or date of birth; optionally deduplication can be done on any other relevant variable such as the national ID number. Similarly, two patients can be compared side by side in terms of demographics (e.g., village of residence, name of the caregiver) and either merged or kept separate. When patients are merged, a new ‘active’ patient is created, while the duplicate patients are marked as ‘merged’. Going forward, the new ‘active’ patient carries the links to the medical cases from both merged patients to enable a cohort analysis of all consultations for a given patient.

medAL-hub

medAL-hub facilitates the client-server mode (versus standalone mode) of operation, providing local hosting of the health facility database and the ability of multiple users (tablets) to access and update medical cases. medAL-hub is developed with the Laravel framework and a PostgreSQL database. The application has no user interface and runs on a NGINX web server hosted on a Raspberry Pi (HypriotOS). The primary use case for this feature is task-shifting among several clinical users on different devices to update or manage the same medical case: for example, a patient is registered at the registration window (user 1), vital signs and basic measurements are entered at the triage station (user 2), and the rest of the consultation is completed by the clinician in the consultation room (user 3).

Client-server and standalone modes have their advantages and disadvantages (Table 3) and selection of the appropriate mode highly depends on the implementation context. The IT configuration is flexible as the mode of operation can be determined on an individual health facility basis. For example, in large health facilities with multiple consultation rooms and/or multiple potential users and a relatively stable power supply (short power outages of less than 2 hours), the client-server mode may be more appropriate. On the other hand, in small health facilities with a single user and prolonged power outages, standalone mode may be preferred. While both configurations allow for offline use of the system for patient management, the Raspberry Pi and router must have a power supply for the client-server mode to work as intended. During power outages, the tablet can be temporarily used in pseudo-standalone mode, with cases syncing to the hub when power to the hub and router is restored. However, the patient list stored on the hub would not be available in this case.

Table 3.

Characteristics in the form of advantages [+] and disadvantages [–] of client-server (with medAL-hub) and standalone (without medAL-hub) modes of IT deployment

Client-server

[+] Possible to access and update a medical case on multiple tablets (task-shifting; patient history) [+] One sim card (for router) is needed per health facility – easier to manage and maintain [+] Tablet storage (and clearing storage for troubleshooting) is not an issue [+] More reliable in terms of data storage (PostgreSQL) [–] High dependency on power supply (including with back-up battery or UPS) [–] Higher complexity requires more advanced IT skills to set up, maintain and troubleshoot

Standalone

[+] Low dependency on power supply (power bank is sufficient to charge the tablet) [–] Tablet storage can become an issue as medical cases accumulate [–] If clearing storage is needed for trouble-shooting purposes, all patient history is lost as well [–] Patient history is stored in one tablet (problematic in health facilities with multiple consultation rooms) [–] Multiple sim cards (or – network) needed for syncing if multiple tablets are used in a health facility

Web-based medAL-reader

Toward the end of the project, we developed a web-based interface of medAL-reader, driven by two main factors. First, maintaining the technology behind the tablet-based medAL-reader had become increasingly costly. Keeping up with Google’s and Apple’s requirements needs both funding and highly specialized expertise. Second, our goal was to create a demonstrator to showcase how algorithms developed in medAL-suite can be integrated into web-based systems, namely electronic medical records (EMR). While not all features have been re-implemented in the web-based reader yet, this version provides a straightforward way for technical teams to explore potential integrations. It is easily accessible, requires no enrollment (as tablets do), and serves as a convenient tool for testing clinical algorithms. Like the tablet-based version, web-based medAL-reader consumes the JSON output of medAL-creator. Developed using the Laravel framework, this tool leverages the Livewire package to enhance the user experience. The application runs on a NGINX server.

Implementation status

Since its development, the medAL-suite has been used to digitalize complex primary care guidelines and deployed in large-scale clinical studies in Tanzania, Rwanda, Kenya, Senegal, and India. The main evaluation of the medAL-suite and associated algorithm content for diagnosing and treating children under the age of 15 years in outpatient primary healthcare settings is the DYNAMIC study conducted in Tanzania and Rwanda in 2021–2023. The study introduced a complex algorithm with 200 + diagnoses [16, 17] to routine healthcare providers in 40 primary health facilities in Tanzania and 32 in Rwanda, and evaluated its impact on quality of care, antibiotic prescriptions, and clinical outcomes using pragmatic clinical trials.

The studies followed strict ethical protocols; informed consent was obtained from over 100,000 participants and patient data collected in medAL-reader by healthcare providers were securely stored on in-country servers. The DYNAMIC Tanzania study demonstrated a significant reduction in overall antibiotic prescriptions (from 70.1% in the control group to 23.2% in the intervention group) without compromising clinical cure rates [11]. An ancillary study showed improvements in the quality of care. The mean proportion of major symptoms and signs assessed during consultations increased from 26.3% in the control arm to 46.4% in the intervention arm. Appropriate antibiotic prescription also increased from 51.4% to 81.9% due to the intervention [18]. The DYNAMIC Rwanda study found very similar results; although the findings are yet to be published. The uptake of the medAL-suite based CDSS in both countries was around 75%, which is relatively high for a routine healthcare setting. Issues with power supply, IT infrastructure, or software presented relatively minor challenges for the implementation of the project; for example, in the Rwanda study < 1% of health facility days were affected. At the end of the project (December 2024), the medAL-suite based CDSS was deployed in 60 health facilities in Tanzania and 39 in Rwanda, with over 300,000 pediatric outpatient consultations completed to date. Discussions with national IT departments in both countries are ongoing on how to integrate the medAL-suite, and namely the capability of using medAL-creator to deploy algorithms in EMR software, into the national digital health blueprints.

Discussion

The primary goal of many digital health technologies is to enable clinicians to provide better services at the point-of-care. Clinical decision support is among the key functionalities of digital technologies aimed at impacting the quality of healthcare. The medAL-suite was created to deliver on this primary goal [19], focusing on democratized development, process-centric design, point-of-care utility, touch-screen interface, low cost, and low power consumption. These themes aim to create sustainable digital systems that enhance healthcare delivery and outcomes in low-resource environments by aligning better with their specific needs and resource constraints.

First, by design, medAL-creator is process- and guideline-centric, prioritizing the actual workflows and clinical guidelines involved in delivering healthcare, rather than focusing on data collection and administrative tasks such as billing. It further aims to democratize the clinical decision support development process by putting clinical content creation primarily in the hands of clinicians rather than IT specialists. By transforming complex code into graphical representations, decision logic becomes more comprehensible and easily modifiable by those who are closest to its utilization. Reducing the need for clinicians and software developers to find a common language to understand clinical and technical requirements increases the speed of content development and adaptation and has the potential to reduce errors. Second, medAL-reader is intended for use at the point-of-care on touch-screen devices to facilitate an intuitive user experience. Third, low-cost and low-power technologies are prioritized in the deployment, particularly by using Raspberry Pis in the client-server configuration.

As we have seen in the DYNAMIC project, by allowing clinical logic to be visualized and edited through medAL-creator, the system has empowered healthcare providers to adapt the decision support logic to their specific contexts, thereby enhancing relevance and improving adherence. Despite its advantages, medAL-creator also has some limitations and areas for future development. From a technical standpoint, medAL-creator’s approach to individual decision trees means that users need to mentally track multiple diagrams to identify potential conflicts among them. Additionally, this structure does not allow for viewing the algorithm from start to finish, potentially hindering a holistic view of the diagnostic process. Another consideration is that while a diagram can contain one or more diagnoses, each diagnosis still requires a separate treatment diagram.

From the sustainability standpoint, priority axes of focus for development include interoperability, scalability, and dynamic algorithms. The development of a clinical content authoring tool that enables programs to manage, exchange, validate, and implement digital clinical guidelines, accessible by any point-of-care system, appears to be the optimal solution for accommodating the needs of diverse local settings. As implementation of EMRs becomes more commonplace, it is critical to consider integration of clinical decision support within these systems. We developed the web-based medAL-reader to move in this direction. The lack of integration maturity between primary systems such as EMRs and reporting systems such as District Health Information System 2 (DHIS2) also means manual data entry and extraction from paper files and registries and/or double data entry into multiple digital systems, introducing additional burden for healthcare providers. While simple decision logic can be programmed directly in EMR software such as OpenMRS, Bahmni, ERPNext, etc., a tool like medAL-creator can help with authoring complex logic that can be integrated into the medical record workflow through APIs, custom development, HL7/CQL, etc.

Interoperability: At this stage, medAL-suite does not yet support interoperability standards. However, assessments have been conducted to explore ways to convert medAL-creator outputs into HL7/FHIR/CQL standards. Some proof-of-concept work to integrate medAL-suite and ERPNext via the web-based medAL-reader has been completed. Adopting standards and best practices such as HL7/FHIR, HL7/CQL, and mapping data elements and clinical concepts to standard terminologies such as Open Concept Lab (OCL) will empower CDSS implementers to use medAL-creator for creating and adapting content based on local or WHO standard digital clinical guidelines. This interoperability is crucial for integrating systems, allowing authors to develop clinically secure and transparent algorithms. Consequently, it enables scalability across various environments without the need for extensive customization by creating sharable content.

Scalability: Using a central authoring tool such as medAL-creator empowers governments and local authorities to determine their desired deployment strategies. This approach reduces dependence on external entities and infrastructure, with the only requirement being the ability to use the output from the authoring tool in their own front-end application deployed at the point of service (e.g., EMR). The web-based medAL-reader was developed as a proof of concept to demonstrate this type of integration.

Dynamic algorithms: At present, medAL-suite supports the creation and deployment of knowledge-based CDSS that derive the decision based on a set of pre-defined rules, as opposed to non-knowledge based CDSS that model the decision based on available data [20]. However, the vast data collected through the medAL-suite presents a significant opportunity to leverage it to enhance algorithm performance and personalization. By applying advanced analytics, such as Modular Clinical Decision Support Networks (MoDN) – a novel decision tree composed of flexible neural network modules to facilitate diagnostic predictions [21], the medAL-suite could potentially move beyond the typical knowledge-based “one-size-fits-all” approach, adapting more dynamically to patient-specific factors and local epidemiological trends.

Conclusion

The medAL-suite is a useful clinician-centric technology aimed at increasing the speed and transparency with which digital clinical decision support systems are implemented. As the tool evolves, the emphasis will remain on adaptations that not only meet the current demands of healthcare providers but also anticipate future challenges and opportunities in global health. With a commitment to innovation, interoperability, and impact, the medAL-suite can play a significant role in transforming healthcare delivery in low-resource settings, in line with the vision of an ecosystem of digital tools that respond to changing treatment guidelines and plug into standards-based health records that support the patient over time and across health system interactions [22].

Author contributions

LGC, VF, RT, AV, FB, SS, IEM, GAL, LC, KK, VDA, AVK were involved in the conceptualization of the software. VF, AV, EB, AF, QG, SU, SS, IEM, JT developed the software. LGC, VF, RT, AV, FB, EB, AF, QG, SU, SS, IEM, PA, EK, GAL, MN, SR, AM, LC, AVK tested features and provided feedback throughout product development and implementation in the target countries. LGC, VF and AVK drafted the manuscript. All authors provided substantive review and feedback and agreed to the publication of the manuscript.

Funding

Open access funding provided by University of Basel

Data availability

No, I do not have any research data outside the submitted manuscript file.

Software availability and requirements: software home page: < https://medal-suite.com/>; license: MIT License (SPDX:MIT); programming language(s) – Rails (medAL-creator), React native (medAL-reader), Laravel (medAL-data, medAL-hub, web-based medAL-reader).

Declarations

Ethics approval and consent to participate

Not applicable.

Consent for publication

All coauthors have provided consent for publication.

Competing interests

The authors have no competing interests.