Message reply method, device, equipment and storage medium

Abstract

The application discloses a message reply method and device, equipment and storage medium, and relates to the technical field of computer and internet. The method comprises the following steps: obtaining a conversation message from a patient account; determining a risk level of the patient account according to health data of the patient account and the conversation message, in the case that the conversation message meets a trigger condition of a temporary response; wherein the health data is used to indicate the physical condition of a patient user corresponding to the patient account; the risk level is used to indicate the risk hidden danger of the patient user; determining a reply strategy for the conversation message based on the risk level; and performing an intelligent reply process for the conversation message based on the reply strategy. The method improves the timeliness of the message response for the patient user, and can perform hierarchical processing on the conversation message of the patient user to meet the needs of different patient users.

Description

Technical Field

[0001] This application relates to the fields of computer and internet technology, and in particular to a message reply method, apparatus, device, and storage medium. Background Technology

[0002] With the rapid development of internet and artificial intelligence technologies, mobile health management has become an important technological direction for chronic disease prevention and control, providing technical support for continuous health monitoring, personalized intervention, and intelligent risk warning.

[0003] In related technologies, health management software typically focuses on recording patients' health data. Some software can also respond to conversational messages sent by patients based on text content uploaded by patients, such as their symptoms, daily complaints, and abnormal physical symptoms.

[0004] However, since only recording the health data of patients is insufficient to meet their needs in real-world scenarios, and relying solely on caregivers to reply to conversational messages sent by patients results in untimely responses. Summary of the Invention

[0005] This application provides a message reply method, apparatus, device, and storage medium. The technical solution provided by this application includes the following aspects.

[0006] According to one aspect of the embodiments of this application, a message reply method is provided, the method comprising: Retrieve conversation messages from the patient's account; If the session message meets the triggering conditions for a temporary response, the risk level of the patient account is determined based on the patient account's health data and the session message; wherein, the health data is used to indicate the physical condition of the patient user corresponding to the patient account; and the risk level is used to indicate the potential risks to the patient user. Based on the risk level, determine the response strategy for the session message; Based on the aforementioned response strategy, an intelligent response process is executed for the conversation messages.

[0007] According to one aspect of the embodiments of this application, a message reply device is provided, the device comprising: The acquisition module is used to retrieve session messages from patient accounts; The determination module is used to determine the risk level of the patient account based on the patient account's health data and the session message, when the session message meets the triggering conditions for a temporary response; wherein the health data is used to indicate the physical condition of the patient user corresponding to the patient account; and the risk level is used to indicate the potential risks to the patient user. The determining module is further configured to determine a response strategy for the session message based on the risk level; The execution module is used to execute an intelligent reply process for the session message based on the reply strategy.

[0008] According to one aspect of the embodiments of this application, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the computer program being loaded and executed by the processor to implement the above-described message reply method.

[0009] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, the computer program being loaded and executed by a processor to implement the above-described message reply method.

[0010] According to one aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program, the computer program being executed by a processor to implement the above-described message reply method.

[0011] The technical solution provided in this application can bring the following beneficial effects: By determining the risk level of a patient's account when its conversation messages meet the triggering conditions for a temporary response, and based on the patient's health data and conversation messages, a response strategy is determined and executed accordingly. On one hand, promptly determining the response strategy and executing the corresponding response process when the patient's account's conversation messages meet the triggering conditions for a temporary response can avoid the problem of being unable to handle sudden situations of patient users in a timely manner due to delayed responses. On the other hand, determining the risk level of a patient's account based on its health data and conversation messages, and then determining the response strategy accordingly, allows for the tiered processing of patient users' conversation messages to meet the needs of patients in different states. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of a computer system provided in one embodiment of this application; Figure 2 This is a schematic diagram of a message reply method provided in one embodiment of this application; Figure 3 This is a flowchart of a message reply method provided in one embodiment of this application; Figure 4 This is a flowchart of a message reply method provided in another embodiment of this application; Figure 5 This is a schematic diagram illustrating a risk level determination method provided in one embodiment of this application; Figure 6 This is a flowchart of a message reply method provided in another embodiment of this application; Figure 7 This is a schematic diagram of a response strategy determination method provided in one embodiment of this application; Figure 8 This is a schematic diagram of a medical safety audit provided in one embodiment of this application; Figure 9 This is a flowchart of a message reply method provided in another embodiment of this application; Figure 10 This is a schematic diagram of a message reply system provided in one embodiment of this application; Figure 11 This is a block diagram of a message reply device provided in one embodiment of this application; Figure 12 This is a structural block diagram of a computer device provided in one embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0014] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0015] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a” and “the” as used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0016] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0017] Please refer to Figure 1This illustration shows a schematic diagram of a computer system provided in one embodiment of this application. The computer system may include: a first terminal device 10, a second terminal device 20, and a server 30.

[0018] The first terminal device 10 includes, but is not limited to, mobile phones, tablets, smart voice interaction devices, game consoles, wearable devices, multimedia playback devices, PCs (Personal Computers), in-vehicle terminals, smart home appliances, and other electronic devices. The client of the target application can be installed on the first terminal device 10. Optionally, the target application can be an application that needs to be downloaded and installed, or it can be a webpage or a mini-program; this application embodiment does not limit this.

[0019] The second terminal device 20 includes, but is not limited to, mobile phones, tablets, smart voice interaction devices, game consoles, wearable devices, multimedia playback devices, PCs, in-vehicle terminals, smart home appliances, and other electronic devices. The client of the target application can be installed on the second terminal device 20. Optionally, the target application can be an application that needs to be downloaded and installed, or it can be a webpage or a mini-program; this application embodiment does not limit this.

[0020] In this embodiment, the first terminal device 10 is a terminal device used by the patient user, and the second terminal device 20 is a terminal device used by the caregiver; or, the first terminal device 10 is a terminal device used by the caregiver, and the second terminal device 20 is a terminal device used by the patient user.

[0021] In this embodiment, the target application can be any application capable of providing health management functions. Exemplarily, the target application is a client application, which can provide health management, health assistance, and other functions. In some embodiments, the target application can also be a social application, an instant messaging application, etc., and this application is not limited thereto. Optionally, the target application versions installed on the first terminal device 10 and the second terminal device 20 are the same; or, the target application versions installed on the first terminal device 10 and the second terminal device 20 are different.

[0022] Server 30 is used to provide backend services for the clients of the target applications in the first terminal device 10 and the second terminal device 20. For example, server 30 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms, but it is not limited to these.

[0023] The first terminal device 10, the second terminal device 20, and the server 30 can communicate with each other via a network. This network can be a wired network or a wireless network.

[0024] The method provided in this application can be performed by a computer device, which can be any electronic device capable of data storage and processing. For example, the computer device can be... Figure 1 The server 30 in the computer system shown can also be Figure 1 The computer system shown can be executed by the first terminal device 10 and the server 30 interacting and cooperating, or by the second terminal device 20 and the server 30 interacting and cooperating, or by another device other than the first terminal device 10, the second terminal device 20, and the server 30.

[0025] In related technologies, chronic diseases are characterized by long course, the need for continuous long-term follow-up, and dynamic fluctuations in condition. With the accelerating aging of the population, the number of people suffering from chronic diseases in China continues to increase, significantly raising the demand for long-term outpatient health management. In traditional online management models for chronic diseases, interaction between caregivers and patients mainly relies on patients proactively sending text messages to provide feedback on vital signs, subjective symptoms, and health concerns. The unified message queuing mechanism lacks the ability to intelligently identify and categorize the content of patient conversations. Caregivers need to browse all conversation information one by one, which not only consumes a significant amount of manpower processing low-value information such as appointment inquiries and general knowledge questions, but also easily overlooks critical medical concerns, posing a medical safety hazard of delayed treatment for acute and critical illnesses.

