Hybrid Artificial Intelligence and Large Language Model-Based Digital Health Platform for Personalized Diabetes Self-Management and Patient Engagement

1. Introduction

The global pervasiveness of diabetes has already reached epidemic proportions and the condition is mostly categorized into several types, the most common being Type 1 Diabetes which is an autoimmune disorder; Type 2 Diabetes which is an insulin resistance disorder and finally Gestational Diabetes which is a disease that occurs during pregnancy. The management of these types is very different; Type 1 diabetes is treated with intensive insulin therapy and careful counting of carbohydrates since the diagnosis of the disease, whereas Type 2 diabetes management is usually initiated with lifestyle changes and oral antidiabetic drugs, which is later supplemented with insulin therapy over time [1]. This imbalance of the treatment course describes the absence of a uniform way of teaching. Without proper care, chronic hyperglycemia might cause excessive and debilitating problems in the systems of all organs such as cardiovascular diseases, nephropathy, neuropathy, and retinopathy when left unattended and uncontrolled [2].

Diabetes is imposing an astronomic financial strain to the world health systems. The fundamental basis of management is Diabetes Self-Management and Support (DSMS). However, there is a very low compliance with these programs in history. Mathematically, the dependence of patient adherence on time (which is referred to as patient adherence) is often modeled as a time-dependent decaying function of cognitive load (patient adherence) and motivation:

$$\mathcal{A}\left(t\right)={\mathcal{A}}_0·e^{-\lambda t}·{\displaystyle \frac{\mathcal{M}\left(t\right)}{\mathcal{L}\left(t\right)}}$$

(1)

where $\lambda$ is the natural attrition rate, traditional educational practices elevate both and cannot sustain therefore leading to diabetes related distress and burn out. This is further augmented by the fact that there is a lot of cognitive load involved in daily activities (calculation of carbohydrate to insulin ratio and the need to make constant adjustments depending on the level of activity) is involved) [3]. This exhaustion of making decisions is an unrelenting element which results in non-adherence since patients are overworked.

To eliminate these challenges, a range of mobile health (mHealth) applications and structured learning, such as X-PERT and DESMOND have been developed [4]. However, many mHealth solutions remain limited to the features of data logging and only provide informational content that is not dynamic and interactive as far as its educational value is concerned over time [5]. This leads to an apparent Utility Gap within the current environment where offerings are either (1) Data Loggers, which have data silos and provide limited learning opportunities, (2) Static Libraries, which are not personalized and adaptive. The existing ecosystems are also limited with low interoperability; patient-generated data is also often isolated and not easily integrated with electronic health records (EHRs), preventing the creation of a comprehensive picture of the patient journey.

These constraints, along with the strong personalization of educational requirements of individuals with diabetes, inspired the creation of the AIDCare Diabetes Self-Management Platform [6]. AIDCare is developed as the multifunctional digital ecosystem including personalized self-management, interaction, and intelligent support for type 1, type 2 and gestational diabetes patients. Although the overall platform includes the aspects of diet, exercise, and risk analysis, in this paper, the attention will be paid to the design and technical validation of the self-management, personalization and gamification Module. It should be stressed that this research is not a set of clinical trials, actual patient testing and clinical validation of a result.

The system has a hybrid rule-based and LLM-driven architecture that allows balancing between safety and personalization. Our research objective is to maximize the personalization function $P\left(u\right)$ for a user u, subject to a hard constraint on recommendation safety:

$$\underset{\theta }{max}{\mathbb{E}}_{u\sim \mathcal{U}}\left[P(u;{\theta }_{LLM})\right]\mathrm{s}.\mathrm{t}.\mathrm{Risk}\left(Output\right)<ϵ$$

(2)

where ${\theta }_{LLM}$ represents the parameters of the Large Language Model. While LLMs provide remarkable personalization functionalities, their probabilistically modeled nature produces risks that are unsuitable for unconstrained medical advice generation. This hybrid formulation is evaluated under controlled, synthetic scenarios to assess functional correctness, consistency, and system-level reliability.

Figure 1. Conceptual comparison of existing diabetes self-management solutions with our work

Figure 1. Conceptual comparison of existing diabetes self-management solutions with our work

Specifically, the key contributions of this paper include (1) the designing of a novel hybrid recommendation engine that integrates deterministic rule-based logic ($R_{rule}$) with a fine-tuned Large Language Model ($R_{LLM}$) to ensure safety-aware personalization within a synthetic evaluation setting. (2) An LLM-based external resource retrieval subsystem and a multi-modal AI assistant to provide adaptive, on-demand personalization support. (3) A structured and flexible content framework with dynamic learning paths, developed through expert-informed design and validated at the system level using synthetic data. (4) The integration of gamification elements and progress tracking driving factors to enhance and sustain long-term user engagements.

The importance of the research work is that it helps to change the current trends in the field of diabetes self-management as a one-size-fits-all paradigm and make it an adaptive, engaging, and personalized digital experience. This work presents a framework of an underlying architecture that can be developed and clinically tested in the future by positioning the system as a technically validated proof-of-concept. The suggested framework can be generalized and used to design AI and gamification-based interventions in other chronic diseases. The rest of this paper is structured in the following way. Section II is a review of the related literature on mHealth-based diabetes education and AI-driven personalization. Section III covers the architecture and methodological aspects. Section IV includes quantitative and qualitative results on the basis of the synthetic assessment. Section V covers discussions and Section VI provides the conclusion of the paper.

