A liver function data detection method and system for a high-risk liver cancer population

Abstract

The application provides a liver function data detection method and system for a high-risk population of liver cancer, relates to the field of health management, and effectively solves the false alarm and missed alarm problems caused by the lack of context information in the prior art by creating and updating a context snapshot based on a user ID in a high-speed memory cache area in real time, combining a user diagnosis type, a medication state and a medication timestamp, and differentiating liver function data based on a preset logic tree, so that the liver function data can be differentiated according to the diagnosis type and the medication state of the user in real time, false alarms and missed alarms can be effectively avoided, and the accuracy and reliability of the alarm system are improved.

Description

Technical Field

[0001] This application relates to the field of health management, and more specifically, to a method and system for detecting liver function data in high-risk groups for liver cancer. Background Technology

[0002] Traditional cloud-based health management platforms initially provide home monitoring for patients with compensated cirrhosis: users measure bilirubin daily using a portable transcutaneous bilirubin meter. The device packages the quantified bilirubin reading, timestamp, and device ID into a data frame and sends it to the platform's data receiving server via the internet. The server then parses the data and stores it in the corresponding user's time-series database to create a daily bilirubin change curve.

[0003] As the business expanded, the service recipients were extended to chronic hepatitis B patients receiving long-term antiviral therapy with nucleoside (acid) analogs. New users use the same model of testing instrument, and the data format and upload path are consistent with the existing cirrhosis user group; all data are bilirubin readings in a standardized format.

[0004] The platform has set alarm rules: if a user's bilirubin reading shows a jump exceeding a certain percentage within 24 hours, an alarm is automatically generated. Anomalies may occur after implementation: Hepatitis B patients may experience transient bilirubin elevations (manifested as steep spikes) due to antiviral drug metabolism, leading to numerous false alarms; similar spikes in cirrhosis patients may indicate acute decompensation of liver function induced by concurrent bacterial infection (requiring emergency treatment). Increasing the alarm threshold may result in missed alarms for cirrhosis users, while maintaining the original threshold may cause "alarm fatigue" for hepatitis B users and health managers due to frequent alarms.

[0005] The root of the problem lies in the fact that user diagnostic information ("compensated cirrhosis", "chronic hepatitis B (under antiviral treatment)") is stored in text form in the user information table of a relational database, while bilirubin values ​​are stored in a time-series database. The two are physically and logically separated, and the simple numerical detection program cannot associate the medical background behind the data.

[0006] However, if multiple data source resources need to be integrated, multi-source queries will cause significant delays under the requirement of millisecond-level response, which will affect the timely response to critical situations. Summary of the Invention

[0007] The purpose of this application is to provide a method and system for detecting liver function data in high-risk groups of liver cancer. This method and system can make real-time and accurate differential judgments on liver function data based on the user's diagnosis type and medication status, effectively avoiding false alarms and missed alarms, and improving the accuracy and reliability of the alarm system.

[0008] On the one hand, this application provides a method for detecting liver function data in high-risk groups for liver cancer, including:

[0009] Create a context snapshot based on the user ID in a high-speed memory cache. The context snapshot stores the diagnosis type, medication status field, and the timestamp field of the last medication record.

[0010] Deploy a change data capture mechanism in the user database, and generate a first-type event message and push it to the message queue when the diagnosis type is updated;

[0011] An event generator is deployed on the medication log server to generate a second type of event message and push it to the message queue when a user submits a medication record.

[0012] Listen to the message queue, generate a context change event, and update the context snapshot corresponding to the user ID in real time;

[0013] After receiving liver function data representing the user's liver function status, a context snapshot corresponding to the user ID is obtained; and based on the liver function data and the diagnosis type, medication status field, and last medication record timestamp field stored in the context snapshot, a preset logic tree is executed to generate differentiated response instructions.

[0014] Optionally, the steps of listening to the message queue, generating a context change event, and updating the context snapshot corresponding to the user ID in real time include:

[0015] Obtain an event batch containing multiple of the aforementioned context change events;

[0016] For multiple context change events corresponding to the same user within the event batch, the final change event is determined based on the time information of the multiple context change events; and,

[0017] The context snapshot corresponding to the user ID is updated in real time using the final change event.

[0018] Optionally, the step of obtaining a context snapshot corresponding to the user ID after receiving liver function data representing the user's liver function status, and executing a preset logic tree to generate a differentiated response instruction based on the liver function data and the diagnosis type, medication status field, and last medication record timestamp field stored in the context snapshot, includes:

[0019] From the context snapshot, retrieve the pre-stored historical trend features that characterize the long-term change trend of the user's liver function status;

[0020] Based on the liver function data, determine the instantaneous state features that characterize the current liver function status;

[0021] By combining the historical trend features, the real-time state features, and user context information in the context snapshot other than the historical trend features, a comprehensive judgment criterion is generated; and,

[0022] Based on the comprehensive judgment criteria, and based on the liver function data, the diagnosis type, medication status field, and last medication record timestamp field stored in the context snapshot, a preset logic tree is executed to generate a differentiated response instruction.

[0023] Optionally, when the context snapshot contains pre-stored historical trend features that characterize the long-term change trend of the user's liver function status, the step of listening to the message queue, generating a context change event, and updating the context snapshot corresponding to the user ID in real time includes:

[0024] Distinguish the type of the context change event to determine whether it is an immediate change event or a trend-related event;

[0025] If the context change event is the immediate change event, then update the user context information in the context snapshot except for the historical trend features;

[0026] If the context change event is a trend-related event, then the context snapshot corresponding to the user ID is updated based on the historical trend features stored in the context snapshot.

[0027] Optionally, the step of generating a comprehensive judgment criterion by combining the historical trend features, the real-time state features, and user context information in the context snapshot other than the historical trend features includes:

[0028] Based on the aforementioned real-time status characteristics, initial indication information characterizing the potential risk to the current liver function status is determined;

[0029] In response to the determination of the initial indication information, supporting information for interpreting the initial indication information is obtained from the historical trend features and the user context information in the context snapshot other than the historical trend features;

[0030] Based on the preset second operation logic, it is determined whether the supporting information and the initial indication information constitute a preset interpretation relationship, and a second determination result is obtained;

[0031] Based on the second determination result, the comprehensive judgment criteria are generated.

[0032] Optionally, the step of determining whether the supporting information and the initial indication information constitute a preset interpretation relationship based on a preset second calculation logic, and obtaining a second determination result, includes:

[0033] A basic risk score is determined for the initial indication information;

[0034] Obtain the preset interpretation weight value corresponding to the supporting evidence information;

[0035] Based on the basic risk score and the preset explanatory weight value, a comprehensive risk score is calculated;

[0036] The comprehensive risk score is compared with a preset threshold to generate the second determination result.

[0037] Optionally, the step of calculating the comprehensive risk score based on the basic risk score and the preset explanatory weight value includes:

[0038] Convert the preset interpretation weight value into a risk deduction amount;

[0039] The risk deduction amount is deducted from the basic risk score to generate the comprehensive risk score.

[0040] Optionally, the step of comparing the comprehensive risk score with a preset threshold to generate the second determination result includes:

[0041] Obtain a set of preset thresholds for defining multiple risk ranges;

[0042] Determine the risk range into which the comprehensive risk score falls among multiple risk ranges defined by the set of preset thresholds;

[0043] Based on the risk range into which the comprehensive risk score falls, a second determination result representing a specific risk level is generated.

[0044] Optionally, the preset logic tree includes the following rules:

[0045] If the diagnosis is cirrhosis and the bilirubin level in the liver function data jumps above the first threshold, an emergency alarm is triggered.

[0046] If the diagnosis is hepatitis B, the medication status is normal, and the bilirubin value in the liver function data jumps above the first threshold, ignore the alarm.

[0047] If the diagnosis is hepatitis B, the medication status is discontinued, and the bilirubin value in the liver function data jumps above the first threshold, a medium-level alarm is triggered.