[0026] For example, diabetes is a chronic disease requiring long-term, continuous management. Patients need ongoing guidance in their daily lives regarding diet, exercise, medication, blood glucose monitoring, complication prevention, and follow-up appointments. In the online-offline care model for diabetes, care services typically include offline medical or health management services, as well as continuous follow-up, reminders, and communication within an online app. In practice, caregivers need to manage a large number of patients simultaneously within the app, including answering patient questions, explaining blood glucose fluctuations, reminding them to take medication or monitor their blood glucose, pushing health information, and comforting patients. However, relying on manual responses or fixed templates presents challenges such as untimely responses, insufficient sense of companionship, inaccurate education, LLM (Large Language Model) medical risks, and difficulty in achieving closed-loop optimization.

[0027] In temporary response scenarios, when caregivers are in outpatient clinics, offline follow-ups, health assessments, resting, on leave, outside of working hours, or off-duty, messages from patients may not be processed manually for a short period. If the system waits entirely for a caregiver's reply, patients may experience anxiety or miss timely safety alerts; conversely, if the system allows for free responses from a large language model, it may result in inappropriate diagnoses, medication adjustments, substitution of doctor's advice, or improper handling of high-risk symptoms.

[0028] Therefore, a temporary response generation and risk triage mechanism that can be embedded in the workflow of a diabetes care app is needed: when caregivers are temporarily unable to reply and the patient's message waiting time exceeds a threshold, the risk level of the patient's message should be determined first, and then an automatic response, conservative prompt, caregiver confirmation, manual priority or emergency prompt should be given based on different risk outputs, so as to balance the timeliness of response and medical safety.

[0029] Based on the problems existing in related technologies, the technical solutions provided in the embodiments of this application are as follows: Figure 2 As shown, after a patient sends a conversation message in the application, the system collects the patient's account's conversation messages and health data, which reflects the patient's physical condition. If the conversation message meets the triggering conditions for a temporary response, the system determines the patient's account risk level based on their physical condition and the conversation message, and then determines a corresponding response strategy based on the risk level. Finally, the system responds to the conversation messages sent by the patient in the application according to the response strategy.

[0030] Please refer to Figure 3 The diagram illustrates a flowchart of a message reply method according to an embodiment of this application. The execution subject of this method may be the computer device described above. The method may include at least one of the following steps (310-340).

[0031] Step 310: Obtain the conversation message from the patient's account.

[0032] In some embodiments, a patient account refers to an account registered by the patient user or linked to the patient user's personal data. Optionally, a patient account is identifying information used to distinguish different patient users.

[0033] In some embodiments, a session message refers to an account's interaction records and / or communication records generated within the platform. Optionally, a session message from a patient account includes one or more of the following: session text, session message sending time, current session status, etc. Here, session text refers to the text content uploaded by the patient user corresponding to the patient account; session message sending time refers to the time when the patient user corresponding to the patient account sent the session text; current session status refers to the current validity status, completion status, etc. of the session message. Optionally, session text includes one or more of the following: symptoms, questions, concerns, etc., described by the patient. Optionally, session message sending time refers to a standard timestamp recorded by the platform server after the patient user clicks to send the message. For example, if a patient user sends the session message "blood sugar 9.8, sweating and palpitations" at 8:15 AM, the session text will be "blood sugar 9.8, sweating and palpitations," and the session message sending time will be 8:15 AM. Optionally, the current session status includes one or more of the following: pending access, in progress, ended, etc.; where pending access means the session message has not been replied to; in progress means the session message is in the interaction stage; ended means the session message has been closed. For example, if a patient sends a conversation message, but the caregiver or artificial intelligence (AI) does not click to view the patient's account's conversation message, the patient's account's conversation message is in a pending state; if a patient sends a conversation message and the caregiver clicks to view the patient's account's conversation message, the patient's account's conversation message is in progress; if a patient sends a conversation message and the caregiver replies to the conversation message and then manually closes the conversation message, the patient's account's conversation message is in an ended state.

[0034] The conversation messages of patient accounts are the foundational information for determining subsequent response strategies. By obtaining the conversation messages of patient accounts, we can not only identify patient accounts that require a response, but also determine the risk of the patient users corresponding to those patient accounts, so as to facilitate the execution of subsequent intelligent response processes.

[0035] Step 320: If the session message meets the triggering conditions for a temporary response, determine the risk level of the patient account based on the patient account's health data and the session message; wherein, the health data is used to indicate the physical condition of the patient user corresponding to the patient account; and the risk level is used to indicate the potential risks to the patient user.

[0036] In some embodiments, a temporary response refers to a response made by a caregiver to a patient's conversation message when the caregiver is unable to reply promptly. Optionally, the triggering conditions for a temporary response include one or more of the following: the caregiver fails to reply to the conversation message initiated by the patient's account within a preset time period; the conversation message contains risk signals, etc. Optionally, the preset time period is determined by relevant personnel. For example, the preset time period is 60 seconds. If the caregiver does not process the conversation message within 60 seconds after the patient's account initiates the conversation message, the conversation message is determined to meet the triggering conditions for a temporary response.

[0037] In some embodiments, when the session message meets the triggering conditions for a temporary response, the risk level of the patient account is determined based on the patient account's health data and the session message. Optionally, the health data is used to indicate the physical condition of the patient user corresponding to the patient account. Optionally, the health data includes the patient user's physical indicators and medication status, etc. For example, the health data includes the patient user's blood glucose levels over the past five days. Optionally, the risk level of the patient account is used to indicate the patient user's potential risks. Generally, the higher the risk level of the patient account, the greater the potential risk for the corresponding patient user; the lower the risk level of the patient account, the smaller the potential risk for the corresponding patient user. Optionally, the number of risk levels is determined by relevant personnel. For example, the number of risk levels is 3, sequentially labeled as low risk, medium risk, and high risk according to the magnitude of the potential risk. For example, the number of risk levels is 4, sequentially labeled as low risk, low-medium risk, medium risk, and high risk according to the magnitude of the potential risk.

[0038] In some embodiments, if the session message does not meet the triggering conditions for a temporary response, the session message for the patient account is processed normally. Optionally, if the triggering conditions for a temporary response include the caregiver's failure to take over the session message in a timely manner, the caregiver takes over the session message for the patient account in a timely manner, that is, if it is determined that the session message does not meet the triggering conditions for a temporary response, the caregiver replies to the session message normally.

[0039] By determining the risk level of a patient's account based on their health data and conversation messages when the triggering conditions for a temporary response are met in the session messages, risk classification of the patient's situation can be achieved. This not only improves the rationality of medical resource allocation but also shortens the patient's response waiting time.

[0040] Step 330: Determine the response strategy for the session messages based on the risk level.

[0041] In some embodiments, a response strategy refers to the method of responding to conversation messages. Optionally, there is a correlation between the response strategy and the content of the conversation messages. For example, if the conversation messages in a patient's account contain daily records, regular check-ins, etc., the response strategy might be comments or lifestyle suggestions. For example, if the conversation messages in a patient's account contain expressions of worry or anxiety, the response strategy might be reassurance or explanation. For example, if the conversation messages in a patient's account include information about medication, the response strategy might be waiting for a caregiver's response regarding medication administration.

[0042] In some embodiments, risk level and response strategy are correlated. For example, when the risk level is low, a corresponding response strategy is generated using an intelligent response model. For example, when the risk level is medium, a corresponding response strategy is generated using the intelligent response model and confirmed by a caregiver. For example, when the risk level is high, the intelligent response model is disabled, and the caregiver is reminded to respond. Here, the intelligent response model is an AI model used to generate response messages.

[0043] Based on risk levels, a response strategy for conversation messages is determined. On the one hand, caregiver resources can be allocated reasonably based on the risk level of the patient account. On the other hand, compared to using intelligent response models to respond to conversation messages for all patient accounts, this approach avoids inappropriate responses from intelligent response models that could affect the safety of patient users.

[0044] Step 340: Based on the reply strategy, execute the intelligent reply process for the conversation message.