2. Related Work

2.1. mHealth Platforms for Diabetes Self-Management

The proliferation of smartphones has led to the development of numerous mHealth applications to assist patients with diabetes self-management in smart healthcare [7,8]. Early and contemporary systems primarily serve as digital logbooks for tracking key metrics such as blood glucose, diet, and physical activity [9,10]. These tools are useful in the collection and monitoring of data, although the systematic review has resulted in mixed outcomes in the long-term clinical outcomes, frequently referencing the high rates of user attrition as a significant reason. One of the main causes of this is the fact that they frequently do not have advanced and versatile educational elements. Their material is often static, and it does not adapt the educational experience to the individual clinical situation, level of knowledge, or changing needs of the user.

It has been demonstrated that this one-size-fits-all strategy can restrict long-term user interaction and, as a result, clinical influence. Moreover, numerous available platforms have issues connected to usability and data integrity [11]. The inappropriateness of user interfaces may pose a serious adoption obstacle, especially to older adults or less digitally literate people, who are one of the target populations of Type 2 diabetes [12,13]. Furthermore, complex variables such as dietary intake are filled with a high risk of inaccuracy when entering the data manually, which restricts the usefulness of the data to the patient and their care team members [14]. The AIDCare platform aims to address these problems through the combination of user-friendly design principles and AI-driven capabilities. A comparative analysis of basic and advanced features of leading mHealth applications, including FatSecret [15], MyFitnessPal [16], and Virtuagym [17], is presented in Table 1. This analysis highlights key limitations in existing platforms, thereby identifying the gaps that AIDCare aims to address.

2.2. Personalization Techniques in Healthcare

The need for a personalized approach to the management of chronic diseases is not new, with studies showing better outcomes when care is tailored to the individual being treated [18]. Personalization in the digital world has been pursued using a number of methods each having its own strengths and weaknesses in a clinical setting. The clinical reliability and transparency of rule-based systems, which are based on expert-defined logic which in many cases can be found in clinical practice guidelines, is high [19]. But they are fundamentally fixed and unable to adapt to subtle user data not included in a set of rules, and thus they need manual upkeep to keep up with the changing medical knowledge.

Conversely, more dynamic recommendations can be offered through recommender systems based on collaborative or content-based filtering systems can provide more dynamic suggestions [20]. But there is a problem with their use in healthcare. Our engine goes beyond these traditional models by executing a hybrid engine, which combines the safety of rule-based logic with the semantic understanding of LLMs. The novelty of our approach lies in this specific combination, which leverages the LLM to interpret unstructured patient data (e.g., lifestyle habits) and match it to relevant content, while the rule-based engine enforces strict clinical safety protocols based on structured data (e.g., lab values). A summary of these techniques is presented in Table 2.

The emergence of robust LLMs has introduced new standards for patient-facing healthcare applications specifically related to diabetes management. Contemporary studies have identified LLM potential as interactive mediums [21,22] and for providing empathetic, on-demand self-management support. But, on the other hand, their use in a medical field requires very careful oversight. On of the major problem with LLM-based solutions is the potential for "hallucinations" means the generation of convincing but factually incorrect information. The false information is unacceptable in a medical context as it is directly impact the lifestyle of the patient [23]. Our system handles these issues through a multi-pronged strategy: meticulous prompt engineering with strict safety barrier that stops the generation of medical advice; a system architecture that uses LLMs to recommend existing, pre-vetted content rather than generating new content; and ensuring patient privacy by only sending anonymized, relevant information to the models.

In parallel, gamification has been widely accepted as an adequate approach for increasing motivation, engagement, and adherence in health-related applications [24]. Compelling gamification moves beyond trivial "pointsification" and is often grounded in behavioral theories like Self-Determination Theory [25]. This assumption recommends that motivation is enhanced by supporting an individual’s innate needs for self-determination, competence, and relatedness. Our platform’s gamification part is designed with these principles as baseline: providing choices in learning paths supports autonomy, earning badges, and tracking progress advances a sense of competence.

2.3. Identified Research Gaps

The review of the literature and applications available in the market shows that the existing digital diabetes solutions have a number of substantive gaps that restrict their effectiveness. Simply put, these loopholes point to the major opportunities that the current study with the assistance of the AIDCare personalized self-management of diabetes module seek to fill in, as explained in Table 3. All these gaps suggest that an all-inclusive and innovative platform should be developed.

3. Methodology

AIDCare diabetes self-management module was developed and tested as a proof-of-concept and tested under a controlled synthetic protocol to validate it technically. The methodology includes a description of system architecture design and the creation of an expert-reviewed diabetes self-management content. It also outlines the implementation of the main AI aspects (the hybrid recommendation engine and multimodal assistant), the combination of a user engagement model (gamification and progress monitoring), and the expert-guided verification process applied to evaluate the agreement with the recommendations in synthetic patient settings.