[0048] On the other hand, this application provides a liver function data detection system for high-risk groups of liver cancer, the system comprising:

[0049] The snapshot creation module is used to create a context snapshot based on the user ID in a high-speed memory cache. The context snapshot stores the diagnosis type, medication status field, and the timestamp field of the last medication record.

[0050] The diagnostic event message generation module is used to deploy a change data capture mechanism in the user database. When the diagnostic type is updated, it generates the first type of event message and pushes it to the message queue.

[0051] The medication event message generation module is used to deploy an event generator on the medication log server. When a user submits a medication record, a second type of event message is generated and pushed to the message queue.

[0052] The snapshot update module is used to listen to the message queue, generate context change events, and update the context snapshot corresponding to the user ID in real time.

[0053] The instruction generation module is used to obtain a context snapshot corresponding to the user ID after receiving liver function data that represents the user's liver function status; and to generate differentiated response instructions by executing a preset logic tree based on the liver function data and the diagnosis type, medication status field, and last medication record timestamp field stored in the context snapshot.

[0054] In summary, the liver function data detection method and system provided in this application for high-risk groups of liver cancer effectively solves the problems of false alarms and missed alarms caused by the lack of context information in the prior art by creating and updating a context snapshot based on user ID in a high-speed memory cache, combining user diagnosis type, medication status and medication timestamp, and making differential judgments on liver function data based on a pre-set logic tree. Thus, it has the advantages of being able to make differential judgments on liver function data in real time and accurately according to the user's diagnosis type and medication status, effectively avoiding false alarms and missed alarms, and improving the accuracy and reliability of the alarm system. Attached Figure Description

[0055] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 The following is an exemplary flowchart illustrating a method for detecting liver function data in a high-risk group for liver cancer.

[0057] Figure 2 The diagram illustrates a module configuration block diagram of a liver function data detection system for high-risk groups of liver cancer in an embodiment.

[0058] Figure labels: 100, Liver function data detection system for high-risk groups of liver cancer; 10, Snapshot creation module; 20, Diagnostic event message generation module; 30, Medication event message generation module; 40, Snapshot update module; 50, Instruction generation module. Detailed Implementation

[0059] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0060] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0061] Traditional cloud-based health management platforms often struggle to accurately assess the clinical significance of liver function data that cannot be distinguished numerically, such as a sharp increase in bilirubin. This is primarily because key diagnostic data, including user diagnosis information and medication records, are stored in multiple physically isolated databases. This necessitates cross-database queries during assessment, introducing significant query latency. This latency prevents the system from automatically and accurately identifying events and initiating pre-defined, differentiated response procedures tailored to the assessment results within a very short timeframe.

[0062] For example, suppose a cloud-based health management platform serves both patients with cirrhosis and patients with chronic hepatitis B. The platform continuously receives bilirubin data streams from both types of users. These data may exhibit the same "peak" pattern in numerical form, such as a bilirubin reading rapidly jumping from 15 μmol / L to 35 μmol / L within two days. For patients with cirrhosis, this peak may indicate acute decompensation of liver function, requiring emergency medical intervention; while for hepatitis B patients undergoing antiviral treatment, this may be transient "therapeutic jaundice," a sign that the medication is taking effect and requires no intervention. However, the platform's data monitoring program can only identify numerical changes and cannot directly obtain the user's diagnosis type or medication status. The user's diagnosis information is stored in a relational database user profile table, daily bilirubin values ​​are stored in a time-series database, and medication attendance records are stored on a separate log server. When a bilirubin peak event occurs, it is necessary to query these three physically isolated databases separately based on the user ID to obtain complete contextual information (diagnosis type, medication status, and last medication record timestamp) in order to make a correct judgment. Such multi-source queries, under millisecond-level response requirements, will cause significant delays, affecting the system's timely response to critical situations.

[0063] If the aforementioned issues are not addressed, the platform will continue to face the risk of numerous false alarms or missed alarms. For hepatitis B users, frequent false alarms can lead to "alarm fatigue," reducing user trust in the platform's alarm system and increasing the unproductive workload of health managers. More seriously, raising the alarm threshold to avoid false alarms could result in fatal missed alarms for critical conditions in patients with cirrhosis, delaying medical intervention and causing irreversible damage to users' health. Furthermore, due to query delays, even if a final judgment can be made, it may not meet the demand for real-time monitoring and response to the liver function status of high-risk groups, thus affecting the platform's overall service quality and user experience.

[0064] like Figure 1 The image illustrates an optimized method for detecting liver function data in high-risk groups for liver cancer. This application proposes a method for detecting liver function data in high-risk groups for liver cancer, comprising:

[0065] S10, Create a context snapshot based on user ID in the high-speed memory cache. The context snapshot stores the diagnosis type, medication status field, and last medication record timestamp field.

[0066] S20, Deploy a change data capture mechanism in the user database, and generate a first-type event message and push it to the message queue when the diagnosis type is updated;

[0067] S30, Deploy an event generator on the medication log server to generate a second type of event message and push it to the message queue when a user submits a medication record;

[0068] S40, listen to the message queue, generate a context change event and update the context snapshot corresponding to the user ID in real time;

[0069] S50: After receiving liver function data representing the user's liver function status, obtain a context snapshot corresponding to the user ID; and based on the liver function data and the diagnosis type, medication status field, and last medication record timestamp field stored in the context snapshot, execute a preset logic tree to generate a differentiated response instruction.

[0070] High-speed memory cache is a storage medium that provides extremely low data access latency. Specifically, it can be a cache area in random access memory (RAM), CPU cache, or solid-state drive. It supports rapid retrieval of user context information.

[0071] A context snapshot is a data structure that captures and stores key user information at a specific point in time. It can be in the form of key-value pairs, structures, or objects, and is used to encapsulate a user's diagnosis type, medication status field, and last medication record timestamp field, providing a centralized, real-time, and easily accessible view of the user's status, avoiding multi-source queries on each data check.

[0072] The diagnosis type refers to the category of disease the user has been diagnosed with, such as cirrhosis or chronic hepatitis B. Its purpose is to serve as an important basis for determining the clinical significance of liver function data and to differentiate changes in liver function under different pathological backgrounds.

[0073] The medication status field indicates the user's current medication status, such as taking medication regularly, stopping medication, or not taking medication. Its purpose is to reflect the impact of the user's medication behavior on the interpretation of liver function data, especially in distinguishing between drug response and disease progression.

[0074] The last medication record timestamp field refers to the specific time when the user last submitted a medication record. It can provide a time reference for medication behavior and help determine the correlation between changes in liver function data and medication behavior.

[0075] In some embodiments, the change data capture mechanism is a system or technology that can monitor and capture data changes in a data source in real time, ensuring that change events can be generated and transmitted in a timely manner when diagnostic types in the user database are updated.

[0076] An event generator is a component that generates structured event messages based on specific business operations (such as a user submitting medication records). It can be event-triggered logic in application code or a standalone microservice. Its purpose is to transform medication use behavior into event messages that can be processed by the system.

[0077] Message queues are middleware used to pass messages between components in a distributed system. They can be software like Kafka, RabbitMQ, or ActiveMQ, providing asynchronous, decoupled message passing channels to ensure reliable transmission and processing of event messages, avoiding performance bottlenecks caused by direct coupling.

[0078] Among them, context change events refer to any operation or data update that causes changes in the information in the user context snapshot. These can be messages triggered by updates to the diagnosis type in the user database, submission of medication records in the medication log server, etc., and their purpose is to serve as a signal to trigger context snapshot updates.

[0079] A pre-defined logic tree is a set of rules or an algorithmic model that makes decisions based on conditional judgments. It can be a decision tree algorithm, a rule engine, or a series of nested conditional statements. It can automatically execute complex judgment logic and generate differentiated response instructions based on liver function data and user context information.