[0045] In some embodiments, the intelligent response process refers to a series of operational steps for responding to conversation messages. Optionally, there is a correlation between the response strategy and the intelligent response process. For example, when the response strategy is to output a review, a review text for the conversation message is generated by the intelligent response model and sent to the conversation message in the patient's account. For example, when the response strategy is for the intelligent response model to generate processing steps, which are then confirmed by the caregiver, the processing steps are generated by the intelligent response model, sent to the caregiver, and after confirmation by the caregiver, sent to the conversation message in the patient's account. For example, when the response strategy is to prohibit the intelligent response model from generating responses, a prompt message is sent to the caregiver with high priority, prompting the caregiver to respond to the conversation message.

[0046] The technical solution provided in this application determines the risk level of a patient account based on its health data and conversation messages when the patient account's conversation messages meet the triggering conditions for a temporary response. Based on this, a response strategy is determined for the conversation messages, and the corresponding response process is executed. On one hand, by promptly determining the response strategy and executing the corresponding response process when the patient account's conversation messages meet the triggering conditions for a temporary response, the problem of being unable to handle sudden situations of patient users in a timely manner due to untimely responses can be avoided. On the other hand, by determining the risk level of a patient account based on its health data and conversation messages, and then determining the response strategy, the patient user's conversation messages can be processed in a tiered manner to meet the needs of patient users in different states.

[0047] Please refer to Figure 4 The diagram illustrates a flowchart of a message reply method according to another embodiment of this application, wherein the execution subject of the method may be the computer device described above. The method may include at least one of the following steps (410-450).

[0048] Step 410: Obtain the conversation message from the patient's account.

[0049] For details not described in step 410 above, please refer to the description of step 310 in the above embodiments.

[0050] Step 420: If the session message meets the triggering conditions for a temporary response, a rule engine is used to determine the first risk identification result based on health data and the session message; and a risk identification model is used to determine the second risk identification result based on health data and the session message; wherein, the rule engine is used to identify structured risk signals according to preset judgment rules, and the risk identification model is an AI model used to identify implicit risks in unstructured text.

[0051] In some embodiments, the rule engine is used to identify explicit, structured risk signals. Optionally, a structured risk signal refers to a risk signal with explicit fields. Optionally, the risk signal includes one or more of the following: health indicators, medication keywords, symptom keywords, and emergency keywords. For example, a patient account's conversation message includes "Today's blood glucose level was 11.7 mmol / L, feeling unwell and experiencing palpitations, forgot to take medication," and the rule engine can identify the structured risk signals "blood glucose level 11.7 mmol / L" and "drug not taken." In some embodiments, the first risk identification result is a risk identification result determined based on the structured risk signals in the conversation message. For example, a conversation message including a structured risk limit of "blood glucose 11.7 mmol / L" is higher than the normal level and is judged as high risk.

[0052] In some embodiments, the risk identification model is used to identify implicit risks in unstructured text. Optionally, unstructured text refers to text without a fixed format and without uniform fields. For example, if a patient's account conversation message includes phrases like "cold sweats, palpitations, and feeling unsteady," the risk identification model can identify the implicit risks of the patient user. In some embodiments, the second risk identification result is a risk identification result determined based on unstructured risk signals in the conversation message. For example, if the conversation message includes the symptom combination of "shortness of breath and chest pain," the risk identification model identifies a high level of implicit risk in the unstructured text of the conversation message and classifies it as high risk.

[0053] In some embodiments, step 420 above includes at least one of the following steps (421-423) (not shown in the figure).

[0054] Step 421: Extract key information from health data and conversation messages. Key information includes health indicators and keywords related to the patient user's physical condition.

[0055] In some embodiments, health indicators refer to various numerical values ​​or standard parameters used to measure the health status of a person. Typically, a patient's health status is determined based on their health indicators. Optionally, the numerical thresholds corresponding to the patient's health indicators are determined according to relevant regulations or institutional standards. For example, health indicators include blood glucose. A blood glucose level below 3.9 mmol / L indicates a risk of hypoglycemia; a blood glucose level above 16.7 mmol / L indicates a risk of hyperglycemia; and a blood glucose level above 22.2 mmol / L is considered a high-risk level. Specific numerical values ​​are provided for illustrative purposes only.

[0056] In some embodiments, keywords include one or more of the following: medication keywords, symptom keywords, and emergency keywords. Medication keywords refer to keywords related to the patient's medication history, such as "taking medication XX" or "not taking medication"; symptom keywords refer to keywords related to the patient's symptoms, such as "XX disease"; and emergency keywords refer to keywords related to the patient's sudden onset of symptoms, such as "sudden physical discomfort." For example, keywords may include one or more of the following: confusion, fainting, chest pain, difficulty breathing, persistent vomiting, severe sweating, palpitations, etc.

[0057] In some embodiments, a structured template matching mechanism is used to identify key information in the patient account's session messages. In some embodiments, the patient account's session messages are cleaned before extracting the key information.

[0058] Step 422: Match the key information with at least one decision rule in the rule engine.

[0059] In some embodiments, the determination rule refers to the rule used to determine the risk level corresponding to key information. Optionally, when the key information includes the patient user's health indicators, the determination rule includes one or more of the following: if the patient user's health indicators are all within the normal range, the patient account's conversation messages are low-risk; if the patient user's health indicators are slightly abnormal, the patient account's conversation messages are medium-risk; if the patient user's health indicators are highly abnormal, the patient account's conversation messages are high-risk. Optionally, when the key information includes the patient user's medication keywords, the determination rule includes: if the medication keywords include one or more of the following, the patient account's conversation messages are high-risk: significant self-adjustment of medication dosage, dangerous medication behavior, medication overdose, abnormal medication use, etc. Optionally, when the key information includes the patient user's medication keywords, the determination rule includes: if the medication keywords include forgetting to take medication, the patient account's conversation messages are medium-risk. Optionally, when the key information includes the patient user's medication keywords, the determination rule includes: if the medication keywords include normal medication use, medication dosage within the normal range, etc., the patient account's conversation messages are low-risk. Optionally, the judgment rules may also include one or more of the following: if one or more of the following keywords appear in the patient account's conversation information, the patient account's conversation messages are considered high-risk: confusion, fainting, chest pain, difficulty breathing, persistent vomiting, severe sweating, palpitations, etc.

[0060] Step 423: If the key information matches the target determination rule in the rule engine, the risk level corresponding to the target determination rule is determined as the first risk identification result.

[0061] In some embodiments, the target determination rule refers to a determination rule that matches key information. For example, if a patient's health indicators are within the normal range and there is no other key information besides health indicators, the first risk identification result is low risk.

[0062] By using a rules engine to identify risks in patient account conversation messages, it is possible to screen for explicit and quantifiable risks, thereby improving the accuracy of risk levels.

[0063] In some embodiments, step 420 above includes step 424 (not shown in the figure).

[0064] Step 424: Input health data and conversation messages into the risk identification model to obtain the second risk identification result output by the risk identification model.

[0065] In some embodiments, the risk identification model is an AI model. Optionally, the risk identification model assesses the risk level of a patient account based on health data and conversation messages. For example, conversation messages include symptoms such as cold sweats and palpitations; the risk identification model then determines a high-risk outcome.

[0066] Step 430: Combine the results of the first risk identification and the second risk identification to determine the risk level of the patient's account.

[0067] In some embodiments, the risk level of the patient account is determined by the higher risk level between the first and second risk identification results. For example, a patient account's session message might include: blood glucose 6.1 mmol / L, but unable to stand and sweating profusely. If the first risk identification result is low risk and the second risk identification result is high risk, then the patient account's risk level is high risk.

[0068] For example, when a conversation message meets the triggering conditions for a temporary response, a risk level assessment is performed on the conversation messages for the patient account. The risk level is determined using a combination of a rule engine and a risk identification model. The rule engine is responsible for identifying explicit, structured risk signals, including blood glucose levels, medication keywords, symptom keywords, and emergency keywords. The risk identification model is responsible for identifying implicit risks in natural language. For instance, if a patient doesn't directly write "hypoglycemia" but expresses a combination of symptoms such as "cold sweats, palpitations, and feeling unsteady," the risk identification model can identify this as high risk.