3.1. System Architecture

The platform’s architecture consists of 3 primary components: (1) a mobile front-end application, (2) a back-end server, and (3) an AI engine. Communication between these components is facilitated by a RESTful API over Hypertext Transfer Protocol (HTTP). Mathematically, we model the system output $\mathcal{T}$ as a function of request latency L and concurrency C, constrained by the bandwidth B: $\mathcal{T}=min(B,{\displaystyle \frac{C}{L_{net}+L_{proc}}})$, where $L_{net}$ is network latency and $L_{proc}$ is server processing time.

Moreover, system reliability $R\left(t\right)$ over a time interval t is modeled as a Poisson process given a failure rate $\lambda$: $R\left(t\right)=e^{-{\int }_0^t\lambda \left(\tau \right)d\tau }$. The back-end server manages user data, business logic, and communication between the mobile client and the AI engine. The AI engine houses the copious machine learning models and LLM integrations answerable for delivering personalized self-management content and support, including recommendations and algorithmic risk estimation outputs within a synthetic evaluation setting.

The Figure 2 illustrates the system architecture of the AIDCare diabetes self-management module, along with its data flows, key components, and the interactions between those key components. The architecture of the system consists of three main components: the Mobile Application, the Back-End Server, and the AI Engine. All of these components communicate via Hypertext Transfer Protocol (HTTP), which is also used to connect with the central database of the platform. The back-end server manages user data and facilitates communication between the mobile application and the AI engine by serving as the middleman. It also ensures the secure transmission and processing of the user requests.

3.2. Generation of Personalized Content for Diabetic Patients

A foundational step in content generation was the creation of structured, evidence-based "learning paths". These paths were designed in collaboration with diabetes specialist nurses from the Kocaeli University Hospital’s Diabetes Clinic to mirror the education provided to newly diagnosed patients. This collaboration is reported as expert input for content design and does not constitute clinical validation via patient outcomes. Specific paths were developed for Type 1, Type 2, and Gestational Diabetes.

Mathematically, we defined each learning path as a Directed Acyclic Graph (DAG) $G=(V,E)$, where $V=\{v_1,v_2,\dots ,v_n\}$ shows the set of educational modules and $E\subseteq V\times V$ stands for the essential dependency constraints. A valid learning sequence $S=(s_1,s_2,\dots ,s_k)$ for a user must appease the topological ordering condition:

$$\forall (v_i,v_j)\in E,\mathrm{index}\left(v_i\right)<\mathrm{index}\left(v_j\right)\mathrm{in}\mathrm{sequence}S$$

(3)

We also defined the optimal path traversal ${\mathcal{P}}^{*}$ as the minimization of the cognitive load cost function $C(u,v)$ over the graph as:

$${\mathcal{P}}^{*}=arg\underset{p\in {\mathcal{P}}_G}{min}{\displaystyle \sum _{i=1}^{\left|p\right|-1}}C(v_i,v_{i+1})·{\omega }_{user}$$

(4)

These clinician-designed paths were then converted into a unified graph structure, shown in Figure 3, which served as the blueprint for diabetes self-management. A JSON-based data structure was implemented on the back-end to manage these paths programmatically.

The learning content was developed based on the H5P Framework [26] that had been selected due to its simplicity in terms of usage and overall functionality in the creation of interactive learning resources. The main benefit of this choice was the power it gave to healthcare practitioners, the subject-matter experts, to create and update diabetes-related content. The solution made the content development process simpler, reduced the dependence on the software developers to update the content.

The H5P content of various diabetes self-management was utilized as:

• Textual Content: A copy of the official guidelines published by the official bodies, like the Turkish Diabetes Foundation and the Endocrinology and Metabolism Association of Turkey.
• Expert-Generated Clinical Content: This is obtained via a partner healthcare expert based at Kocaeli University Hospital.
• Quizzes and Assessments: Developed by combining knowledge of various online sources, with the assistance of Google and its Gemini pro, and then reviewed for factual consistency by domain experts.
• Diabetes Games: Traditional devices used by diabetes nurses, such as playing cards, were computerized, and their game versions were complemented with new game concepts to enhance the engagement of the learners.

All developed content underwent expert review for clarity, engagement, and guideline consistency, serving as a pre-deployment quality assurance step. The feedback indicated that initial content created using the “Course Presentation” type was considered “too boring” and “not diverse enough”. A concern was also raised that placeholder videos used during the development phase could lead to copyright issues upon publication. In response to this expert feedback, the requested changes were implemented.

3.3. Development of of Parsing Engine

We parsed the H5P content by developing our own H5P parser on the backend side. The backend server takes an H5P compressed file as input, parses the data through our designed backend logic in ASP.Net and JavaScript’s H5P rendering engine. After parsing the data is normalized using the second standard form (2NF) to remove duplications present in the data. The development of H5P parser engine added an additional novelty to the proposed methodology.

3.4. Creation of the Hybrid Recommendation Engine

3.4.1. Engine Architecture