[0080] The core innovation of this application lies in creating and updating context snapshots based on user IDs in a high-speed memory cache. This efficiently integrates and preloads key user context information (such as diagnosis type, medication status field, and last medication record timestamp field) scattered across different data sources. Combined with an event-driven change capture mechanism, this overcomes the latency problem caused by cross-database queries in traditional solutions. It achieves millisecond-level accurate identification of the clinical significance behind liver function data, providing precise and differentiated responses and effectively avoiding false positives and false negatives.

[0081] This application constructs an efficient, real-time user context management and liver function data analysis system, enabling precise monitoring and differentiated responses to the liver function status of high-risk individuals for liver cancer.

[0082] First, to address the query latency issue caused by the dispersed storage of user diagnostic information and medication records across multiple physically isolated databases, the system creates and maintains a context snapshot for each user ID within a high-speed memory cache. This context snapshot centrally stores information crucial for determining the clinical significance of liver function data, including diagnosis type, medication status field, and the timestamp field of the last medication record. To ensure that the information in the context snapshot remains up-to-date, the system deploys an event-driven update mechanism.

[0083] Specifically, a change data capture mechanism is deployed in the user database. When a user's diagnosis type is updated, this mechanism immediately generates a first-type event message and pushes it to the message queue. Simultaneously, an event generator is deployed on the medication log server. When a user submits a new medication record, this generator generates a second-type event message and pushes it to the message queue as well. The message queue acts as middleware, ensuring reliable transmission and asynchronous processing of these change events. Subsequently, the message queue is continuously monitored. Once any type of event message is received, a corresponding context change event is generated based on the message content, and these events are used to update the context snapshot of the corresponding user ID in the high-speed memory cache in real time. This real-time update mechanism ensures the timeliness of the data in the context snapshot, allowing subsequent judgments to be based on the latest user status information. When liver function data representing a user's liver function status, such as bilirubin readings, is received, it no longer requires a time-consuming cross-database query. Instead, it directly and quickly retrieves the context snapshot corresponding to that user ID from the high-speed memory cache. After obtaining the liver function data and the latest context snapshot, a pre-defined logic tree is executed based on this information. The pre-defined logic tree is a predefined decision model that can make complex conditional judgments based on the specific numerical changes in liver function data, combined with the diagnosis type, medication status field, and last medication record timestamp field in the context snapshot.

[0084] For example, a spike in bilirubin in a patient with cirrhosis might trigger an emergency alert; however, the same spike in bilirubin in a hepatitis B patient taking medication normally might be identified as a benign drug response and ignored. This approach allows for the generation of differentiated response instructions, such as sending alerts at different levels, providing personalized health advice, or initiating specific medical interventions. This enables accurate identification and response to different clinical scenarios, effectively avoiding false alarms and missed alarms.

[0085] For example, a high-speed memory cache could utilize the server's DDR4 RAM to provide nanosecond-level access speeds. Context snapshots can be implemented as a JSON object containing key-value pairs such as "diagnosisType", "medicationStatus", and "lastMedicationTimestamp". For instance, a user's context snapshot might be stored as `{"userId": "user123", "diagnosisType": "Chronic Hepatitis B", "medicationStatus": "On Medication", "lastMedicationTimestamp": "2023-10-26T08:00:00Z"}`. The user profile database could be a relational database, such as MySQL. Change data capture mechanisms can leverage the database's binary log parsing tools, such as Debezium, to capture update events of the diagnosis type field in real time. When a user's diagnosis type in the user profile table is updated from "cirrhosis" to "chronic hepatitis B", Debezium captures this change and generates an event message. The medication log server can be a standalone microservice. When a user submits a "medication taken" or "medication not taken" record via a mobile application, this microservice immediately generates an event message containing the user ID, medication status, and current timestamp. The message queue can utilize an Apache Kafka cluster, providing high-throughput and low-latency message delivery capabilities. First and second type event messages are published to specific topics in Kafka. The snapshot update module can be a standalone consumer service that continuously subscribes to the Kafka message queue. Upon receiving an event message, this service parses the message content, extracts the user ID and change information, and then directly updates the context snapshot corresponding to the user ID in the high-speed in-memory cache. For example, if a medication status change event is received, it updates the "medicationStatus" and "lastMedicationTimestamp" fields in the snapshot.

[0086] Upon receiving liver function data uploaded by the user (e.g., bilirubin readings from a transcutaneous jaundice analyzer), the module first reads the corresponding context snapshot from the high-speed memory cache based on the user ID in the data. Then, the module executes a pre-built rule engine containing a series of rules based on diagnosis type, medication status, and changes in bilirubin levels. For example, one rule might be defined as: "If the diagnosis type is 'cirrhosis' and the bilirubin level jumps by more than 20 μmol / L within 24 hours, generate an 'emergency alert' command." Another rule might be: "If the diagnosis type is 'chronic hepatitis B' and the medication status is 'On Medication' and the bilirubin level jumps by more than 20 μmol / L within 24 hours, generate an 'ignore alert' command." By executing these rules, differentiated response commands can be generated based on the specific clinical context, such as sending different levels of notifications to health managers or pushing personalized health advice to users.

[0087] Through the above technical solution, this application effectively solves the problems of query latency and inaccurate judgment caused by the scattered storage of key user context information in multiple databases in existing technologies. By creating and updating context snapshots in real time in a high-speed memory cache, key information such as user diagnosis type, medication status, and the timestamp of the last medication record can be obtained with extremely low latency, thereby significantly improving the response speed of liver function data detection. The application of an event-driven change capture mechanism and message queues ensures the real-time nature of context snapshots and data consistency, avoiding misjudgments caused by information lag. Combining liver function data and real-time updated context snapshots, and executing a pre-defined logic tree, enables accurate identification of the clinical significance behind liver function data, such as distinguishing between benign drug reactions and acute liver injury. This greatly reduces unnecessary alarms and potential fatal missed detections, improves the accuracy, reliability, and efficiency of liver function monitoring in high-risk groups for liver cancer, and provides users with more personalized and precise health management services.

[0088] This application further proposes a pre-defined logic tree including the following rules:

[0089] If the diagnosis is cirrhosis and the bilirubin level in the liver function data jumps above the first threshold, an emergency alarm is triggered.

[0090] If the diagnosis is hepatitis B, the medication status is normal, and the bilirubin value in the liver function data jumps above the first threshold, ignore the alarm.

[0091] If the diagnosis is hepatitis B, the medication status is discontinued, and the bilirubin level in the liver function data jumps above the first threshold, a medium-level alarm is triggered.

[0092] By combining refined pre-defined logic tree rules with real-time updated user context information, intelligent judgment and differentiated responses to spikes in bilirubin levels in liver function data are achieved. Specifically, upon receiving liver function data representing a user's liver function status, a context snapshot corresponding to that user ID is first obtained. This context snapshot is dynamically maintained and contains key information such as the user's diagnosis type and medication status. It is precisely because the context snapshot provides immediate and accurate background information that the pre-defined logic tree can perform multi-dimensional conditional judgments based on this information.

[0093] The pre-defined logic tree operates as follows: it no longer simply triggers alarms based on whether bilirubin levels exceed a single threshold. Instead, it differentiates the clinical significance of bilirubin spikes based on the diagnosis type and medication status stored in the context snapshot. For example, if the context snapshot shows a diagnosis of cirrhosis and the bilirubin level in liver function data spikes above the first threshold, an emergency alarm will be triggered immediately. This is because a sharp increase in bilirubin in cirrhotic patients usually indicates a critical condition. Conversely, if the context snapshot shows a diagnosis of hepatitis B and the medication status is normal, an alarm will be ignored even if the bilirubin level spikes above the first threshold. This is because hepatitis B patients may experience benign therapeutic jaundice during normal medication. Furthermore, if the context snapshot shows a diagnosis of hepatitis B but the medication status is discontinued, and the bilirubin level spikes above the first threshold, a medium-level alarm will be triggered. This is because discontinuing medication may lead to viral rebound and liver damage, requiring immediate attention but less urgent than acute exacerbation of cirrhosis.