[0069] For example, such as Figure 5 As shown, the patient account's session messages are processed through the rule engine and risk identification model to obtain the first risk identification result and the second risk identification result. Then, the first risk identification result and the second risk identification result are merged to determine the patient account's risk level as one of low risk, medium risk, and high risk.

[0070] Step 440: Determine the response strategy for the session messages based on the risk level.

[0071] Step 450: Based on the reply strategy, execute the intelligent reply process for the conversation message.

[0072] For details not described in steps 440-450 above, please refer to the description of steps 330-340 in the above embodiments.

[0073] By combining rule engines with risk identification models, the accuracy of identifying the risk level of patient accounts can be improved.

[0074] Please refer to Figure 6The diagram illustrates a flowchart of a message reply method according to another embodiment of this application. The execution subject of this method can be the computer device described above. The method may include at least one of the following steps (610-660).

[0075] Step 610: Obtain the conversation message from the patient's account.

[0076] Step 620: If the session message meets the triggering conditions for a temporary response, determine the risk level of the patient account based on the patient account's health data and the session message; wherein, the health data is used to indicate the physical condition of the patient user corresponding to the patient account; and the risk level is used to indicate the potential risks to the patient user.

[0077] For details not described in steps 610-620 above, please refer to the description of steps 310-320 in the above embodiments.

[0078] Step 630: Under the condition that the risk level is the first risk level, determine the response strategy for the conversation message as the first response strategy; wherein, the first response strategy includes: generating a first suggestion type response message through the intelligent response model and automatically sending the first suggestion type response message to the patient account.

[0079] In some embodiments, a risk level of "first risk level" means that the patient account has a low risk. In this application, "first risk level" can also be referred to as "low risk level," "low risk," etc. Optionally, a risk level of "first risk level" is defined as follows: the patient user's health indicators are normal, the patient account's conversation messages are daily check-ins, the patient account's conversation messages are daily dietary records, etc. For example, if the patient account's conversation messages are "Today's fasting blood glucose is 6.1 mmol / L, I ate eggs and whole-wheat bread for breakfast," or "I checked in on time today," etc., it is determined that the patient user's blood glucose is within the individual target range, and the risk level is "first risk level." For example, if the patient account's conversation messages are ordinary check-ins, dietary consultations, or mild emotional expressions, the risk level is also "first risk level."

[0080] In some embodiments, the first suggestion-type response message includes one or more of the following: commentary, encouraging suggestions, general lifestyle suggestions, etc. Optionally, when the risk level is the first risk level, the caregiver is not notified after the intelligent response model generates the first suggestion-type response message. Optionally, the intelligent response model is a large language generation model.

[0081] In some embodiments, the first risk level includes a first risk sub-level and a second risk sub-level, wherein the risk of the first risk sub-level is lower than that of the second risk sub-level. Optionally, the first response strategy corresponding to the first risk sub-level includes: generating a first suggestion-type response message through an intelligent response model and automatically sending the first suggestion-type response message to the patient's account without notifying the caregiver. Optionally, the first response strategy corresponding to the second risk sub-level includes: generating a first suggestion-type response message through an intelligent response model and automatically sending the first suggestion-type response message to the patient's account; and reminding the caregiver with a low priority.

[0082] For example, in one or more of the following scenarios, the risk level is classified as the first risk sub-level: the patient user's health indicators are normal, the patient account's conversation messages are daily check-ins, the patient account's conversation messages are daily dietary records, etc. Optionally, in the case of the first risk sub-level, the first suggestion-type response message includes comments, encouragement, or general lifestyle suggestions. For example, in one or more of the following scenarios, the risk level is classified as the second risk sub-level: the patient user's blood sugar is slightly elevated after a meal, the patient user's conversation messages express concern, etc. Optionally, in the case of the second risk sub-level, the first suggestion-type response message includes one or more of the following safety steps: retesting, reviewing meals, observing changes, etc.

[0083] Step 640: If the risk level is the second risk level, determine the response strategy for the conversation message as the second response strategy; wherein, the second response strategy includes: generating a second suggestion type response message through the intelligent response model, submitting the second suggestion type response message to the caregiver account, and sending the second suggestion type response message to the patient account after receiving the confirmation instruction from the caregiver account.

[0084] In some embodiments, a risk level of "second risk level" means that the patient account is at higher risk. In this application, "second risk level" may also be referred to as "medium risk level," "medium risk," etc. Optionally, a risk level of "second risk level" may be defined as one or more of the following scenarios: mildly abnormal health indicators of the patient user, missed medication, or mild symptoms. For example, a risk level of "second risk level" may be defined as a patient user experiencing continuous abnormal blood sugar levels, suspected missed medication, mild symptoms, or scenarios involving medication administration.

[0085] In some embodiments, the intelligent response model generates a second suggestion-type response message, submits it to the caregiver for confirmation, and sends the second suggestion-type response message to the patient's account after receiving confirmation from the caregiver's account. Optionally, in the case of submission to the caregiver for confirmation, the caregiver is alerted with medium priority. In some embodiments, the intelligent response model generates a second suggestion-type response message, and if the second suggestion-type response message is only a conservative suggestion, a conservative suggestion is automatically sent to the patient's account.

[0086] For example, if a patient's account contains messages such as "My blood sugar was 9.8 mmol / L after dinner, I'm a little worried" or "I forgot to take my medication today, I don't know what to do," the risk level is determined to be the second risk level. The intelligent response model generates a second suggestion-type response message, which is then sent to the patient's account after being confirmed by the caregiver.

[0087] Step 650: If the risk level is the third risk level, determine the response strategy for the conversation message as the third response strategy; wherein, the third response strategy includes: prohibiting the generation of suggestion-type response messages, generating emergency prompt information and sending it to the patient's account, and pushing the conversation message to the manual priority processing queue.

[0088] In some embodiments, a risk level of third risk means that the patient account is at very high risk. In this application, third risk level may also be referred to as high risk level, high risk, etc. Optionally, a risk level of third risk is defined as one or more of the following scenarios: severely abnormal health indicators of the patient user, the patient user experiencing a serious illness, or significantly adjusting medication dosage on their own. For example, a risk level of third risk is defined as a patient user experiencing severe hypoglycemia, altered consciousness, chest pain, dyspnea, extremely high blood sugar, or significantly adjusting medication dosage on their own.

[0089] In some embodiments, an emergency alert message is used to notify the patient user of an emergency. Optionally, the emergency alert message is a preset message that has been manually reviewed. In some embodiments, the manual priority processing queue refers to a queue of conversation messages that caregivers prioritize for processing. In some cases, conversation messages in the manual priority processing queue do not need to be queued and can be processed by caregivers with priority. Optionally, the manual priority processing queue may also be called a manual priority queue, priority processing queue, etc. In some embodiments, prohibiting the generation of suggestion-type reply messages means prohibiting the intelligent reply model from generating suggestion-type reply messages. For example, when the risk level is the third risk level, the third reply strategy includes: prohibiting the generation of suggestion-type reply messages and not automatically sending suggestion-type messages to remind caregivers with high priority. For example, when the patient account's conversation messages include: "blood sugar 3.2 mmol / L, sweating and palpitations", "chest pain, shortness of breath", "blood sugar 22 mmol / L and still feeling very uncomfortable", etc., the risk level is determined to be the third risk level, and the generation and sending of suggestion-type reply messages are prohibited.

[0090] For example, in the case of a patient's mildly abnormal blood glucose level, the corresponding risk level is Level 1, and the intelligent response model can automatically send safety suggestions such as retesting, recording, and observation. In the case of a patient's continuously abnormal blood glucose level or accompanying symptoms, the corresponding risk level is Level 2, and the intelligent response model can generate a response message and submit it to the caregiver for confirmation. In cases involving medication, the intelligent response model is only allowed to remind patients "do not adjust medication on their own" or "follow the established plan," and cannot provide new dosages or treatment plans. In the case of a patient exhibiting high-risk symptoms, the intelligent response model is prohibited from generating suggestion-type response messages.