A hybrid architecture was deliberately chosen to balance clinical safety and adaptive intelligence. The rule-based layer provides a deterministic and auditable foundation based on established clinical guidelines, while the LLM layer offers the flexibility to interpret nuanced, unstructured patient data that rules cannot easily capture. The dual-layer architecture is shown in Figure 4.

3.4.2. Rule-Based Component

The first layer is a deterministic system that recommends content by applying predefined rules to a user’s structured health data. The logic is based on guideline-backed clinical thresholds for five key variables, detailed in Table 4. Let $\mathcal{U}$ be the universe of patient profiles and $\mathcal{C}$ be the set of content modules. The rule-based engine describes a mapping function $f_R:\mathcal{U}\to \mathcal{P}\left(\mathcal{C}\right)$ based on a set of logical implications $\Lambda =\{{\lambda }_1,\dots ,{\lambda }_m\}$, where each rule ${\lambda }_k$ is defined using the Heaviside step function $H\left(x\right)$:

$${\lambda }_k:H(\mathrm{val}\left(u\right)-{\tau }_{thresh})=1\Rightarrow \mathrm{Recommend}\left(c_k\right)$$

(5)

When a user’s data exceeds a threshold, our engine uses associated keywords to recommend relevant modules. The rules are stored in an external JSON file, allowing clinicians to modify them without code changes. In the absence of clinical deployment, this auditability provides a verifiable safety anchor within the synthetic evaluation protocol.

3.4.3. LLM-Based Component

The second layer addresses unstructured data, such as dietary habits and exercise routines. This engine uses an open-source large language model Mistral-7B-Instruct-v0.2 available at Huggingface. The reason behind its selection is due to its advanced instruction-following capabilities and large context window and open-source availability. The probability of generating a recommendation sequence $Y=(y_1,\dots ,y_T)$ given the user context X is modeled via the autoregressive property:

$$P\left(Y\right|X)={\displaystyle \prod _{t=1}^T}P\left(y_t\right|y_{<t},X;\theta )$$

(6)

where $\theta$ represents the model parameters. The self-attention mechanism is formally defined as:

$$\mathrm{Attention}(Q,K,V)=\mathrm{softmax}\left({\displaystyle \frac{Q{K}^T}{\sqrt{d_k}}}\right)V$$

(7)

For multi-head attention with h heads, the output is defined as the concatenation of head outputs projected by $W^O$:

$$\mathrm{MultiHead}(Q,K,V)=\mathrm{Concat}({\mathrm{head}}_1,\dots ,{\mathrm{head}}_h)W^O$$

(8)

It feeds the user’s profile and a list of education titles into the LLM with a structured prompt instructing it to recommend the 5–10 most relevant topics. To ensure clinical reliability, a low temperature setting (0.2) was used to enforce high determinism. All LLM outputs are treated as recommendation candidates and are bounded by the deterministic rule layer during synthetic evaluation to reduce unsafe or inconsistent generations.

3.4.4. Fine-Tuning of the LLM-Based Recommender

In order to achieve controlled, privacy-preserving, and reproducible experimentation, a synthetic question-answer dataset was created by using the Gemini Pro API. Gemini Pro was chosen because it has a high instruction-following ability when using constrained prompts to request guideline-based queries that can be refined to the rank of relevance-based queries.

The LLM-based recommendation component was fine-tuned using supervised instruction tuning. Given an input user profile and candidate educational topics, the model learns to generate the most relevant recommendation sequence. The optimization objective follows the standard causal language modeling loss:

$$\mathcal{L}\left(\theta \right)=-{\displaystyle \sum _{t=1}^T}logP\left(y_t\right|y_{<t},X;\theta )$$

(9)

where X represents the input instruction containing user information and candidate content, $y_t$ denotes the target output token at position t, and $\theta$ represents the trainable model parameters.

All fine-tuning experiments were conducted using our lab server computer having NVIDIA RTX 5000 Ada Generation GPU with 64GB of RAM for computation. Key architectural and fine-tuning hyperparameters are listed in Table 5.

3.4.5. Recommendation Merging and Delivery

The outputs from the rule-based engine (R) and the LLM-based engine (L) are merged using a set union operation ($M=R\cup L$) to produce a single list of unique recommendations. To strictly prioritize the deterministic layer within this union, we assign a priority score $S\left(i\right)$ to each recommendation item i, calculated as:

$$S\left(i\right)=\left\{\begin{array}{cc}1.0+\psi \left(P_{LLM}\left(i\right)\right),\hfill & \mathrm{if}i\in R_{rule}\hfill \\ \psi \left(P_{LLM}\left(i\right)\right),\hfill & \mathrm{if}i\in R_{LLM}\setminus R_{rule}\hfill \end{array}\right.$$

(10)

where $P_{LLM}\left(i\right)$ represents the confidence probability score generated by the Mistral-7B model, and $\psi (·)$ is a normalization function that maps model logits to the range $[0,1)$. This ensures that any item triggered by a clinical rule ($R_{rule}$) strictly supersedes purely AI-generated suggestions. This list is then stable-sorted to prioritize the deterministic, rule-based suggestions. The final list is delivered to the mobile client via a REST API.

3.4.6. Continuous Recommendation Framework

To ensure recommendations remain current, an event-driven trigger system was implemented in the system’s backend’s “post_save” signal. The system monitors the user’s profile for changes in key clinical variables (HbA1c, LDL, etc.). This can be modeled as a discrete event simulation where state transitions $S_t\to S_{t+1}$ trigger an interrupt $\mathcal{I}$ if $\left|\right|S_{t+1}-S_t\left|\right|>\delta$, where $\delta$ is the clinical significance threshold. If a value crosses a predefined threshold, a message is published to a RabbitMQ queue, triggering a worker to re-run the recommendation process. The updated recommendations are then pushed to the client via WebSocket.

This architecture provides immediate, personalized recommendations without inefficient client-side polling and includes a noise-reduction mechanism to prevent notifications for minor, clinically insignificant fluctuations. In this paper, the correctness of triggering and notification suppression is verified via synthetic state transitions.

3.5. Gamification Mechanisms and Rationale

To support continued interaction with the personalized recommendations and educational activities generated by AIDCare, the platform incorporates a gamification layer that translates clinically appropriate self-management tasks into structured goals, progress feedback, achievement-based rewards, and interactive challenges [27,28,29]. These mechanisms are not included solely for entertainment; rather, they operationalize behavior-change strategies such as self-monitoring, goal setting, immediate feedback, positive reinforcement, and gradual mastery.

Diabetes-specific studies indicate that gamified mHealth interventions may improve selected self-care behaviors, including blood-glucose monitoring, physical activity, dietary behavior, and engagement with educational content, and may produce modest short-term improvements in glycemic control [30,31]. However, the available evidence remains heterogeneous and does not yet establish sustained clinical effectiveness totally. For this reason, gamification in AIDCare can not treated as a stand-alone therapeutic intervention but as an engagement mechanism integrated with personalized AI recommendations and the rule-based safety component. By adapting goals, challenges, and feedback to the user’s diabetes type, clinical profile, learning progress, and current recommendations, the system is designed to support perceived competence, autonomy, and task relevance rather than relying exclusively on external rewards [28,29].

This approach is also consistent with evidence showing that gamification or self-monitoring alone may be insufficient unless combined with meaningful goals, personalized feedback, usability, and clinically relevant support [32].

3.6. Evaluation Protocol and Metrics

The performance of the recommendation engine was evaluated using an expert-defined benchmark consisting of synthetic patient profiles and corresponding recommendation lists. The synthetic profiles were designed to represent diverse diabetes self-management scenarios, including variations in diabetes type, clinical indicators, lifestyle characteristics, and educational requirements. The synthetic evaluation data were generated under predefined constraints to maintain consistency with diabetes self-management guidelines and were limited to relevant educational domains, including nutrition management, glucose monitoring, insulin-related education, and lifestyle modification.

The generated recommendation outputs were compared against the expert-defined gold-standard recommendations using item-level binary relevance evaluation. Accordingly, true positives (TP), false positives (FP), and false negatives (FN) were calculated to quantify the agreement between the system-generated recommendations and the reference recommendations. Prompt constraints and low-temperature generation settings were applied during synthetic data generation to reduce stochastic variability and minimize logically inconsistent or out-of-scope scenarios. The evaluation therefore measures technical agreement with expert-defined recommendations under controlled synthetic conditions rather than real-world clinical effectiveness.

The performance of the recommendation component was assessed using Accuracy, Precision, Recall, and F1 Score. The reported TP, FP, FN, and derived metrics represent recommendation-item-level agreement within the synthetic evaluation framework and should not be interpreted as patient-level deployment performance. Table 6 presents the fine-tuning progression across 20 epochs. The reported epoch-wise metrics represent the learning behavior of the LLM-based recommendation component during supervised instruction tuning, where the model learns to generate recommendation outputs aligned with expert-defined targets.

The final F1 Score of 81% demonstrates a balance between Precision (83%) and Recall (79%) in reproducing expert-defined recommendation patterns. However, these results do not indicate clinical effectiveness, improvement in diabetes outcomes, or direct patient benefit, as no prospective clinical study or real-world user evaluation was conducted. Instead, they provide a proof-of-concept assessment of recommendation consistency and system-level feasibility under controlled synthetic conditions. A post-hoc expert review of the missed recommendations indicated that the identified false negatives (225 cases) corresponded mainly to optional educational recommendations rather than critical safety-related omissions. This review provides an additional expert-informed consistency assessment within the synthetic evaluation protocol and does not represent clinical validation.

3.7. External Resource Retrieval System

While AIDCare contains a full-fledged module of in-house educational content, external sources like open-access scientific papers, articles, and videos are proven to deliver considerable knowledge to diabetes patients. For this reason, a three-layer external recommendation sub-system is integrated into the Education Module. This subsystem uses a fine-tuned LLM with a “board-certified endocrinologist” persona to generate relevant search queries based on the user’s profile. These queries are then passed to the Google Programmable Search API and the YouTube Data API. The top results are retrieved, ranked, and presented to the user within the application. This component is designed for educational retrieval support and does not perform diagnosis, prescription, or clinical decision-making. The ranking score $\mathcal{R}$ for a retrieved document d given query q is computed as a weighted sum of textual relevance and domain authority:

$$\mathcal{R}(d,q)=\alpha ·\mathrm{sim}({\mathbf{v}}_d,{\mathbf{v}}_q)+(1-\alpha )·log\left(\mathrm{Auth}\left(d\right)\right)$$

(11)

where $\mathrm{sim}(·)$ denotes cosine similarity between the embedding vectors $\mathbf{v}$ and $\mathrm{Auth}\left(d\right)$ is a heuristic score based on domain credibility.

3.7.1. Patient Info and the LLM: Preparation

The sub-system reads the clinical variables (e.g., HbA1C, LDL) and lifestyle habits, and general health information of the user into the UserProfile table and summarizes the data. This overview is then fed to the fine-tuned LLM to produce between three and six web and YouTube search queries. The response of each call is a json_object with a maximum of five keywords or search terms, which are subsequently processed with Retrofit. The LLM is asked to assume the role of a board-certified endocrinologist with a diabetes specialty. This system specifically asks to use evidence-based sources, which eliminates personal blogs and advertisements. The model is also limited to give a pure response in the form of a pure json_object. To control scope, the persona is applied just to bias retrieval to authoritative sources of education.

3.7.2. Google Developer Search

The search queries generated by the LLM are inputted in Google Programmable Search Engine (Custom Search JSON API). The system then retrieves the top 6 results and converts them into instances of the model: specifically, external recommend ui model, which contains their titles, snippets, thumbnails and their URLs, which will be displayed to the user.

3.7.3. YouTube Data API Search

The query LLM generates on YouTube through search queries are sent to the YouTube Data API using the search.list method. The video IDs of the search results are deduplicated and their full details (including snippet, statistics and contentDetails) are fetched using the method of videos.list. The five most trending and engaged with videos are then turned into an instance of ExternalRecommendUiModel to display.

3.7.4. Merging and Presentation of Results

The results from both the web and YouTube searches are retrieved in parallel using a Kotlin Coroutine and are concatenated into a single list. This list is then serialized to JSON via the Retrofit pipeline and delivered to the mobile client. The results are rendered in a tab-based RecyclerView UI, appearing directly beneath the in-house recommendations from the hybrid engine.

3.8. Multimodal AI Assistant

In order to offer an on-demand assistant, a multimodal AI assistant was created. There is a possibility to enter text and image queries. Google Vision API is applied to label and text extraction in cases of image queries (e.g., a photo of a meal or a glucometer screen). This formatted information, together with the text prompt on the part of the user, is subsequently forwarded to the LLM that functions under stringent safety guardrails, and will not give medical diagnoses or prescriptions. The assistant is situated as a learning assistant and is checked at the system level with synthetic prompts and compliance checks with safety rules.

3.8.1. Front-End/User Interface

The chatbot has a primary display that provides five professionally vetted quick-start prompts to the user. Upon clicking on one, the chat screen is displayed and a message box, send button, image selection button, and preview section are dynamically displayed on the screen. The user can insert an image to be analyzed by the assistant by just tapping the image selection button. On clicking an image, the URI is changed into a Bitmap and shown as a preview, at the same time being changed into a Base64 format to analyze. When a prompt is sent, an asynchronous call is made to the OpenAI API, and the returned response replaces the placeholder text. Throughout this process, the user is informed of any errors via Toast messages.

3.8.2. Google Vision API Integration

If an image file is attached to the user’s prompt, a request for label and Optical Character Recognition (OCR) analysis is sent to Google Cloud Vision. The results returned from this analysis are then formatted as raw inputs for the prompt that will be sent to the fine-tuned LLM. The joint representation $h_{joint}$ combining the textual feature vector ${\mathbf{x}}_{text}$ and the visual feature vector ${\mathbf{x}}_{vision}$ is obtained via a late-fusion gating mechanism:

$$h_{joint}=\sigma ({\mathbf{W}}_t{\mathbf{x}}_{text}\oplus {\mathbf{W}}_v{\mathbf{x}}_{vision}+\mathbf{b})$$

(12)

where ⊕ denotes concatenation, $\sigma$ is the ReLU activation function, and ${\mathbf{W}}_t,{\mathbf{W}}_v$ are learnable projection matrices.

3.8.3. Response by the LLM Model

The analysis outputs from Google Cloud Vision are sent as part of a prompt, along with the user’s original text and system instructions, to the LLM. To minimize medico-legal risks, the LLM is instructed to act as a “diabetes-focused clinical assistant” that never prescribes medication or alters dosages and always recommends consulting a healthcare professional. When the LLM receives the image analysis results, it applies a decision template:

• If the image is of a medical device, such as an insulin pen or glucometer, the model offers information regarding its indications, correct use, and caution points.
• If the image is of a body part (e.g., feet or skin lesions), the model provides information about self-care routines and signs of potential complications.
• If the image or prompt is unrelated to diabetes management, the model provides a polite rejection and redirects the conversation.

To preserve user privacy and ensure HIPAA/GDPR compliance, the image is only sent to Google Cloud Vision, while the LLM receives only the extracted OCR text and labels. After a successful operation, the clinically worded response from the LLM is presented to the user. In the case of an error, the user is informed, and the interface is reset.

3.9. User Engagement Framework

3.9.1. Gamification and Profile Analytics

In order to provide long-term engagement and motivation, a full gamification system was introduced, and was backed by profile analytics system. This framework is based on an achievement and badge system where users can earn badges when they reach certain milestones defined in the central database. The system stipulates six accomplishments at this stage, such as the Consistent Learner, which is the opening of an educational module on a daily basis during 30 consecutive days (Signal: award_consistent_student_badge), or Fast Learner, which is clearing ten or more lessons in seven days (Signal: award_fast_student. Django signals that track user progress take care of business logic and when the achievement conditions are met, the corresponding record is updated in an atomic operation to ensure that race conditions are avoided.

In addition to the badge system, users get 100 points each time they complete an educational module. The cumulative user engagement score $U_{score}\left(t\right)$ at time t is formally modeled as a weighted summation of completed modules and accrued achievements:

$$\begin{array}{cc}\hfill U_{score}\left(t\right)=& {\displaystyle \sum _{k=1}^K}\left(\mathbb{I}\left(m_k\right){\displaystyle \frac{100}{n_k}}\right)\hfill \\ \hfill & +{\displaystyle \sum _{j=1}^J}\left(A_j{\omega }_j\right)\hfill \\ \hfill & +{\int }_0^t\delta \left(u_{\tau }\right)e^{-\gamma (t-\tau )}d\tau \hfill \end{array}$$

(13)

Here, $\mathbb{I}\left(m_k\right)$ is an indicator function for module completion where $n_k$ is the interaction count, $A_j$ represents the binary status of badge j with assigned weight ${\omega }_j$, and the integral term accounts for the active engagement time $\delta \left(u_{\tau }\right)$ with an exponential decay factor $\gamma$ to model engagement recency. These points contribute to a leaderboard displaying the top six users, which is generated using a PostgreSQL view named v_leaderboard and rendered in the user’s profile page.

To provide personalized feedback, a progress analytics dashboard displays three key statistics: the total number of completed lessons, total active time, and the user’s maximum login streak. This data is stored in the UsersProcess and UserModuleAccess tables and is updated by a celery task whenever a user’s completion rate changes.

3.9.2. Progress Tracking and Server Integration

It has created a lightweight, three-layered architecture which is able to track user progression on the fly, and also offer a seamless resume where you left off feature across all client platforms without having to use third-party plug-ins. The first layer, which is known as the Website Layer, is a fragment of JavaScript that is integrated in the footer of all the H5P content modules. This is a script that tracks xAPI statements, e.g., completed, and then provides a brief JSON request, where the user identifier, education identifier and rate of completion are sent to a relevant RESTful service.

The second layer, which is the Mobile Client Layer, makes the content on mobile devices. This layer uses a JavaScript bridge to provide progress information to the native application that will store these values in a local Room database eliminating the possibility of losing the information when there is intermittent connectivity. The last layer is the Server Layer, a Django REST endpoint that communicates via standard HTTP and is used to handle progress data: GET to see the last state of a user, POST to add a new module and PATCH to update the field of completion rate. The completion rate is computed itself based on a fixed-rate algorithm in which interactive educational items are only added to the sum. There are no headings and images that can change the completion percentage.

3.10. Platform Development

The modern robust technology stack that was used to architect the platform was to guarantee scalability, maintainability, and performance. The back-end server was built on the Django framework and Python and is based on the Django Rest Framework in constructing the API endpoints. Celery with a RabbitMQ message broker was used to handle asynchronous tasks, including updating user analytics. In the case of AI and machine learning, the models were created and deployed with the help of PyTorch to create the neural network, as well as scikit-learn to create data preprocessing pipelines and evaluate the model. The recommendation and assistant features were interfaced with the Hugging Face Transformers library to access the Large Language Models (LLMs).

The mobile application was created as a native android application with API level 26 and above. The network with the back-end was implemented using the Retrofit library supporting the creation of type-safe HTTP requests, the local data persistence and caching were managed by the Room persistence library to make sure that the user can receive a seamless experience even when there is no connection. PostgreSQL was used as the central database, as it is known to be reliable and hosts complicated queries. Performance sensitive components such as database views were generated effectively using complex features of the database, one of them is the real time leader board. The education module related UI screens of the AIDCare application are depicted in Figure 5.

4. Results

4.1. Quantitative Performance of the Hybrid Recommendation Engine

The primary quantitative evaluation centered on the performance of the hybrid recommendation engine. The fine-tuning operation was monitored over 20 epochs, and the model’s learning progression is illustrated in the figures. Figure 6. The figure shows the training and validation loss curves, which demonstrate stable convergence without significant overfitting. The corresponding improvement in performance is shown in Figure 7, where Accuracy, Precision, Recall, and the F1 Score all increase sharply in the initial epochs before plateauing.

To further analyze the relationships between these metrics, a correlation matrix was generated (Figure 8). The correlation matrix reveals strong negative relationships between validation loss and performance metrics, indicating that reductions in loss consistently correspond to improvements in precision, recall, and F1-score. The Pearson Correlation Coefficient ${\rho }_{X,Y}$ between any two metrics X and Y in this matrix is defined as:

$$\begin{array}{cc}\hfill {\rho }_{X,Y}=& {\displaystyle \frac{\mathbb{E}\left[(X-{\mu }_X)(Y-{\mu }_Y)\right]}{{\sigma }_X{\sigma }_Y}}\hfill \\ \hfill & ={\displaystyle \frac{{\sum }_{i=1}^n(x_i-\overline{x})(y_i-\overline{y})}{\sqrt{{\sum }_{i=1}^n{(x_i-\overline{x})}^2}\sqrt{{\sum }_{i=1}^n{(y_i-\overline{y})}^2}}}\hfill \end{array}$$

(14)

where $\sigma$ denotes the standard deviation and $\mu$ the mean of the variables.

The engine achieved a final F1 Score of 81%, with a Precision of 83% and a Recall of 79%. Accuracy followed a similar convergence trend to the F1-score, stabilizing at approximately 81% in later epochs, indicating consistent overall agreement between predicted and expert-labeled relevance decisions. The 95% Confidence Interval (CI) for the Precision metric, based on the Wilson Score Interval, is calculated as:

$$CI={\displaystyle \frac{2np+z^2\pm z\sqrt{z^2+4nq(1-p)}}{2(n+z^2)}}$$

(15)

Here, $n=5000$ denotes the total number of evaluated recommendation instances in the synthetic test set, corresponding to binary relevance decisions derived from 5000 synthetic question–answer pairs generated using Gemini Pro and compared against the expert-defined gold-standard recommendation list. The parameter p represents the observed precision, $q=1-p$, and z is the $1-{\displaystyle \frac{\alpha }{2}}$ quantile of the standard normal distribution. A post-hoc expert review indicated that the recommendations missed by the engine (225 false negatives) were clinically optional, which is reported as an expert-informed consistency check within the synthetic evaluation setting rather than a form of clinical validation.

5. Discussion

This work presented a technically validated framework for personalized diabetes self-management education and evaluated its core hybrid recommendation engine under a controlled synthetic protocol. The reported F1 score of 81% reflects agreement with an expert-defined reference set on synthetic patient profiles rather than clinical effectiveness or patient outcome improvement. At the system level, these results indicate that safety-aware personalization can be operationalized through a hybrid architecture that combines deterministic, guideline-based rules with the contextual reasoning capability of a fine-tuned large language model.

The principal contribution of this study lies in demonstrating how the complementary strengths of rule-based and LLM-based approaches can be reconciled in educational settings where reliability and auditability are critical. Although rule-based systems are more transparent and safer with regard to clinical safety, they lack the ability to adapt, and purely LLM-driven systems introduce challenges associated with verifiability and control. The proposed hybrid structure, reflects this trade-off, by grounding recommendations on expert-constructed constraints whilst promoting an adaptive meaning of the learner context within limited bounds. Application wise, the framework can be used to visualize a pathway towards more interactive and personalized diabetes education as opposed to the fixed, one-size-fits-all mHealth solutions. Even though the elements of personalization and engagement-oriented design features were not empirically evaluated in this study, the combination of personalization and engagement-oriented design features is expected to contribute to long-term learning and should be evaluated in the future with a learner-centered approach.

To clinicians, the framework is placed as an educational decision-support tool which may be used to automate routine educational guidance, but not clinical judgment. In the context of the healthcare-system, the work can be used as a reference prototype of proactive, education-driven support, with broader preventive implications, which still need to be validated in terms of prospective real-world studies.

6. Conclusion

This paper presented the design, development, and system-level evaluation of AIDCare, an AI-enabled diabetes self-management education platform designed to support personalized and adaptive learning experiences. The proposed framework integrates a safety-oriented hybrid recommendation engine that combines deterministic rule-based logic with large language model capabilities to provide individualized educational recommendations while maintaining controllability and transparency. In addition, the platform incorporates an external educational resource retrieval module, an image-enabled AI assistant, gamification mechanisms, and progress analytics to provide an integrated digital environment for diabetes self-management support.

The educational content and personalized learning pathways were developed through collaboration with healthcare professionals to ensure alignment with diabetes education principles and practical relevance. However, this expert involvement represents an expert-informed design process rather than clinical validation or evaluation of patient outcomes. The proposed recommendation engine was evaluated using controlled synthetic patient profiles and expert-defined recommendation targets, achieving an F1-score of 81.24%, with a precision of 83.5% and recall of 79.1%. These results demonstrate the capability of the proposed framework to reproduce expert-defined recommendation patterns under controlled evaluation conditions.

The findings indicate the feasibility of combining rule-based safety constraints with LLM-driven personalization for developing next-generation diabetes education platforms. Nevertheless, the reported results should not be interpreted as evidence of clinical effectiveness, improved glycemic outcomes, or real-world patient benefit, as prospective clinical studies and user-centered evaluations were beyond the scope of this work. Future research will focus on real-world deployment studies, usability assessment with individuals with diabetes and healthcare professionals, longitudinal engagement analysis, and further evaluation of safety, reliability, and clinical impact in practical healthcare settings.