[0094] In this way, the proposed solution overcomes the limitations of traditional methods that rely solely on numerical judgment, avoiding false alarms and missed alarms caused by a lack of medical background information. It is precisely because the pre-built logic tree can perform refined classification and judgment of bilirubin value spikes based on contextual information such as real-time acquired diagnosis type and medication status that it can generate matching, differentiated response instructions for different clinical scenarios, thereby improving the accuracy and reliability of alarms.

[0095] In some preferred embodiments, this application is implemented as follows: Assume a patient with user ID "UserA" whose diagnosis type stored in the context snapshot is "cirrhosis". When the latest liver function data of UserA is received, showing that his bilirubin value jumped from 15 μmol / L to 35 μmol / L within 24 hours, the preset logic tree will first obtain UserA's diagnosis type "cirrhosis". Since the jump of 35 μmol / L relative to 15 μmol / L exceeds the preset first threshold (e.g., set to an absolute jump of 20 μmol / L or a relative jump of 100%), and the diagnosis type is cirrhosis, the preset logic tree will trigger an emergency alarm according to the first rule and generate corresponding emergency response instructions, such as sending a text message notification to the doctor or highlighting it on the management platform interface.

[0096] For example, another patient with the user ID "UserB" has a diagnosis type of "Hepatitis B" stored in their context snapshot and a medication status of "normal medication." When UserB's liver function data also shows a jump in bilirubin levels from 15 μmol / L to 35 μmol / L, exceeding the first threshold, the pre-defined logic tree will retrieve UserB's diagnosis type "Hepatitis B" and medication status "normal medication." At this point, the pre-defined logic tree will, according to the second rule, determine that this situation is highly likely to be benign therapeutic jaundice, thus ignoring the alarm and not generating any response instructions, avoiding unnecessary medical intervention and alarm fatigue.

[0097] As a specific implementation, for a patient with User ID "UserC", the diagnosis type stored in their context snapshot is "Hepatitis B" but the medication status is "discontinued". When UserC's liver function data also shows that the bilirubin level jumps from 15 μmol / L to 35 μmol / L, exceeding the first threshold, the pre-defined logic tree will retrieve UserC's diagnosis type "Hepatitis B" and medication status "discontinued". At this time, the pre-defined logic tree will determine, according to the third rule, that this situation may be liver damage caused by viral rebound after discontinuation of medication, thus triggering an intermediate alarm and generating corresponding response instructions, such as sending a reminder to the health manager, suggesting that they contact the patient for further evaluation.

[0098] The aforementioned technical solution allows for refined analysis of bilirubin spikes in liver function data based on the patient's diagnosis and medication status. This enables accurate differentiation of the significance of bilirubin elevation in different clinical contexts, avoiding false alarms for benign conditions while ensuring timely alerts for critical situations and providing appropriate reminders for less urgent cases. This significantly improves the accuracy and reliability of alerts, providing healthcare professionals with more valuable decision-making support and thus optimizing patient health management processes.

[0099] In some embodiments, the steps of listening to the message queue, generating a context change event, and updating the context snapshot corresponding to the user ID in real time include:

[0100] Retrieve an event batch containing multiple context change events;

[0101] For multiple context change events corresponding to the same user within an event batch, the final change event is determined based on the time information of the multiple context change events; and,

[0102] The context snapshot corresponding to the user ID is updated in real time using the final change event.

[0103] Among them, an event batch is a collection of context change events that are collected within a specific time window or when a specific number is reached. It can be implemented by batch reading, batch processing function of message queue, or timed aggregation, etc. The purpose is to reduce the interaction frequency with message queue and improve the throughput of data processing.

[0104] Among them, time information refers to data associated with context change events that indicates the order or validity of events. Specifically, it can be the timestamp when the event was generated, the timestamp when the event entered the message queue, or the sequence number of the event, etc. Its purpose is to provide a basis for judging the order and validity of events.

[0105] The final change event refers to the event that is determined to represent the latest or most valid state of the user among multiple context change events for the same user after judging the time information. It can be determined by comparing timestamps to select the latest event, selecting events according to business logic priorities, or merging the valid parts of multiple events. Its purpose is to ensure the accuracy and efficiency of context snapshot updates and avoid unnecessary intermediate state updates.

[0106] This application optimizes the context snapshot update process by introducing batch processing and event filtering mechanisms. Specifically, instead of processing each context change event in the message queue immediately, it first retrieves a batch of events containing multiple context change events. This batch retrieval method significantly reduces the frequency of interaction with the message queue, thereby reducing network overhead and processor context switching, laying the foundation for efficient subsequent processing. Based on this, for multiple context change events corresponding to the same user within the event batch, the final change event is determined based on the event's time information, such as the event's generation timestamp. This means that if a user experiences multiple context changes within a short period, only the event representing the user's latest state is identified and retained.

[0107] For example, if a user first updates their diagnosis type to "cirrhosis" and then later to "hepatitis B," the system determines "hepatitis B" as the final status based on the time information. This filtering mechanism avoids duplicate or invalid updates to the same user's context snapshot, effectively reducing unnecessary computation and storage operations. Ultimately, the system uses this final change event to update the context snapshot corresponding to the user ID in real time. By using only filtered final change events for snapshot updates, the system avoids frequent write operations, reduces access pressure on the high-speed memory cache, and thus improves the efficiency of snapshot updates and the overall performance of the system.

[0108] This optimized snapshot update mechanism, combined with the overall method of creating user ID-based context snapshots in a high-speed memory cache and subsequently generating differentiated response instructions based on a pre-defined logic tree executed from these snapshots, enables the entire liver function data detection method to maintain its response speed and accuracy when facing high-concurrency event streams. By reducing the frequency of snapshot updates and resource consumption, the system can provide accurate user context information more stably and promptly, thereby ensuring that subsequent liver function data analysis and the generation of differentiated response instructions are based on the latest and most concise data, thus improving the reliability and efficiency of the entire detection method.

[0109] For example, when retrieving an event batch containing multiple context change events, the system can configure a message queue consumer that pulls events in batches from the message queue at fixed intervals (e.g., every 500 milliseconds) or when the accumulated number of events reaches a preset threshold (e.g., 1000 events). These events can be temporarily stored in a memory buffer, forming an event batch. For multiple context change events corresponding to the same user within an event batch, the system can iterate through the event batch to determine the final change event based on the time information of these multiple context change events. For each event, the system can extract its user ID and event timestamp. The system can maintain a temporary mapping table where the key is the user ID, and the values ​​are the timestamp of the user's latest event and the corresponding event content. When processing a new event, if the user ID for that event already exists in the mapping table, the system can compare the timestamp of the current event with the timestamp recorded in the mapping table. If the timestamp of the current event is later, the event content and timestamp in the mapping table are updated. If the user ID does not exist, the current event and its timestamp are directly added to the mapping table. After batch traversal is complete, the value corresponding to each user ID in the mapping table is the user's final change event. For example, if user A has three events in a batch: event 1 (diagnosis type: cirrhosis, timestamp: T1), event 2 (medication status: taken, timestamp: T2), and event 3 (diagnosis type: hepatitis B, timestamp: T3), and T3 > T2 > T1, then the final change event will be event 3. When using final change events to update the context snapshot corresponding to a user ID in real time, the system can traverse all final change events in this temporary mapping table. For each final change event, the system can atomically update the context snapshot of the corresponding user ID in the high-speed memory cache. For example, Redis's HSET command or similar atomic operations can be used to ensure data integrity and consistency during the update process. If the snapshot does not exist, a new snapshot is created. If the snapshot already exists, the diagnosis type, medication status field, or last medication record timestamp field in the snapshot is updated according to the content of the final change event.