[0091] For example, please refer to Figure 7 This illustration shows a schematic diagram of a response strategy determination method provided in one embodiment of this application. Risk levels include low risk (i.e., the first risk sub-level), low-to-medium risk (i.e., the second risk sub-level), medium risk (i.e., the second risk level), and high risk (i.e., the third risk level). In the case of a low risk level, reassuring or general advice is automatically sent to the patient's account; in the case of a low-to-medium risk level, a conservative suggestion is sent and the caregiver is alerted with low priority; in the case of a medium risk level, a suggestion is generated and submitted to the caregiver's account for confirmation before being sent, or a conservative suggestion is sent; in the case of a high risk level, the intelligent response model is prohibited from generating suggestion-type response messages, and an emergency alert is generated and sent to the patient's account, while the conversation message is pushed to the manual priority processing queue.

[0092] It should be understood that only one of the three steps 630, 640 and 650 above needs to be performed, and the corresponding response strategy should be further determined based on the determined risk level.

[0093] Step 660: Based on the reply strategy, execute the intelligent reply process for the conversation message.

[0094] For details not described in step 660 above, please refer to the description of step 340 in the above embodiments.

[0095] In some embodiments, one or more of the following steps 670-680 (not shown in the figures) are included before step 660: Step 670: Perform a medical safety review on the message content of the first or second type of suggestion reply message. The medical safety review is used to determine whether the message content contains a diagnosis conclusion, medication adjustment suggestions, or alternative doctor's advice.

[0096] In some embodiments, medical safety review refers to the standardized verification of message content in accordance with relevant medical regulations. Optionally, if the message content includes a diagnosis, medication adjustment suggestions, or alternative doctor's advice, the message content is considered to have failed the medical safety review. Optionally, if the message content fails the medical safety review, the steps of automatically sending a first-type suggestion reply message to the patient's account or submitting a second-type suggestion reply message to the caregiver's account are prohibited.

[0097] In some embodiments, medical security audits include one or more of the following: medical boundary audit, emergency risk audit, privacy audit, tone audit, consistency audit, and duplication audit. Specifically, the medical boundary audit checks whether the message content exceeds service boundaries; the emergency risk audit checks for suggestive replies targeting patients in an emergency state; the privacy audit checks for content that leaks private information; the tone audit checks for messages containing negative emotions; the consistency audit checks for consistency with patient account conversation messages; and the duplication audit checks for duplicate content. For example, medical boundary review includes: reviewing whether the message content contains diagnostic conclusions, medication adjustments, alternative doctor recommendations, etc.; emergency risk review includes: reviewing whether the message content involves risks requiring immediate treatment, such as hypoglycemic coma, chest pain, or abnormal consciousness; privacy review includes: reviewing whether the message content discloses sensitive information such as ID card, mobile phone number, detailed medical records, and home address; tone review includes: reviewing whether the message content contains inappropriate expressions such as intimidation, blame, discrimination, or excessive promises; consistency review includes: reviewing whether the message content conflicts with the knowledge base, doctor's advice, or content already sent by caregivers; and duplication review includes: reviewing whether the message content is highly repetitive with recent push notifications or caregiver replies.

[0098] In some embodiments, the sending strategy for the first suggestion-type response message and the second suggestion-type response message is determined based on the medical safety audit results. Optionally, the sending strategy includes one or more of the following: automatic sending, delayed sending, submission to the caregiver's account for confirmation, and prohibition of sending.

[0099] Step 680: If the message content passes the medical security review, execute the step of automatically sending a first suggestion-type reply message to the patient's account, or submitting a second suggestion-type reply message to the caregiver's account.

[0100] For example, please refer to Figure 8This illustration shows a schematic diagram of a medical safety review provided in one embodiment of this application. Desensitized minimal contextual information is input into an intelligent response model, which generates a first or second suggestion-type response message. Medical safety reviews are performed on both the first and second suggestion-type response messages, including: medical boundary review, emergency risk review, privacy review, tone review, consistency review, and duplication review. Based on the review results, a suggestion-type response message is sent or submitted for caregiver confirmation, delayed, or prohibited from being sent. Furthermore, only allowed suggestion-type response messages are displayed on the patient's account, while the caregiver's account displays risk levels, suggestion-type response messages awaiting confirmation, and caregiver modification records, with operation logs retained in the background.

[0101] By conducting medical safety reviews on the content of the first or second suggestion-type response messages generated by the intelligent response model, and executing the corresponding response steps if the medical safety review is passed, the risk of the intelligent response model generating inappropriate suggestions can be reduced.

[0102] The method provided in this application, by distinguishing three risk levels, determines the response strategy for conversation messages and can reasonably allocate human resources based on the actual situation of the patient user corresponding to the patient account.

[0103] Please refer to Figure 9 The diagram illustrates a flowchart of a message reply method provided in another embodiment of this application. The execution subject of this method may be the computer device described above. The method may include at least one of the following steps (910-990).

[0104] Step 910: Obtain the conversation message from the patient's account.

[0105] Step 920: De-identify the health data and conversation messages by removing or replacing the patient identity information in the health data and conversation messages to obtain the processed health data and conversation messages; wherein, the processed health data and conversation messages are used to determine the risk level of the patient account.

[0106] In some embodiments, anonymization refers to removing or replacing patient identification information in health data and conversation messages. By anonymizing health data and conversation messages, sensitive information such as the patient's complete medical records, ID number, mobile phone number, and address can be avoided from being input into the intelligent response model, thus ensuring the privacy and security of patient users.

[0107] Step 930: Obtain the caregiver's shift schedule information, which is used to indicate the caregiver's current work status.

[0108] In some embodiments, the caregiver's scheduling information is used to define the caregiver's working hours, scheduling table response fields, etc. The working hours refer to the time period during which the caregiver is in a working state; the scheduling table response fields are used to indicate whether the caregiver is in an outpatient clinic, offline follow-up, health assessment, online care, rest, on leave, or out of shift. Furthermore, it should be understood that this application does not limit the specific names used for the caregiver's working states.

[0109] Step 940: If the caregiver's current work status is unable to respond to the conversation message, and the conversation message has not been replied to by the caregiver for more than a preset time, determine that the conversation message meets the triggering conditions for a temporary response.

[0110] In some embodiments, a caregiver may not respond to conversation messages if their current work status is any of the following: on an outpatient assignment, on an in-person follow-up assignment, on a health assessment assignment, or outside of working hours. Optionally, a caregiver may not respond to conversation messages if the current time is outside of their working hours. For example, a caregiver may not respond to conversation messages during nighttime, rest days, or outside of their scheduled shifts.

[0111] In some embodiments, if a caregiver's current work status prevents them from responding to a conversation message, and the message remains unanswered for a preset duration, the conversation message is determined to meet the triggering condition for a temporary response. For example, if the preset duration is 60 seconds, and the caregiver is currently on outpatient duty, and does not respond to the conversation message within 60 seconds, then the conversation message meets the triggering condition for a temporary response. For example, if a caregiver is online but on outpatient duty or outside of working hours, and does not respond to the conversation message within the preset duration, the conversation message is determined to meet the triggering condition for a temporary response. Optionally, the preset duration can be configured based on the institution, service level, patient account risk level, etc.

[0112] Step 950: If it is detected that the caregiver is entering a reply to the conversation message, cancel the triggering of the temporary response and record the reason for cancellation.

[0113] In some embodiments, triggering a temporary response is canceled if any of the following is detected: the caregiver is typing a reply to the conversation message; the caregiver opens the conversation message; the caregiver takes over the conversation message, etc. Optionally, the cancellation reason includes one or more of the following: the caregiver takes over the conversation message, the caregiver responds to the conversation message, etc.

[0114] In some embodiments, if no response to a conversation message is detected from the caregiver, it is determined whether the conversation message meets the triggering conditions for a temporary response based on the caregiver's scheduling information.

[0115] Step 960: If the session message meets the triggering conditions for a temporary response, determine the risk level of the patient account based on the patient account's health data and the session message; wherein, the health data is used to indicate the physical condition of the patient user corresponding to the patient account; and the risk level is used to indicate the potential risks to the patient user.

[0116] Step 970: Determine the response strategy for the session messages based on the risk level.

[0117] Step 980: Based on the reply strategy, execute the intelligent reply process for the conversation message.

[0118] For details not described in steps 960-980 above, please refer to the description of steps 320-340 in the above embodiments.

[0119] Step 990: Record operation logs related to the temporary response. The operation logs include at least one of the following fields: scenario type, risk level, triggering reason, candidate response content, medical safety review result, sending action, sending blocking reason, manual confirmation status, similarity score with historical responses, feedback event, record creation time, and operator identifier.

[0120] Among them, the scenario type (scene_type) indicates the scenario of the patient account's conversation message; the risk level (risk_level) indicates the risk level of the patient account; the trigger reason (trigger_reason) indicates the reason for the conversation message triggering a temporary response; the candidate response content (candidate_content) indicates the response message generated by the intelligent response model; the medical safety audit result (audit_result) indicates the medical safety audit result of the response message generated by the intelligent response model; the send action (send_action) indicates the automatic sending action of the response message; the blocked reason (blocked_reason) indicates the reason for interrupting the sending of the response message; the manual confirmation status (manual_confirm_status) indicates the confirmation status of the caregiver; the similarity score with historical responses (similarity_score) indicates the similarity between this temporary response and the previous temporary response; the feedback event (feedback_event) indicates the feedback of the patient account's conversation message after receiving the response; the record creation time (created_at) indicates the trigger time of this temporary response; and the operator identifier (operator_id) is the caregiver's identity identifier.

[0121] By recording operation logs related to temporary responses, it is possible to save original data such as the operation behavior and operation content of patient accounts and caregiver accounts, which facilitates the traceability of subsequent execution events.

[0122] The methods provided in this application will be illustrated below through several exemplary embodiments.

[0123] Example 1: At 20:15, a patient account sends a conversation message: "My blood sugar was 9.8 after dinner today, I'm a little worried." By collecting the patient account's conversation messages, the message sending time, the caregiver's schedule information, and the patient's health data, and detecting that the caregiver is currently on outpatient duty and temporarily unable to respond to the conversation message, and that the conversation message exceeds 60 seconds (i.e., the preset duration), the conversation message meets the triggering conditions for a temporary response. Based on the patient account's conversation message and health data, the patient account's risk level is determined to be the second risk level. The prompt word arrangement module constructs prompt words, inputting the patient account's conversation message summary, risk level, blood sugar summary (i.e., the patient account's health data), diet or exercise or medication summary (i.e., the patient account's health data), safety strategy, patient communication preferences, and the current triggering reason (i.e., "on outpatient duty"). The intelligent response model generates a second suggested response message: "I saw you said your blood sugar was 9.8 after dinner. Don't panic, you can retest it first, and then recall the amount of staple food you ate, your post-meal activities, and whether you took your medication on time. Don't change your medication on your own for now." The second type of suggestion response message underwent a medical safety review. Since it did not contain a diagnosis, did not adjust medication dosage, and did not replace doctor's advice, it was deemed to have passed the medical safety review. The second type of suggestion response message was automatically sent, and the conversation message was added to the caregiver's to-do list for follow-up.

[0124] Example 2: A patient account sends a conversation message: "Blood sugar 3.2 mmol / L, sweating, palpitations, almost unable to stand." The rule engine determines that blood sugar is below 3.9 mmol / L, and the risk identification model identifies "sweating, palpitations, and almost unable to stand" as a high-risk symptom combination. The patient account's risk level is classified as Level 3. Therefore, generating suggestive replies is prohibited; only emergency alerts or guidance for the patient to follow the platform's emergency procedures are sent. This conversation message is then pushed to the manual priority processing queue, and a high-priority reminder is displayed in the caregiver's account.

[0125] Example 3: A patient's account sends a conversation message, a routine dietary consultation message. When the conversation message is nearing its preset duration, it is detected that a caregiver has opened the message and is typing. The temporary response is canceled to avoid conflict between the intelligent response model generated by the temporary response and the manual response. The triggering reason, cancellation reason, and caregiver takeover status are recorded.

[0126] Example 4: The caregiver replies to the patient's account: "Observe your post-meal blood sugar for the next two days. You can eat a little less staple food at dinner." Recognizing that this round of communication is complete, the recommended supplementary type is "blood sugar monitoring reminder + dietary encouragement." The intelligent reply model generates: "Remember to record your blood sugar changes after dinner so we can continue to observe tomorrow." This generated content does not overlap with the caregiver's reply and does not involve diagnosis or medication adjustments; therefore, this reply message is automatically sent to the patient's account.

[0127] Example 5: The patient's account had not been accessed by the app for three consecutive days, and their postprandial blood glucose levels had been high recently. The profile showed a low score in "dietary control". The knowledge point "meal order and postprandial blood glucose" was selected, a short text knowledge push was generated, and the push was sent during the patient's frequently active time period. The user's click and reply status were recorded.

[0128] The following is an exemplary description of the system embodiments provided in this application.

[0129] Please refer to Figure 10 The diagram illustrates a message reply system according to an embodiment of this application. This system has the functionality to implement the method example described above. In some embodiments, the message reply system can be embedded in a diabetes care application. The system includes an event acquisition module, a caregiver status recognition module, a patient profiling module, a scenario determination module, a prompt word arrangement module, an LLM content generation module, a medical safety review module, a sending arrangement module, and a feedback learning module.

[0130] In some embodiments, the message reply system connects to the messaging system of the diabetes care app, the patient health data system, the caregiver scheduling and operating system, the health knowledge base, and the large language model service, continuously monitoring patient messages, caregiver actions, health data changes, and time events. Specifically, the messaging system of the diabetes care app provides conversation services between patient accounts and caregiver accounts; the patient health data system provides health data for patient accounts; the caregiver scheduling and operating system determines the caregiver's work status; and the health knowledge base and large language model service generate reply messages.

[0131] In some embodiments, when a patient sends a conversation message in the diabetes care APP through their patient account, the event collection module collects one or more of the following: the message content of the patient account's conversation message, the sending time of the conversation message, the status of the conversation message, the patient account's recent health data, the number of days the patient account has not interacted, the caregiver's work status, whether the caregiver is entering a reply to the conversation message, whether manual confirmation has been initiated, and whether the caregiver has taken over the conversation message, etc.

[0132] In some embodiments, the caregiver status recognition module is used to determine whether the caregiver is online, busy, currently typing, or on a scheduled shift. Optionally, the caregiver status recognition module is used to obtain the caregiver's shift information. Optionally, the caregiver status recognition module is used to obtain the shift schedule response fields and working time configurations.