[0110] The above technical solution efficiently processes a large number of context change events in the message queue, avoiding frequent snapshot update operations for each event. By batch acquiring events and filtering multiple change events for the same user, the system significantly reduces unnecessary computation and resource consumption, lowers the access pressure on the high-speed memory cache, and thus improves the efficiency and real-time performance of context snapshot updates. This ensures that subsequent liver function data detection and differentiated response instruction generation based on context snapshots can be performed based on the latest and concise user context information, improving the performance and stability of the entire detection method.

[0111] In some embodiments, after receiving liver function data characterizing a user's liver function status, the steps of obtaining a context snapshot corresponding to the user ID and, based on the liver function data and the diagnosis type, medication status field, and last medication record timestamp field stored in the context snapshot, executing a preset logic tree to generate a differentiated response instruction include:

[0112] Retrieve pre-stored historical trend features that characterize the long-term changes in a user's liver function status from context snapshots;

[0113] Based on liver function data, determine the instantaneous state features that characterize the current liver function status;

[0114] By combining historical trend features, real-time state features, and user context information from context snapshots (excluding historical trend features), a comprehensive judgment basis is generated; and,

[0115] Based on a comprehensive judgment, and using liver function data, the diagnosis type stored in the context snapshot, the medication status field, and the timestamp field of the last medication record, a pre-set logic tree is executed to generate differentiated response instructions.

[0116] Historical trend features refer to information extracted from a user's past liver function data that reflects the long-term evolution of their liver function status. Specifically, this can be achieved by calculating and storing the average value, rate of change, and fluctuation range of liver function indicators such as bilirubin and transaminase over a period of time, or by using trend line parameters obtained through time series analysis. This provides in-depth information beyond data from a single point in time, helping the system understand whether the current liver function status is long-term stable, continuously deteriorating, or experiencing occasional fluctuations, thus providing historical context for more accurate judgments.

[0117] Real-time status features refer to key information that characterizes the user's real-time liver function level, directly extracted from the currently received liver function data. Specifically, this can be determined by obtaining the current absolute value of bilirubin, the difference from the previous measurement or baseline value, and the magnitude or rate of change within a specific time window. Its purpose is to reflect the actual status of the user's liver function at the current moment, serving as the basis for subsequent comprehensive judgment.

[0118] Historical trend characteristics, real-time status characteristics, and key user contextual information (such as diagnosis type, medication status, and last medication record timestamp) are integrated and analyzed to form a comprehensive judgment criterion. This comprehensive judgment criterion guides the unified evaluation result executed by the pre-set logic tree. Specifically, it can be a multi-dimensional vector, a risk score, or a classification label. Its purpose is to overcome the limitations of a single information source and provide a more comprehensive and accurate assessment of liver function status, thereby making subsequent differentiated response instructions more precise and effective.

[0119] This application significantly improves the accuracy of liver function status assessment and the effectiveness of response commands by incorporating consideration of long-term trends in user liver function status. Specifically, upon receiving new liver function data, the system first retrieves pre-stored historical trend features from a pre-created and real-time updated context snapshot. This mechanism benefits from the context snapshot's pre-aggregation of key information scattered across different databases (including diagnosis type, medication status, last medication record timestamp, and the newly added historical trend features) into a high-speed memory cache, thus avoiding the latency caused by traditional cross-database queries and ensuring millisecond-level response speeds. Simultaneously, based on the currently received liver function data, the system determines the immediate status features characterizing the immediate liver function status. Subsequently, the historical trend features, immediate status features, and user context information from the context snapshot (excluding historical trend features) are organically combined to generate a comprehensive judgment criterion. This comprehensive judgment criterion provides a multi-dimensional and more comprehensive view of the user's liver function status; for example, it can distinguish between benign transient jaundice caused by medication and acute liver injury caused by disease progression or discontinuation of medication. Ultimately, the pre-built logic tree, based on this more precise comprehensive judgment criterion and combined with liver function data, diagnosis type, medication status fields, and the last medication record timestamp field, performs more refined logical judgments to generate differentiated response instructions. Thus, by considering the long-term evolution and real-time changes in the user's liver function status, as well as the clinical context, it makes decisions that are more consistent with the actual situation, avoiding false alarms and missed alarms, and improving the monitoring accuracy and reliability of the health management platform.

[0120] For example, suppose a user is diagnosed with chronic hepatitis B and is receiving antiviral treatment. When the user uploads new liver function data showing a significant spike in bilirubin levels within 24 hours, the assessment process is initiated. First, the system retrieves pre-stored historical trend features from the user's context snapshot. For example, the user's bilirubin level trend over the past three months is recorded as "long-term stable, with occasional therapeutic jaundice spikes." Simultaneously, based on the currently received liver function data, the system determines the immediate status features. For example, the current bilirubin level is 35 μmol / L, a 133% increase compared to the previous day's 15 μmol / L. Next, the system combines these historical trend features and immediate status features with other user context information stored in the context snapshot (e.g., diagnosis type "chronic hepatitis B (on antiviral treatment)," medication status "normal medication," and last medication record timestamp "within the last 24 hours") to generate a comprehensive judgment criterion. This comprehensive judgment criterion might be a risk score or a classification label, such as "drug-related benign fluctuations." Finally, the pre-defined logic tree executes the corresponding rules based on this comprehensive judgment criterion of "drug-related benign fluctuations," combined with specific liver function data and contextual information. For example, if there is a rule in the logic tree: "If the diagnosis type is hepatitis B, the medication status is normal, and the comprehensive judgment criterion is drug-related benign fluctuations, then ignore the alarm," the system will ignore the alarm for this bilirubin elevation according to this rule, avoiding unnecessary interference to users and health managers.

[0121] Through the aforementioned technical solution, this application can more comprehensively and accurately assess a user's liver function status and generate more effective differentiated response instructions. This enables the differentiation of similar changes in liver function data under different clinical backgrounds; for example, it can identify benign bilirubin elevations caused by medications, while issuing timely and accurate alerts for liver function abnormalities that truly require intervention (such as acute decompensation of cirrhosis or viral rebound after drug withdrawal). Therefore, it can significantly reduce false alarms and false negatives, improve the accuracy and reliability of the health management platform's monitoring, and thus provide users with more personalized and effective health management services.

[0122] In some embodiments, when the context snapshot contains pre-stored historical trend features that characterize the long-term changing trend of a user's liver function status, the steps of listening to the message queue, generating a context change event, and updating the context snapshot corresponding to the user ID in real time include:

[0123] Distinguish the type of context change event to determine whether it is an immediate change event or a trend-related event;

[0124] If the context change event is an immediate change event, then update the user context information in the context snapshot except for historical trend features;

[0125] If the context change event is a trend-related event, then the context snapshot corresponding to the user ID is updated based on the historical trend features stored in the context snapshot.

[0126] Among them, immediate change events refer to contextual change events that have an instantaneous impact on a user's liver function status or reflect short-term behavior, but usually do not directly change or should not immediately change long-term trends. These can be daily check-ins of medication records, short-term dietary adjustment records, etc., and are used to distinguish those events that do not affect the stability of historical trend characteristics in order to avoid unnecessary updates.

[0127] Trend-related events refer to context-change events that have a substantial impact on the long-term trend of a user's liver function status and require reassessment or updating of historical trend characteristics. These events can include changes in diagnosis type, adjustments to long-term treatment plans, or the occurrence of major complications. The purpose is to identify events that require updating historical trend characteristics to ensure that they accurately reflect the long-term evolution of a user's liver function status.

[0128] This application introduces a mechanism to differentiate context change event types, enabling differentiated updates of context snapshots corresponding to user IDs.

[0129] Specifically, when the system listens to the message queue and generates a context change event, it first identifies the event type, clearly classifying it as either an immediate change event or a trend-related event. This classification forms the basis for subsequent differentiated updates. If identified as an immediate change event, such as a user's daily medication check-in record, this type of event reflects an instantaneous state or short-term behavior, having little impact on the long-term trend of the user's liver function. Therefore, the system only updates the user's context information in the context snapshot, excluding historical trend features, such as the medication status field or the timestamp field of the last medication record, thus maintaining the stability of historical trend features. Conversely, if identified as a trend-related event, such as a significant change in the user's diagnosis type, this type of event has a substantial impact on the long-term evolution of the user's liver function. In this case, it updates the historical trend features stored in the context snapshot to ensure that the historical trend features accurately reflect the latest long-term trend of the user's liver function. Through this differentiated update strategy, this application effectively avoids unnecessary interference or updates to historical trend features due to frequent, non-trend events, thereby ensuring the stability and accuracy of historical trend features. This is closely integrated with the steps in the aforementioned scheme that extract historical trend features from contextual snapshots and combine them with real-time state features and user context information to generate a comprehensive judgment basis. By ensuring the accuracy of historical trend features, this scheme provides more reliable long-term background information for the subsequent generation of comprehensive judgment basis, enabling the final judgment result to more accurately reflect the user's true liver function status, avoiding misjudgments or omissions caused by distortion of historical trend features, thereby improving the judgment accuracy and reliability of the entire liver function data detection method.

[0130] For example, suppose a user's context snapshot pre-stores the long-term trend of their liver function status. This historical trend could be a moving average calculated based on bilirubin readings over the past 90 days and its fluctuation range. When a new context change event appears in the message queue, the event is first identified. Specifically, if the received context change event is an update to the user's daily medication record, such as "medication taken" or "medication not taken," it is identified as an immediate change event. In this case, the medication status field and the last medication record timestamp field in the user's context snapshot are updated, but the pre-stored historical trend feature is not touched or modified. This ensures that daily medication records do not interfere with the calculation of the long-term trend, maintaining the stability of the historical trend feature. On the other hand, if the received context change event is a change in the user's diagnosis type, for example, a doctor updating the user's diagnosis from "chronic hepatitis B" to "cirrhosis," it is identified as a trend-related event. Since a significant change in diagnosis type directly affects the long-term assessment benchmark of the user's liver function status, this historical trend feature is recalculated or adjusted based on the historical trend feature already stored in the context snapshot, combined with the new diagnostic information. For example, a background task could be triggered to reanalyze the user's historical liver function data under the new diagnostic type, or a model optimized for the new diagnostic type could be applied to update the historical trend features, thereby ensuring that the historical trend features accurately reflect the user's long-term liver function changes under the new medical context.

[0131] By employing the aforementioned technical solution, this application effectively avoids distortion of historical trend features due to frequent updates of non-trend events by distinguishing the types of context change events and selectively updating information in the context snapshot according to the event type. This ensures that historical trend features accurately reflect the long-term changing trend of the user's liver function status. This makes the subsequent comprehensive judgment criteria generated based on historical trend features more accurate and reliable, thereby improving the accuracy of the user's liver function status assessment and reducing the occurrence of misjudgments or omissions.

[0132] In some embodiments, the step of generating a comprehensive judgment criterion by combining historical trend features, real-time state features, and user context information in the context snapshot other than historical trend features includes:

[0133] Based on real-time status characteristics, initial indications of potential risks to current liver function status are determined;

[0134] In response to the determination of the initial indication information, supporting information for interpreting the initial indication information is obtained from historical trend features and user context information other than historical trend features in the context snapshot;

[0135] Based on the preset second operation logic, it is determined whether the supporting information and the initial indication information constitute a preset interpretation relationship, and a second determination result is obtained;

[0136] Based on the second judgment result, a comprehensive judgment basis is generated.

[0137] Initial indication information refers to preliminary signals identified based on real-time state characteristics that characterize the current liver function status as potentially abnormal or at risk. These signals can be determined using methods such as threshold comparison, abnormal fluctuation detection, or pattern recognition.

[0138] Among them, corroborating information refers to auxiliary data obtained from historical trend features and user context information other than historical trend features in context snapshots, which can support, interpret or correct the initial indication information. It may include historical bilirubin change curves, medication records, diagnosis types, past medical history or lifestyle habits, etc.

[0139] The pre-defined second operational logic is a series of rules, algorithms, or models used to evaluate the correlation between supporting information and initial indication information. It can be implemented using a rule engine based on expert knowledge, a machine learning model, or a statistical analysis method.

[0140] The predefined explanatory relationship is a predefined logical connection between the initial indication information and the supporting information that can explain or modify the risk judgment. It may include causal relationship, accompanying relationship, exclusion relationship or modification relationship, etc.

[0141] This application first identifies initial indications of potential risk to the current liver function status based on immediate state characteristics. This step is the starting point of the judgment, focusing on the immediate abnormal signals revealed by the current data. Subsequently, in response to the determination of the initial indications, supporting information for interpreting the initial indications is selectively obtained from historical trend features and user context information (excluding historical trend features) in the context snapshot. This purposeful information acquisition avoids interference from irrelevant information, ensuring the efficiency and accuracy of subsequent judgments. Next, based on a pre-set second operational logic, it is determined whether the supporting information constitutes a pre-set explanatory relationship with the initial indications, thus obtaining a second judgment result. This step is the core of the solution, introducing intelligent logical judgment to verify or correct the initial risk signal, for example, determining whether the immediate risk can be reasonably explained by historical trends or specific context information. Finally, based on the second judgment result, the system generates a comprehensive judgment basis. This comprehensive judgment basis is no longer a simple summation of information, but a conclusion that has undergone in-depth logical verification and correction, and can more accurately reflect the user's true liver function status. It is precisely because of this step-by-step, verification-based judgment mechanism that this solution can overcome the misjudgment or missed judgment problems that may be caused by simple information combination in traditional methods. For example, when the immediate status features show elevated bilirubin, if the supporting information indicates that the user is taking a medication that may cause benign bilirubin elevation, and the historical trend also supports this benign change, then the system can determine that the elevation is interpretable, thereby avoiding false alarms. Conversely, if the supporting information shows that the user has stopped taking the medication without authorization, then even if the immediate bilirubin is elevated, the system can still identify its potential danger and avoid missed alarms. This in-depth verification and interpretation of immediate status features enables more accurate identification of similar data patterns under different pathological backgrounds when generating comprehensive judgment criteria, thus providing a more reliable basis for subsequent execution of pre-set logic trees to generate differentiated response instructions, significantly improving the accuracy and reliability of liver function data detection in high-risk groups for liver cancer.

[0142] In some embodiments, the step of determining whether the supporting information and the initial indication information constitute a preset interpretation relationship, and obtaining a second determination result, according to a preset second operational logic, includes:

[0143] Determine the basic risk score for the initial indication information;

[0144] Obtain the preset interpretation weight value corresponding to the supporting information;

[0145] The comprehensive risk score is calculated based on the basic risk score and the preset explanatory weight value.

[0146] The comprehensive risk score is compared with a preset threshold to generate a second judgment result.

[0147] Among them, the basic risk score refers to the numerical value that preliminarily quantifies the potential risks represented by the initial indication information. It can be determined by using a predefined risk level mapping table or by using a statistical analysis model based on historical data. Its purpose is to provide a quantitative benchmark for subsequent risk assessment.

[0148] The preset explanatory weight value is a numerical value used to measure the degree of explanation or direction of influence of supporting information on the initial indication information. It can be set by expert experience, trained by machine learning or configured based on clinical guidelines. Its purpose is to reflect the corrective effect of different supporting information on risk assessment.

[0149] The comprehensive risk score refers to the final risk quantification value obtained by combining the basic risk of the initial indication information and the explanatory role of the supporting information. It can be calculated by weighted summation, multiplication correction or based on a specific risk model. Its purpose is to provide a comprehensive and detailed risk assessment result.

[0150] Preset thresholds refer to critical values ​​used to define different risk levels or judgment results. They can be set using clinical expert consensus, statistical quantiles, or based on risk tolerance. Their purpose is to convert continuous risk scores into discrete judgment results.