[0133] In some embodiments, the patient profiling module is used to maintain basic information about the patient account, the health status, behavioral compliance, cognitive weaknesses, and communication preferences of the patient user corresponding to the patient account. Optionally, the patient profile includes one or more of the following dimensions: basic profile, health status profile, behavioral compliance profile, cognitive weakness profile, and communication preference profile. The basic profile indicates the basic information of the patient account; the health status profile indicates the patient user's physical condition; the behavioral compliance profile indicates the patient account's behavior; the cognitive weakness profile indicates the patient user's cognitive weaknesses; and the communication preference profile indicates the patient user's communication preferences. For example, if the patient user is a diabetic patient, the basic profile of the patient account includes one or more of the following: age, gender, height and weight, region, daily routine preferences, type of diabetes, disease duration, whether insulin is used, responsible caregiver, service package, and offline service institution. The health status profile includes one or more of the following: fasting blood glucose, postprandial blood glucose, glycated hemoglobin, recent hypoglycemia, hyperglycemia, abnormal blood glucose fluctuation records, medication regimen, follow-up visit plan, complication risk, and comorbidity information. Behavioral adherence profiles include one or more of the following: frequency of blood glucose monitoring, medication reminder completion, dietary records, exercise records, weight records, number of consecutive days without interaction, and message reply habits. Cognitive weakness profiles include the level of mastery of multiple knowledge domains in diabetes health education. For example, diabetes health education can be broken down into multiple knowledge domains, and a mastery score can be maintained for each domain. Patient user mastery scores for different knowledge domains are as follows: Diet control: 0.42, Exercise management: 0.71, Medication adherence: 0.35, Hypoglycemia management: 0.20, Blood glucose monitoring: 0.58, Complication prevention: 0.31. Lower scores indicate greater weakness in that knowledge domain. Optionally, this score can be updated based on patient questions, test results, knowledge card clicks, caregiver annotations, and historical consultation content. Communication preference profiles include one or more of the following: preference for brief reminders, detailed explanations, encouraging or direct expressions, receptiveness to long texts, short sentences, graphic cards, and question-and-answer content, and historical feedback on holiday greetings, follow-up appointment reminders, dietary advice, and exercise encouragement.

[0134] In some embodiments, the scenario determination module is used to determine whether the current conversation message belongs to the scenario of "the caregiver's current working status is unable to respond to the conversation message, and the conversation message has not been replied to by the caregiver for more than a preset time".

[0135] In some embodiments, when the intelligent response model generates a response message, the prompt word arrangement module provides the large language generation model (i.e., the intelligent response model) with the minimum information required to generate the response message. Optionally, the prompt word arrangement module provides one or more of the following: current scenario type, patient desensitization identifier, patient message summary, risk level, current triggering reason, recent blood glucose summary, diet or exercise or medication summary, referable safety policies, and patient communication preferences. Furthermore, it should be understood that the system should avoid inputting sensitive information such as complete medical records, ID numbers, mobile phone numbers, and addresses into the intelligent response model.

[0136] In some embodiments, the medical security audit module is used to perform medical boundary audit, emergency risk audit, privacy audit, tone audit, consistency audit, and duplication audit on the generated response messages.

[0137] In some embodiments, the sending orchestration module outputs automatic sending, delayed sending, submission for caregiver confirmation, or prohibition of sending based on the review results of the medical safety review module.

[0138] In some embodiments, the patient account can see one or more of the following: the final temporary response, emergency alert messages, supplementary remarks after conversation messages, knowledge push cards, etc. Supplementary remarks after conversation messages refer to supplementary care or reminders automatically generated by the system after the caregiver and patient have completed a round of communication, indicating that the conversation intent of the message has been closed. Knowledge push cards refer to knowledge cards pushed to the patient account by the system. Optionally, the system triggers the push of knowledge cards under one or more of the following circumstances: holidays, birthdays, or enrollment anniversaries of the patient account; no interaction from the patient account for three consecutive days; no check-in records from the patient account for several consecutive days; recent high postprandial blood glucose or abnormal fasting blood glucose in the patient account; after adjustments to the patient account's medication plan; before or after a follow-up visit for the patient account; when the caregiver marks the patient account as having a certain type of knowledge gap.

[0139] In some embodiments, candidate content, review logs, and reasons for banning are not displayed in the patient account.

[0140] In some embodiments, caregivers can see a pending list, risk level prompts, identifiers for response messages generated by the intelligent response mode, a manual confirmation entry point, response messages generated by the intelligent response mode, modification records, withdrawal records, and session message reminders for the third risk level. The backend can record and export operation logs.

[0141] In some embodiments, the feedback learning module is used to record feedback after interaction between the patient account and the caregiver account, and to update the profile corresponding to the patient account. Optionally, the feedback after interaction between the patient account and the caregiver account includes one or more of the following: whether the patient user replies; whether the patient user clicks, favorites, or closes the knowledge card; whether the patient user completes check-in, blood sugar testing, exercise, or medication reminders; whether the caregiver modifies, withdraws, or likes AI-suggested content; whether the patient user complains, unsubscribes, or ignores a certain type of content for a long time. Optionally, the feedback learning module is used to update one or more of the following: the patient's mastery of different knowledge points; the patient user's preference for different expression styles; the patient user's acceptance of different push times; the caregiver's personal communication style; and the preset duration of automatic sending and manual confirmation in different scenarios. For example, if the patient user repeatedly ignores long popular science articles but replies with short encouragement, the system reduces the probability of long text pushes and increases the recommendation weight of short sentence reminders and graphic cards.

[0142] For details not disclosed in the system embodiments of this application, please refer to the method embodiments of this application.

[0143] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0144] Please refer to Figure 11 This diagram illustrates a block diagram of a message reply apparatus according to an embodiment of this application. The apparatus has the functionality to implement the method example described above. The apparatus can be implemented in hardware or by hardware executing corresponding software. Optionally, the apparatus can be a computer device or can be installed within a computer device. Figure 11 As shown, the message reply device 1100 may include: an acquisition module 1110, a determination module 1120, and an execution module 1130.

[0145] The acquisition module 1110 is used to acquire session messages from the patient account.

[0146] The determination module 1120 is used to determine the risk level of a patient account based on the patient account's health data and the session message when the session message meets the triggering conditions for a temporary response; wherein, the health data is used to indicate the physical condition of the patient user corresponding to the patient account; and the risk level is used to indicate the potential risks to the patient user.

[0147] The determination module 1120 is also used to determine the response strategy for session messages based on the risk level.

[0148] Execution module 1130 is used to execute an intelligent reply process for conversation messages based on the reply strategy.

[0149] In some embodiments, the determining module 1120 is configured to use a rule engine to determine a first risk identification result based on health data and conversation messages; and to use a risk identification model to determine a second risk identification result based on health data and conversation messages; wherein the rule engine is used to identify structured risk signals according to preset judgment rules, and the risk identification model is an AI model used to identify implicit risks in unstructured text; and the risk level of the patient account is determined by combining the first risk identification result and the second risk identification result.

[0150] In some embodiments, the determining module 1120 is used to extract key information from health data and session messages, the key information including health indicators and keywords related to the patient user's physical condition; match the key information with at least one judgment rule in the rule engine; and, if the key information matches the target judgment rule in the rule engine, determine the risk level corresponding to the target judgment rule as the first risk identification result.

[0151] In some embodiments, the determining module 1120 is used to input health data and session messages into the risk identification model to obtain a second risk identification result output by the risk identification model.

[0152] In some embodiments, the determining module 1120 is configured to determine a first response strategy for the conversation message when the risk level is a first risk level; wherein the first response strategy includes: generating a first suggestion-type response message through an intelligent response model and automatically sending the first suggestion-type response message to the patient account; when the risk level is a second risk level, the determining module is configured to determine a second response strategy for the conversation message; wherein the second response strategy includes: generating a second suggestion-type response message through an intelligent response model and submitting the second suggestion-type response message to the caregiver account, and sending the second suggestion-type response message to the patient account after receiving a confirmation instruction from the caregiver account; when the risk level is a third risk level, the determining module is configured to determine a third response strategy for the conversation message; wherein the third response strategy includes: prohibiting the generation of suggestion-type response messages, generating an emergency alert message and sending it to the patient account, and pushing the conversation message to a manual priority processing queue.

[0153] In some embodiments, the message reply device 1100 further includes: an audit module (not shown in the figure), used to perform medical safety audit on the message content of the first suggestion type reply message or the second suggestion type reply message, the medical safety audit being used to determine whether the message content contains a diagnostic conclusion, medication adjustment suggestion or alternative doctor suggestion; and an execution module 1130, further used to execute the step of automatically sending the first suggestion type reply message to the patient account or submitting the second suggestion type reply message to the caregiver account if the message content passes the medical safety audit.

[0154] In some embodiments, the execution module 1130 is further configured to perform desensitization processing on the health data and session messages, removing or replacing the patient identity information in the health data and session messages to obtain processed health data and session messages; wherein the processed health data and session messages are used to determine the risk level of the patient account.