[0151] This application provides an assessment benchmark by determining a basic risk score for initial indication information, thus preliminarily quantifying potential risks. Subsequently, pre-defined explanatory weights corresponding to supporting information are obtained. These weights reflect the corrective effect of different supporting information on the risk represented by the initial indication information; for example, some supporting information may reduce risk, while others may increase it. Next, based on the basic risk score and the pre-defined explanatory weights, a comprehensive risk score is calculated. This process organically combines the corrective effects of the initial risk and supporting information, forming a more comprehensive and refined risk assessment result. Finally, the comprehensive risk score is compared with a pre-defined threshold to generate a second judgment result, thereby transforming the continuous risk assessment results into a clear risk level or judgment conclusion.

[0152] The coordinated operation of this series of steps enables this solution to overcome the lack of precise quantification in risk assessment found in traditional methods. Specifically, by combining user context information such as diagnosis type, medication status, and last medication record timestamp obtained in real time through context snapshots, as well as initial indication and supporting information extracted from historical trend features and immediate status features, this solution can transform this discrete, multi-source information into a unified, quantifiable risk assessment system. For example, when immediate status features show a sharp increase in bilirubin and initial indication information is generated, the system can adjust the basic risk score based on supporting information such as whether the user is a cirrhosis patient or a hepatitis B patient, and whether they are taking medication regularly, by assigning different preset interpretation weights. This quantitative correction mechanism allows the system to move beyond simple rule matching and dynamically adjust risk assessment based on the specific circumstances of supporting information, thereby distinguishing between events with different clinical significance, such as "benign therapeutic jaundice" and "acute liver injury," effectively avoiding false alarms and false negatives, significantly improving the accuracy and reliability of risk determination, and providing a solid foundation for generating differentiated response instructions.

[0153] The steps for calculating the comprehensive risk score based on the basic risk score and the preset explanatory weights include:

[0154] Convert the preset interpretation weight value into a risk deduction amount;

[0155] The risk deduction amount is deducted from the basic risk score to generate the comprehensive risk score.

[0156] Among them, the preset explanation weight value refers to the quantitative representation of the degree of explanation of the supporting information to the initial indication information. It can be a preset value, percentage, or dynamically generated by a machine learning model according to the type and strength of the supporting information. Its purpose is to provide a basis for subsequent risk adjustment.

[0157] Risk deduction refers to the value used to reduce the basic risk score, which is derived from the preset explanatory weight value. Specifically, it can be achieved by looking up a table, applying a conversion function, or mapping the preset explanatory weight value to a specific deduction value based on a specific algorithm. Its purpose is to visualize the risk mitigation effect of supporting information.

[0158] This application achieves a refined assessment of liver function risk by converting a preset explanatory weight value into a risk deduction amount and subtracting this risk deduction amount from the base risk score. Specifically, after the system determines initial indications of potential risk based on real-time status characteristics, it further acquires supporting information to interpret these initial indications, such as the user's diagnosis type, medication status, or historical trend characteristics. The importance or explanatory power of this supporting information is quantified by a preset explanatory weight value.

[0159] To more accurately reflect the actual impact of supporting information on risk, this scheme no longer simply linearly combines the preset explanatory weight value with the basic risk score, but instead transforms it into a specific risk deduction. This transformation mechanism allows the preset explanatory weight value to directly affect the basic risk score, achieving "offsetting" or "correction" of the original risk. Subsequently, by subtracting this risk deduction from the basic risk score, a comprehensive risk score corrected by supporting information is obtained. This comprehensive risk score can more accurately reflect the user's actual liver function risk level because it not only considers the potential risks reflected in the initial indication information but also fully incorporates the explanatory background provided by the supporting information.

[0160] This risk score calculation method based on deduction allows for a more accurate second judgment result when comparing the overall risk score with a preset threshold. For example, when supporting information fully explains the initial indication (such as a benign drug reaction), the preset explanatory weight is higher, and the corresponding risk deduction is also larger, significantly reducing the overall risk score and potentially making it lower than the preset risk threshold, ultimately determining it as not high-risk. Conversely, if the supporting information cannot explain or has insufficient explanatory power, the risk deduction is smaller, and the overall risk score remains at a high level, thus accurately identifying the true risk. This refined risk assessment mechanism enables the system to more reliably distinguish liver function abnormalities in different clinical contexts when generating comprehensive judgment criteria, thereby guiding the preset logic tree to generate differentiated response instructions. This avoids false positives or false negatives caused by simple numerical judgments in traditional methods, improving the accuracy and reliability of the entire liver function data detection method.

[0161] In some embodiments, the step of comparing the comprehensive risk score with a preset threshold to generate a second determination result includes:

[0162] Obtain a set of preset thresholds for defining multiple risk ranges;

[0163] Determine the risk range into which the comprehensive risk score falls within multiple risk ranges defined by a set of preset thresholds;

[0164] Based on the risk range in which the comprehensive risk score falls, a second judgment result representing a specific risk level is generated.

[0165] Among them, multiple risk ranges refer to continuous numerical ranges representing different levels of risk, which are divided by the aforementioned preset thresholds. For example, they can be divided into low-risk ranges, medium-risk ranges, high-risk ranges, etc., with the aim of finely classifying risks.

[0166] The second judgment result, which represents a specific risk level, refers to the classification label or identifier that is output based on the risk range into which the comprehensive risk score falls, and clearly indicates the current risk level. It can be an enumerated value (such as "low risk", "medium risk", "high risk"), a risk level number (such as "level 1", "level 2", "level 3"), or a risk status description. Its purpose is to provide a clear and actionable risk judgment conclusion.

[0167] Based on the above characteristics, this application overcomes the limitations of single-threshold judgment by introducing a multi-level risk assessment mechanism. Specifically, upon receiving liver function data representing the user's liver function status, the system first determines initial indication information based on immediate status characteristics and calculates a comprehensive risk score in conjunction with supporting information. On this basis, to conduct a more refined assessment of the comprehensive risk score, a set of preset thresholds is obtained. These thresholds are carefully designed to divide the entire risk score range into multiple discrete risk intervals. Subsequently, the calculated comprehensive risk score is compared with these preset thresholds to accurately determine which risk interval the score falls into. Once the risk interval of the comprehensive risk score is determined, the system can generate a second judgment result representing a specific risk level based on that interval.

[0168] This multi-range, multi-level judgment method ensures that the second judgment result is no longer a simple binary judgment (such as "risky" or "no risk"), but rather reflects the degree and nature of the risk. For example, one comprehensive risk score may fall into the "low risk" range, while another may fall into the "high risk" range, even if both are above a single "risk" threshold. This refined second judgment result builds upon the comprehensive analysis of initial indication and supporting information, and provides richer and more accurate input for generating subsequent comprehensive judgments. In this way, when generating the final differentiated response instructions, the system can take differentiated measures based on different risk levels. For example, it may only provide health advice for low-risk situations, while it may immediately trigger an emergency alarm for high-risk situations. This significantly improves the accuracy of risk assessment and the targeting of responses, avoiding misjudgments or resource waste caused by overly absolute judgments. As a result, the entire liver function data detection method can more effectively adapt to complex and changing situations, providing users with more accurate and reliable health management services.

[0169] like Figure 2 As shown, an exemplary system for detecting liver function data in high-risk groups for liver cancer is illustrated. This application further proposes a liver function data detection system 100 for high-risk groups for liver cancer, which includes:

[0170] The snapshot creation module 10 is used to create a context snapshot based on the user ID in a high-speed memory cache. The context snapshot stores the diagnosis type, medication status field, and last medication record timestamp field.

[0171] The diagnostic event message generation module 20 is used to deploy a change data capture mechanism in the user database. When the diagnostic type is updated, it generates a first type of event message and pushes it to the message queue.

[0172] Medication event message generation module 30 is used to deploy an event generator on the medication log server, and generate a second type of event message when a user submits a medication record and push it to the message queue;

[0173] Snapshot update module 40 is used to listen to the message queue, generate context change events and update the context snapshot corresponding to the user ID in real time;

[0174] The instruction generation module 50 is used to obtain a context snapshot corresponding to the user ID after receiving liver function data that represents the user's liver function status; and to generate differentiated response instructions by executing a preset logic tree based on the liver function data and the diagnosis type, medication status field, and last medication record timestamp field stored in the context snapshot.

[0175] Through the above technical solutions, this system provides a highly efficient and stable architecture for detecting liver function data in high-risk individuals for liver cancer. By maintaining real-time updated user context snapshots in a high-speed memory cache, the latency issues caused by traditional multi-database queries are overcome, ensuring that the latest diagnostic and medication background information of the user can be obtained at extremely fast speeds upon receiving liver function data. The event-driven snapshot update mechanism guarantees the accuracy and timeliness of context information. Based on this real-time and accurate context information and liver function data, the instruction generation module executes a pre-set logic tree to generate differentiated response instructions, thereby avoiding false positives and false negatives caused by uniform judgments for users with different pathological backgrounds. This significantly improves the accuracy and response efficiency of liver function data detection, ensuring that various modules can work collaboratively in high-concurrency, high-data-volume scenarios such as cloud-based health management platforms, thereby improving the performance and reliability of the entire system.

[0176] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for detecting liver function data in high-risk groups for liver cancer, characterized in that, include: Create a context snapshot based on the user ID in a high-speed memory cache. The context snapshot stores the diagnosis type, medication status field, and the timestamp field of the last medication record. Deploy a change data capture mechanism in the user database, and generate a first-type event message and push it to the message queue when the diagnosis type is updated; An event generator is deployed on the medication log server to generate a second type of event message and push it to the message queue when a user submits a medication record. Listen to the message queue, generate a context change event, and update the context snapshot corresponding to the user ID in real time; After receiving liver function data representing the user's liver function status, a context snapshot corresponding to the user ID is obtained; and based on the liver function data and the diagnosis type, medication status field, and last medication record timestamp field stored in the context snapshot, a preset logic tree is executed to generate a differentiated response instruction. The pre-defined logic tree includes the following rules: If the diagnosis is cirrhosis and the bilirubin level in the liver function data jumps above the first threshold, an emergency alarm is triggered. If the diagnosis is hepatitis B, the medication status is normal, and the bilirubin value in the liver function data jumps above the first threshold, the alarm is ignored. If the diagnosis is hepatitis B, the medication status is discontinued, and the bilirubin value in the liver function data jumps above the first threshold, a medium-level alarm is triggered.

2. The method for detecting liver function data in high-risk groups for liver cancer according to claim 1, characterized in that, The steps of listening to the message queue, generating a context change event, and updating the context snapshot corresponding to the user ID in real time include: Obtain an event batch containing multiple of the aforementioned context change events; For multiple context change events corresponding to the same user within the event batch, the final change event is determined based on the time information of the multiple context change events; and, The context snapshot corresponding to the user ID is updated in real time using the final change event.

3. The method for detecting liver function data in high-risk groups for liver cancer according to claim 1, characterized in that, The steps of obtaining a context snapshot corresponding to the user ID after receiving liver function data representing the user's liver function status, and executing a preset logic tree to generate a differentiated response instruction based on the liver function data and the diagnosis type, medication status field, and last medication record timestamp field stored in the context snapshot, include: From the context snapshot, retrieve the pre-stored historical trend features that characterize the long-term change trend of the user's liver function status; Based on the liver function data, determine the instantaneous state features that characterize the current liver function status; By combining the historical trend features, the real-time state features, and user context information in the context snapshot other than the historical trend features, a comprehensive judgment criterion is generated; and, Based on the comprehensive judgment criteria, and based on the liver function data, the diagnosis type, medication status field, and last medication record timestamp field stored in the context snapshot, a preset logic tree is executed to generate a differentiated response instruction.

4. The method for detecting liver function data in high-risk groups for liver cancer according to claim 3, characterized in that, When the context snapshot contains pre-stored historical trend features that characterize the long-term change trend of a user's liver function status, the steps of listening to the message queue, generating a context change event, and updating the context snapshot corresponding to the user ID in real time include: Distinguish the type of the context change event to determine whether it is an immediate change event or a trend-related event; If the context change event is the immediate change event, then update the user context information in the context snapshot except for the historical trend features; If the context change event is a trend-related event, then the context snapshot corresponding to the user ID is updated based on the historical trend features stored in the context snapshot.

5. The method for detecting liver function data in high-risk groups for liver cancer according to claim 3, characterized in that, The step of generating a comprehensive judgment criterion by combining the historical trend features, the real-time state features, and user context information in the context snapshot other than the historical trend features includes: Based on the aforementioned real-time status characteristics, initial indication information characterizing the potential risk to the current liver function status is determined; In response to the determination of the initial indication information, supporting information for interpreting the initial indication information is obtained from the historical trend features and the user context information in the context snapshot other than the historical trend features; Based on the preset second operation logic, it is determined whether the supporting information and the initial indication information constitute a preset interpretation relationship, and a second determination result is obtained; Based on the second determination result, the comprehensive judgment criteria are generated.

6. The method for detecting liver function data in high-risk groups for liver cancer according to claim 5, characterized in that, The step of determining whether the supporting information and the initial indication information constitute a preset interpretation relationship based on the preset second operation logic, and obtaining the second determination result, includes: A basic risk score is determined for the initial indication information; Obtain the preset interpretation weight value corresponding to the supporting evidence information; Based on the basic risk score and the preset explanatory weight value, a comprehensive risk score is calculated; The comprehensive risk score is compared with a preset threshold to generate the second determination result.

7. The method for detecting liver function data in high-risk groups for liver cancer according to claim 6, characterized in that, The step of calculating the comprehensive risk score based on the basic risk score and the preset explanatory weight value includes: Convert the preset interpretation weight value into a risk deduction amount; The risk deduction amount is deducted from the basic risk score to generate the comprehensive risk score.

8. The method for detecting liver function data in high-risk groups for liver cancer according to claim 6, characterized in that, The step of comparing the comprehensive risk score with a preset threshold to generate the second determination result includes: Obtain a set of preset thresholds for defining multiple risk ranges; Determine the risk range into which the comprehensive risk score falls among multiple risk ranges defined by the preset threshold; Based on the risk range into which the comprehensive risk score falls, a second determination result representing a specific risk level is generated.

9. A liver function data detection system for high-risk groups of liver cancer, characterized in that, The system includes: The snapshot creation module is used to create a context snapshot based on the user ID in a high-speed memory cache. The context snapshot stores the diagnosis type, medication status field, and the timestamp field of the last medication record. The diagnostic event message generation module is used to deploy a change data capture mechanism in the user database. When the diagnostic type is updated, it generates the first type of event message and pushes it to the message queue. The medication event message generation module is used to deploy an event generator on the medication log server. When a user submits a medication record, a second type of event message is generated and pushed to the message queue. The snapshot update module is used to listen to the message queue, generate context change events, and update the context snapshot corresponding to the user ID in real time. The instruction generation module is used to obtain a context snapshot corresponding to the user ID after receiving liver function data that represents the user's liver function status; and to generate differentiated response instructions by executing a preset logic tree based on the liver function data and the diagnosis type, medication status field, and last medication record timestamp field stored in the context snapshot. The pre-defined logic tree includes the following rules: If the diagnosis is cirrhosis and the bilirubin level in the liver function data jumps above the first threshold, an emergency alarm is triggered. If the diagnosis is hepatitis B, the medication status is normal, and the bilirubin value in the liver function data jumps above the first threshold, the alarm is ignored. If the diagnosis is hepatitis B, the medication status is discontinued, and the bilirubin value in the liver function data jumps above the first threshold, a medium-level alarm is triggered.

Images