[0155] In some embodiments, the acquisition module 1110 is further configured to acquire the caregiver's shift information, which is used to indicate the caregiver's current working status. The determination module 1120 is further configured to determine that the conversation message meets the triggering conditions for a temporary response when the caregiver's current working status cannot respond to the conversation message, and the conversation message has not been replied to by the caregiver for more than a preset time.

[0156] In some embodiments, the execution module 1130 is further configured to cancel triggering a temporary response and record the reason for cancellation if it is detected that the caregiver is entering a reply to a session message.

[0157] In some embodiments, the execution module 1130 is further configured to record operation logs related to temporary responses. The operation logs include at least one of the following fields: scenario type, risk level, triggering reason, candidate response content, medical safety review result, sending action, sending blocking reason, manual confirmation status, similarity score with historical responses, feedback event, record creation time, and operator identifier.

[0158] It should be noted that the apparatus provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0159] Please refer to Figure 12 The diagram shows a structural block diagram of a computer device 1200 provided in one embodiment of this application.

[0160] Typically, computer device 1200 includes a processor 1210 and a memory 1220.

[0161] Processor 1210 may include one or more processing cores, such as a quad-core processor or a twelfth-core processor. Processor 1210 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1210 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, processor 1210 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, processor 1210 may also include an AI processor for handling computational operations related to machine learning.

[0162] The memory 1220 may include one or more computer-readable storage media, which may be non-transitory. The memory 1220 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in the memory 1220 are used to store a computer program configured to be executed by one or more processors to implement the message reply method described above.

[0163] Those skilled in the art will understand that Figure 12 The structure shown does not constitute a limitation on the computer device 1200, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0164] In an exemplary embodiment, a computer-readable storage medium is also provided, wherein a computer program is stored in the storage medium, and the computer program, when executed by a processor, implements the above-described message reply method. Optionally, the computer-readable storage medium may include: ROM (Read-Only Memory), RAM (Random Access Memory), SSD (Solid State Drives), or optical disc, etc. The random access memory may include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).

[0165] In an exemplary embodiment, a computer program product is also provided, the computer program product including a computer program executed by a processor, causing the computer device to perform the above-described message reply method.

[0166] It should be noted that the collection and processing of relevant data in this application (including but not limited to the health data of the patient account and conversation messages mentioned above) should strictly comply with the requirements of relevant national laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0167] It should be understood that "multiple" as used herein refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, the step numbers described herein are merely illustrative of one possible execution order. In some other embodiments, the steps may not be executed in numerical order, such as two steps with different numbers being executed simultaneously, or two steps with different numbers being executed in the reverse order of the illustration. This application does not limit this.

[0168] The above description is merely an exemplary embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A message reply method, characterized in that, The method includes: Retrieve conversation messages from the patient's account; If the caregiver fails to reply to the conversation message within a preset time period, the conversation message is determined to meet the triggering conditions for a temporary response. When the session message meets the triggering conditions for a temporary response, a rule engine is used to determine a first risk identification result based on the patient account's health data and the session message; and a risk identification model is used to determine a second risk identification result based on the health data and the session message; wherein, the health data is used to indicate the physical condition of the patient user corresponding to the patient account, and the health data includes the patient user's physical indicators and medication status; the rule engine is used to identify structured risk signals according to preset judgment rules; and the risk identification model is an artificial intelligence AI model used to identify implicit risks in unstructured text. By combining the first risk identification result and the second risk identification result, the risk level of the patient account is determined; wherein, the risk level is used to indicate the potential risks to the patient user; Based on the risk level, determine the response strategy for the session message; Based on the aforementioned response strategy, an intelligent response process is executed for the conversation messages.

2. The method according to claim 1, characterized in that, The step of employing a rule engine to determine the first risk identification result based on the patient's account health data and the session messages includes: Key information is extracted from the health data and the conversation messages, including health indicators and keywords related to the patient user's physical condition; The key information is matched with at least one judgment rule in the rule engine; If the key information matches the target determination rule in the rule engine, the risk level corresponding to the target determination rule is determined as the first risk identification result.

3. The method according to claim 1, characterized in that, The step of employing a risk identification model to determine a second risk identification result based on the health data and the session messages includes: The health data and the session message are input into the risk identification model to obtain the second risk identification result output by the risk identification model.

4. The method according to claim 1, characterized in that, The step of determining a response strategy for the session message based on the risk level includes: When the risk level is the first risk level, the response strategy for the conversation message is determined as the first response strategy; wherein, the first response strategy includes: generating a first suggestion type response message through an intelligent response model, and automatically sending the first suggestion type response message to the patient account; When the risk level is the second risk level, the response strategy for the conversation message is determined as the second response strategy; wherein, the second response strategy includes: generating a second suggestion type response message through the intelligent response model, submitting the second suggestion type response message to the caregiver account, and sending the second suggestion type response message to the patient account after receiving the confirmation instruction from the caregiver account; When the risk level is the third risk level, the response strategy for the conversation message is determined to be the third response strategy; wherein, the third response strategy includes: prohibiting the generation of suggestion-type response messages, generating emergency prompt information and sending it to the patient's account, and pushing the conversation message to the manual priority processing queue.

5. The method according to claim 4, characterized in that, The method further includes: The message content of the first suggestion type reply message or the second suggestion type reply message is subject to medical safety review. The medical safety review is used to determine whether the message content contains a diagnosis conclusion, medication adjustment suggestion or alternative doctor's advice. If the message content passes the medical security review, the step of automatically sending the first suggestion-type reply message to the patient's account or submitting the second suggestion-type reply message to the caregiver's account is executed.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: The health data and the conversation messages are desensitized to remove or replace the patient identity information in the health data and the conversation messages, resulting in the processed health data and the conversation messages. The processed health data and the session messages are used to determine the risk level of the patient account.

7. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Obtain the caregiver's shift schedule information, which is used to indicate the caregiver's current work status; The determination that the conversation message meets the triggering conditions for a temporary response when the caregiver fails to reply to the conversation message within a preset time period includes: If the caregiver is unable to respond to the session message in their current working state, and the session message is not replied to by the caregiver for a preset time, the session message is determined to meet the triggering conditions for a temporary response.

8. The method according to claim 7, characterized in that, The method further includes: If it is detected that the caregiver is entering a reply to the conversation message, the temporary response is canceled and the reason for cancellation is recorded.

9. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Record operation logs related to the temporary response, the operation logs including at least one of the following fields: scenario type, risk level, triggering reason, candidate response content, medical safety review result, sending action, sending blocking reason, manual confirmation status, similarity score with historical response, feedback event, record creation time, and operator identifier.

10. A message reply device, characterized in that, The device includes: The acquisition module is used to retrieve session messages from patient accounts; The determination module is used to determine whether the conversation message meets the triggering conditions for a temporary response if the caregiver fails to reply to the conversation message within a preset time period. The determining module is further configured to, when the session message meets the triggering conditions for a temporary response, use a rule engine to determine a first risk identification result based on the patient account's health data and the session message; and use a risk identification model to determine a second risk identification result based on the health data and the session message; and combine the first risk identification result and the second risk identification result to determine the risk level of the patient account; wherein, the health data is used to indicate the physical condition of the patient user corresponding to the patient account, the health data includes the patient user's physical indicators and medication status, the risk level is used to indicate the patient user's potential risks, the rule engine is used to identify structured risk signals according to preset judgment rules, and the risk identification model is an artificial intelligence AI model used to identify implicit risks in unstructured text; The determining module is further configured to determine a response strategy for the session message based on the risk level; The execution module is used to execute an intelligent reply process for the session message based on the reply strategy.

11. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing a computer program that is loaded and executed by the processor to implement the message reply method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which is loaded and executed by a processor to implement the message reply method as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, The computer program product includes a computer program that is executed by a processor to implement the message reply method as described in any one of claims 1 to 9.

Images