An intelligent illness management method, system and storage medium
By detecting the display conditions in the clinical information system, personalized patient views are generated, solving the problem that doctors have difficulty quickly obtaining key information, improving the efficiency and quality of diagnosis and treatment, and meeting personalized needs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- SHANGHAI LIANYING ZHIYUAN MEDICAL TECH CO LTD
- Filing Date
- 2026-01-13
- Publication Date
- 2026-06-05
AI Technical Summary
In the dynamic and continuous process of inpatient condition management, existing clinical information systems make it difficult for doctors to quickly obtain key information, resulting in low diagnostic and treatment efficiency, difficulty in meeting personalized needs, and failure to effectively accumulate and reuse expert diagnostic and treatment experience.
The detection module identifies view display conditions, obtains patient information, determines patient view templates based on disease type and course, generates personalized patient views, and displays them on the terminal, supporting personalized view configuration and the reuse of expert experience.
It improves the efficiency and quality of doctors' diagnosis and treatment in disease management, meets personalized needs, simplifies the information screening process, and ensures that key indicators are not overlooked.
Smart Images

Figure CN122162196A_ABST
Abstract
Description
Technical Field
[0001] This manual relates to the field of medical services, and in particular to an intelligent method, system, and storage medium for managing medical conditions. Background Technology
[0002] In the current hospital information system, clinical information systems (such as electronic medical records, patient 360-degree views, etc.) are widely used to integrate and display multi-source patient data, providing basic information support for doctors.
[0003] However, in the dynamic and continuous process of inpatient condition management, doctors need to quickly obtain key information and make decisions based on specific clinical problems. For example, the core indicators that doctors focus on differ for patients with different diseases and at different stages of disease. However, existing systems mostly use uniform information display templates, resulting in redundant irrelevant information and the burying of key indicators. Doctors need to spend a lot of time filtering effective data, reducing diagnostic and treatment efficiency. Furthermore, different doctors have different diagnostic and treatment habits, and uniform information display templates cannot meet personalized needs. Completely customizable view configurations are complex to operate, increasing the cost for doctors. At the same time, the valuable clinical experience of experts (such as indicator focus preferences, risk assessment logic, and medication order issuance habits) is not effectively accumulated and reused. Non-expert doctors cannot quickly learn from the expert's diagnostic and treatment approach, which may lead to the omission of key disease indicators or delays in risk assessment.
[0004] Therefore, there is an urgent need for an intelligent disease management solution that can combine the patient's specific condition with the doctor's actual needs to build a more accurate and personalized patient view, thereby improving the efficiency and quality of diagnosis and treatment. Summary of the Invention
[0005] One aspect of this specification provides an intelligent disease management method. The method includes: in response to detecting that a target patient meets view display conditions, acquiring patient information of the target patient, the patient information including a target disease, a target disease course, and examination information; determining a patient view template based on the target disease and the target disease course; and generating a target patient view of the target patient based on the patient view template and the examination information, and displaying the target patient view via a first terminal.
[0006] One aspect of this specification provides an intelligent patient condition management system. The system includes: a detection module for detecting whether a target patient meets view display conditions; an acquisition module for acquiring patient information of the target patient in response to detecting that the target patient meets the view display conditions, the patient information including a target disease, a target disease course, and examination information; a determination module for determining a patient view template based on the target disease and the target disease course; and a generation module for generating a target patient view of the target patient based on the patient view template and the examination information, and displaying the target patient view via a first terminal.
[0007] This specification provides one or more embodiments of a computer-readable storage medium that stores computer instructions. When a computer reads the computer instructions from the storage medium, the computer executes the intelligent disease management method. Attached Figure Description
[0008] This specification will be further described by way of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting; in these embodiments, the same reference numerals denote the same structures, wherein:
[0009] Figure 1 These are application scenario diagrams of the disease management system shown in some embodiments of this specification;
[0010] Figure 2 This is a block diagram of a disease management system according to some embodiments of this specification;
[0011] Figure 3 This is a flowchart illustrating a disease management method according to some embodiments of this specification;
[0012] Figure 4 A schematic diagram of the first information list shown in some embodiments of this specification;
[0013] Figure 5 This is a schematic diagram illustrating the process of near-field interaction with a first terminal according to some embodiments of this specification;
[0014] Figure 6 This is a schematic diagram illustrating the process of near-field interaction with a second terminal according to some embodiments of this specification;
[0015] Figure 7 This is a schematic diagram of a target patient view according to some embodiments of this specification;
[0016] Figure 8 This is a flowchart illustrating the process of determining a patient view template according to some embodiments of this specification;
[0017] Figure 9 This is a schematic diagram illustrating the process of generating a view template according to some embodiments of this specification;
[0018] Figure 10 This is a schematic diagram illustrating the process of generating a target patient view according to some embodiments of this specification;
[0019] Figure 11 This is a schematic diagram of a target patient view according to some embodiments of this specification;
[0020] Figure 12 This is a flowchart illustrating the process of issuing prompts based on interactive behavior data of the target doctor and target patient views, as shown in some embodiments of this specification. Detailed Implementation
[0021] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some examples or embodiments of this specification. For those skilled in the art, these drawings can be applied to other similar scenarios without creative effort. Unless obvious from the context or otherwise specified, the same reference numerals in the drawings represent the same structures or operations.
[0022] It should be understood that the terms “system,” “device,” “unit,” and / or “module” used herein are one way to distinguish different components, elements, parts, sections, or assemblies at different levels. However, if other terms can achieve the same purpose, they may be replaced by other expressions.
[0023] As indicated in this specification and claims, unless the context clearly indicates otherwise, the words "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate the inclusion of expressly identified steps and elements, which do not constitute an exclusive list, and the method or apparatus may also include other steps or elements.
[0024] Flowcharts are used in this specification to illustrate the operations performed by the system according to embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.
[0025] Figure 1 This is an application scenario diagram of a disease management system according to some embodiments of this application.
[0026] like Figure 1 As shown, the application scenario 100 of the disease management system may include a first terminal 110, a second terminal 120, a processing device 130, a storage device 140, and a network 150.
[0027] The first terminal 110 may be a terminal device that interacts with the doctor 111. In some embodiments, the first terminal 110 may include a mobile phone 110-1, a tablet 110-2, a nursing cart terminal 110-3, an XR device (not shown), etc. The nursing cart terminal 110-3 may include a trolley, a display device, one or more examination devices and / or nursing tools, etc. The doctor 111 can use the first terminal 110 to perform near-field interaction with identifiable markers set on the patient's bed and / or ward, access the patient's condition management system (e.g., view a first information list, a second information list, a target patient view, etc.), and interact with the patient's second terminal 120, etc.
[0028] The second terminal 120 can be a terminal device that interacts with the patient 121. In some embodiments, the second terminal 120 may include a mobile phone 120-1, a tablet 120-2, a bedside terminal device 120-3, etc. The bedside terminal device 120-3 may include an XR device, a display device, a mobile device, etc., or any combination thereof. The patient 121 can use the second terminal 120 to perform near-field interaction with an identifiable marker set on the doctor's name tag, and interact with the doctor's first terminal 110, etc.
[0029] Processing device 130 can process data and / or information obtained from first terminal 110, second terminal 120, storage device 140, and network 150. For example, upon detecting that a target patient meets the view display conditions, processing device 130 determines a patient view template based on the target disease and target disease course. Alternatively, processing device 130 obtains patient information of the target patient from storage device 140, generates a target patient view based on the patient view template and examination information, and displays the target patient view via the first terminal. In some embodiments, processing device 130 can be a single server or a group of servers. The server group can be centralized or distributed. In some embodiments, processing device 130 can be local or remote. In some embodiments, processing device 130 can be implemented on a cloud platform. For example, the cloud platform can include private cloud, public cloud, hybrid cloud, community cloud, distributed cloud, inter-cloud cloud, multi-cloud, etc., or combinations thereof.
[0030] In some embodiments, the processing device 130 may include one or more processors (e.g., a single-core processor or a multi-core processor). For illustrative purposes only, only one processing device 130 is described in application scenario 100. However, it should be noted that application scenario 100 in this application may also include multiple processing devices. Therefore, in this application, the operations and / or method steps performed by one processing device 130 may also be performed jointly or individually by multiple processing devices.
[0031] Storage device 140 may store data, instructions, and / or any other information. In some embodiments, storage device 140 may store data obtained from other components of application scenario 100. In some embodiments, storage device 140 may store data and / or instructions that processing device 130 may execute or use to execute the exemplary methods described in this application.
[0032] For example, storage device 140 may store a view template library. The view template library includes view templates corresponding to patients with different diseases and disease stages in one or more departments. View templates are template information used to guide the construction of patient views. More details about the view template library can be found in the detailed description of step 330. As another example, storage device 140 may store a rule library. The rule library includes anomaly detection rules and clinical warning rules corresponding to patients with different diseases and disease stages in one or more departments. Anomaly detection rules are normal value ranges for identifying abnormal indicators. Clinical warning rules are digital expressions of standardized decision-making logic for risk warning, obtained through analysis of expert second-behavioral data. More details about anomaly detection rules and clinical warning rules can be found in the detailed description of step 340.
[0033] In some embodiments, storage device 140 may include mass storage device, removable storage device, volatile read-write memory, read-only memory (ROM), or any combination thereof.
[0034] Network 150 may include any suitable network capable of facilitating the exchange of information and / or data in application scenario 100. Network 150 may be or include wired networks, wireless networks (e.g., 802.11 networks, Wi-Fi networks), Bluetooth™ networks, Near Field Communication (NFC) networks, and any combination thereof.
[0035] Figure 2 This is a block diagram of the disease management system 200 according to some embodiments of this specification. For example... Figure 2 As shown, the disease management system 200 may include a detection module 210, an acquisition module 220, a determination module 230, a generation module 240, and / or a prompting module 250. In some embodiments, Figure 2One or more modules shown can be implemented by processing device 130.
[0036] The detection module 210 can be used to detect whether a target patient meets the view display conditions. In some embodiments, the detection module 210 can perform one or more of the following operations: displaying a first information list of patients requiring medical management to a target doctor via a first terminal; and determining that the target patient meets the view display conditions in response to detecting that the target doctor selects a target information thumbnail of a target patient via the first terminal. In some embodiments, the first information list includes information thumbnails of multiple patients requiring medical management, and each information thumbnail includes a status marker and at least one core indicator for the corresponding patient. In some embodiments, the detection module 210 can perform one or more of the following operations: receiving a first unique identifier from the first terminal, the first unique identifier being obtained by the first terminal through near-field interaction with a first identifiable marker set on the bed; determining the patient corresponding to the bed based on the first unique identifier, and identifying the patient as a target patient meeting the view display conditions. In some embodiments, the detection module 210 can perform one or more of the following operations: receiving a second unique identifier from the first terminal; determining a second information list of patients corresponding to the ward based on the second unique identifier, and displaying the second information list via the first terminal. In some embodiments, the second unique identifier is obtained by the first terminal through near-field interaction with a second identifiable marker set on the ward. In some embodiments, the first identifiable marker is an NFC marker, and the second identifiable marker is a Bluetooth beacon. In some embodiments, the detection module 210 may perform one or more of the following operations: receiving a third unique identifier from the target patient's second terminal; in response to determining the target doctor corresponding to the doctor's nameplate based on the third unique identifier, obtaining relevant information about the target doctor, and displaying the relevant information about the target doctor through the second terminal. In some embodiments, the third unique identifier is obtained by the second terminal through near-field interaction with the third identifiable marker set on the doctor's nameplate. For a detailed description of the detection module 210, please refer to the relevant description of step 310.
[0037] The acquisition module 220 can be used to acquire patient information of the target patient. In some embodiments, the patient information includes the target disease, the target disease course, and examination information. For a detailed description of the acquisition module, please refer to the relevant description of step 320.
[0038] The determining module 230 can be used to determine a patient view template based on the target disease and the target disease course. In some embodiments, the determining module 230 can determine a target standard view template corresponding to the target disease and the target disease course as a patient view template from a view template library. In some embodiments, the view template library includes standard view templates corresponding to patients with different diseases and different disease courses in the target department where the target patient is located. The standard view templates are obtained by learning from the first behavioral data of experts in the target department. In some embodiments, the first behavioral data includes data related to interface interaction behavior and doctor-patient communication behavior. In some embodiments, the determining module 230 can perform one or more of the following operations: determining whether the target doctor using the first terminal has a personalized view template set for the target disease and the target disease course based on the account information logged in on the first terminal; and in response to determining that a personalized view template exists, using the personalized view template as a patient view template; or in response to determining that no personalized view template exists, determining a target standard view template from the view template library as a patient view template. In some embodiments, the view template library includes multiple expert view templates corresponding to patients with different diseases and disease stages in the target department. Each expert view template is obtained by learning from the expert behavior data of a single expert in the target department. Personalized view templates are constructed by the target physician based on any expert view template. For a detailed description of the determination module 230, please refer to the relevant description of step 330.
[0039] The generation module 240 can be used to generate a target patient view for a target patient based on a patient view template and examination information, and display the target patient view via a first terminal. In some embodiments, the examination information includes the indicator values of multiple indicators for the target patient, and the patient view template includes indicator weight information corresponding to multiple view areas. In some embodiments, the generation module 240 can perform one or more of the following operations: determining the abnormal inspection results of the indicator values of multiple indicators based on abnormal inspection rules; for each view area, determining at least one first target indicator displayed in the view area based on the abnormal inspection results and the indicator weight information corresponding to the view area; and generating a target patient view based on at least one first target indicator and its indicator value corresponding to each view area. In some embodiments, the view area includes at least one of the following areas: a first area configured to display summary information of indicator changes; a second area configured to display early warning indicators related to complications; a third area configured to display core indicators; and a fourth area configured to display indicators corresponding to the core indicator category. In some embodiments, the generation module 240 may perform one or more of the following operations: acquiring the clinical warning rules of the target department where the target patient is located; in response to determining that at least one second target indicator among multiple indicators meets the target warning condition among multiple warning conditions, generating a target patient view based on at least one first target indicator and its value, at least one second target indicator and its value, and the target response action corresponding to the target warning condition for each view area. In some embodiments, the clinical warning rules include multiple warning conditions and their respective corresponding response actions. The clinical warning rules are obtained by learning from the second behavioral data of experts in the target department, and the second behavioral data is related to the issuance of medical orders. For a detailed description of the generation module 240, please refer to the relevant description of step 340.
[0040] The prompting module 250 can be used to issue prompts through a first terminal. In some embodiments, the prompting module 250 can perform one or more of the following operations: in response to the patient view template being a personalized view template, acquiring interaction behavior data between the target doctor and the target patient view; based on the target standard view template and the interaction behavior data, determining whether the target doctor has missed any core indicators; in response to determining that the target doctor has missed any core indicators, issuing a prompt through the first terminal. For a detailed description of the prompting module 250, please refer to the relevant description of step 350.
[0041] In some embodiments, the detection module 210, acquisition module 220, determination module 230, generation module 240, and / or prompting module 250 may be implemented on the same or different processing devices. In some embodiments, the disease management system 200 may include one or more other modules and / or omit one or more modules described above. In some embodiments, a module may be split into multiple modules, or multiple modules may be merged into one module.
[0042] Figure 3 This is a flowchart illustrating an intelligent disease management method according to some embodiments of this specification. In some embodiments, the processing device 130 and / or the disease management system 200 can perform... Figure 3 .like Figure 3 As shown, the intelligent disease management process 300 includes the following steps.
[0043] Step 310: The target patient is detected to meet the view display conditions. In some embodiments, the processing device 130 or the detection module 210 may perform step 310.
[0044] The target patient is a patient requiring medical management, such as an inpatient. The view display conditions are the conditions under which the target patient view is displayed to the target doctor on the first terminal. The target doctor is the doctor who manages the target patient's condition, such as the inpatient's resident physician or attending physician. The target patient view is a personalized patient view built based on the target patient's situation (e.g., patient information such as the target disease, the target disease stage, and examination information). The patient view refers to the visual interface used to present patient information. In some embodiments, the target patient view can also be further built based on the target doctor's situation (e.g., their preferences). For a detailed description of the target patient view, see the relevant description in step 340.
[0045] In some embodiments, the target doctor can actively click on the target patient's patient view entry through a patient management application (such as a doctor's assistant) installed on the first terminal. The patient management application helps the target doctor manage the entire process of patient diagnosis and treatment. For example, it can be used for ward rounds, shift handovers, and case discussions for hospitalized patients. This specification uses ward rounds as an example for detailed explanation. In response to detecting that the target doctor has clicked on the target patient's patient view entry, the processing device 130 determines that the target patient meets the view display conditions. Multiple patient view entries can be set in the patient management application so that the target doctor can access the target patient's view through different paths. The target doctor can click on the target patient's patient view entry at any time (e.g., before or after ward rounds) and at any location.
[0046] In some embodiments, the processing device 130 displays a first information list of patients requiring medical management to a target doctor via a first terminal. In response to detecting that the target doctor selects a target patient's target information thumbnail via the first terminal, it determines that the target patient meets the view display conditions. The first information list is a list of brief information about multiple patients requiring medical management by the target doctor. In ward round applications, it can also be referred to as a ward round queue. The first information list includes information thumbnails of multiple patients requiring medical management. Each patient's information thumbnail can serve as the patient view entry point for that patient. Alternatively, each patient's information thumbnail includes the patient view entry point for that patient. In some embodiments, before the target doctor performs medical management, a reminder to view the first information list can be issued via the first terminal.
[0047] Information thumbnails can display brief information about patients whose conditions require management. For example, an information thumbnail may include the patient's basic information, status markers, and at least one core indicator.
[0048] Basic information includes the patient's name, bed number, disease type, and course of illness. The disease type refers to the specific illness the patient suffers from, such as lung cancer or gastric perforation. The course of illness indicates the current stage of treatment. Various treatments have pre-defined treatment procedures, dividing the entire process into multiple stages. For example, for inpatient surgical treatment, the treatment process can be divided into the admission stage, preoperative stage, intraoperative stage, postoperative stage, discharge assessment stage, and follow-up stage.
[0049] Core indicators are quantifiable metrics that have a critical impact on patient management. Examples include blood pressure, pulse, albumin, respiration, and sodium levels. These core indicators may differ among patients requiring management.
[0050] Core indicators may include abnormal indicators for patients requiring medical management. These abnormal indicators are those exceeding the normal range. Processing device 130 can analyze the patient's examination information based on abnormal examination rules corresponding to the patient's disease type and course to determine the presence of abnormal indicators. A detailed description of determining abnormal indicators based on abnormal examination rules can be found in the relevant description of step 340.
[0051] Core indicators may include high-weight indicators that require special attention. In some embodiments, the information that doctors focus on during the diagnosis and treatment of patients from different departments, with different diseases, and at different stages of disease often differs. Therefore, embodiments of this specification support setting corresponding view templates for patients from different departments, with different diseases, and at different stages of disease. Each view template may contain indicator weight information (such as indicator category weight and specific indicator weight) for patients in that specific department, with different diseases, and at different stages of disease. For patients requiring disease management, a corresponding view template can be matched according to their department, disease, and stage of disease, and their high-weight indicators can be identified accordingly. For example, high-weight indicators may be the two indicators with the highest weight among all the patient's indicators, or the two indicators with the highest weight in the category with the highest indicator category weight.
[0052] In some embodiments, the view template includes a corresponding standard view template and a personalized view template. For patients requiring medical management, if the target physician has already set up a corresponding personalized view template for the patient's department, disease type, and disease course, high-weight indicators can be determined based on this personalized template; if no personalized template has been set, high-weight indicators can be determined based on the standard view template corresponding to the department, disease type, and disease course. For more information on view templates and indicator weights, please refer to step 330. Figure 8 , Figure 9 Related descriptions.
[0053] Core metrics can include personalized metrics that the target physician prefers to focus on. The target physician can configure the core metrics they wish to display in the information thumbnails through the settings options within the disease management application.
[0054] Status markers are labels that indicate whether a patient's status is normal. Processing device 130 can mark patients with abnormal indicators as "indicator abnormal" and patients without abnormal indicators as "indicator normal".
[0055] For example, such as Figure 4 As shown, the target doctor's first information list can include thumbnails of information for 10 patients whose conditions need to be managed. Taking patient A's information thumbnail as an example, the information thumbnail can include patient A's name "A", bed number "02", disease course "12 hours after surgery", core indicators "blood pressure, albumin" and status mark "abnormal indicators".
[0056] In some embodiments, the information thumbnails of multiple patients awaiting medical management are determined in order of priority according to the patients awaiting medical management.
[0057] As an example only, priority is related to at least one of the following: whether the patient is a newly admitted patient, a post-operative patient, or a patient in an abnormal condition. For example, corresponding individual scoring items can be set according to whether the patient is a newly admitted patient, a post-operative patient, or a patient in an abnormal condition, and a corresponding score can be determined based on the number of days corresponding to each individual scoring item (e.g., number of days in hospital, number of days after surgery, number of days in an abnormal condition, etc.). Then, the number of days for multiple individual scoring items are weighted and summed to obtain a priority score, and the corresponding priority is determined based on the priority score.
[0058] As another example, prioritization can be determined based on the bed number of patients requiring medical care. For example, such as... Figure 4 As shown, thumbnails of information for multiple patients awaiting medical management are sorted by bed number from smallest to largest.
[0059] As another example, priorities can be determined based on the target doctor's settings. For instance, the target doctor can directly adjust the priority by clicking, dragging, or other operations on the primary terminal. Alternatively, the target doctor can pre-set the method for determining priorities, such as "by bed number from smallest to largest."
[0060] In some embodiments of this specification, the patient priority information thumbnails (combining dimensions such as new admission, postoperative, and abnormal status) can help doctors prioritize high-priority patients, rationally allocate treatment efforts, and ensure timely management of the condition of key patients.
[0061] In some embodiments, the target physician can select the target information thumbnail by clicking anywhere or a specific location on the target patient's target information thumbnail. For example, such as Figure 4 As shown, the target doctor can click the "Full View" button in the target patient "A" target information thumbnail to select it. At this time, the processing device 130 can determine that the target patient "A" meets the view display conditions.
[0062] In some embodiments of this specification, doctors can trigger the display of a view by selecting a thumbnail of the patient's information to be managed. The information thumbnail allows doctors to preview the patient's core indicators and status markers, helping them to quickly filter out target patients. This simplifies the process of retrieving the patient view and improves the efficiency of disease management during ward rounds.
[0063] In some embodiments, the processing device 130 receives a first unique identifier from a first terminal, the first unique identifier being obtained by the first terminal through near-field interaction with a first identifiable marker disposed on the bed; based on the first unique identifier, it determines the patient corresponding to the bed and identifies the patient as the target patient that meets the view display conditions.
[0064] The first unique identifier is used to identify the hospital bed. Each first unique identifier corresponds to one hospital bed. For example, the first unique identifier for the hospital bed where patient "A" is located is "02". The first identifiable mark is a physical tag placed on the hospital bed to identify a specific bed. For example, the first identifiable mark can include an NFC tag, a QR code, a barcode, etc. There is a one-to-one correspondence between the first unique identifier and the first identifiable mark. Each first identifiable mark can have a corresponding first unique identifier built into it or bound to it.
[0065] Figure 5 This is a schematic diagram illustrating the near-field interaction process with a first terminal according to some embodiments of this specification. For example... Figure 5 As shown, each bed in ward A is equipped with an NFC tag as a first identifiable marker. When the NFC module of the first terminal approaches or touches the NFC tag on bed 02, the NFC tag is activated and interacts with the first terminal in the near field. The first terminal reads the built-in or bound first unique identifier "02" from the NFC tag and sends it to the processing device 130. Based on the correspondence between beds and patients, the processing device 130 determines that the patient corresponding to the bed with the first unique identifier "02" is "A". At this time, the processing device 130 can determine that patient "A" is the target patient who meets the view display conditions.
[0066] In some embodiments, after determining the patient corresponding to the first unique identifier, the processing device 130 may first determine whether the patient is a patient under the responsibility of the target doctor. If not, the processing device 130 may send a prompt message to the first terminal 110 (such as "The current bed is not a patient under your care, do you want to view it?"), and then determine whether the patient is a target patient that meets the view display conditions based on the feedback information input by the target doctor through the first terminal 110; if so, it directly determines that the patient is a target patient that meets the view display conditions.
[0067] In some embodiments of this specification, the view display is triggered by near-field interaction between the first terminal and the identifiable marker on the bed, which enables rapid and accurate retrieval of the patient's view, avoids the tedious operation of manually searching for patient information, and improves the convenience of operation during ward rounds.
[0068] In some embodiments, the processing device 130 receives a second unique identifier from a first terminal, the second unique identifier being obtained by the first terminal through near-field interaction with a second identifiable marker located in the ward; determines a second information list of patients corresponding to the ward based on the second unique identifier, and displays the second information list through the first terminal.
[0069] The second unique identifier is used to identify the ward. Each second unique identifier corresponds to one ward. For example, the second unique identifier for the ward where the target patient "A" is located is "ward A". The second unique identifier is obtained by the first terminal through near-field interaction with the second identifiable marker set in the ward.
[0070] The second identifiable tag is a physical tag carrier placed inside or at the entrance of a ward to identify a specific ward. For example, the second identifiable tag may include an RFID tag, a Bluetooth beacon, an infrared reflective tag, etc. There is a one-to-one correspondence between the second unique identifier and the second identifiable tag. Each second identifiable tag may have a corresponding second unique identifier built into it or bound to it. In some embodiments, the types of the first identifiable tag and the second identifiable tag may be the same or different. The detection range or activation range of the first identifiable tag and the second identifiable tag may be the same or different. In some embodiments, the second identifiable tag is a Bluetooth beacon, the first identifiable tag is an NFC tag, and the detection range or activation range of the second identifiable tag is greater than that of the first identifiable tag.
[0071] The second information list is a list of information about patients in the ward corresponding to the second unique identifier. For example, the ward could be a list of brief information about all patients in the ward where the target patient resides. In some embodiments, the second information list is a list of information about patients in the ward corresponding to the second unique identifier who are under the care of the target doctor. For example, the second information list includes thumbnails of information about patients "A" and "E" under the care of the target doctor in "ward A". The format of the second information list is similar to that of the first information list described above, and will not be repeated here.
[0072] As an example only, combined with Figure 5As shown, the second identifiable marker is a Bluetooth beacon, deployed inside or at the entrance of ward A, and configured to continuously broadcast a second unique identifier corresponding to ward A. The first terminal continuously scans for Bluetooth signals. When the strength of the Bluetooth signal it scans reaches a strength threshold and / or the distance to the Bluetooth beacon reaches a distance threshold, it determines that the target doctor has entered or is approaching the ward corresponding to the second unique identifier, and sends the second unique identifier to the processing device 130. The processing device 130 determines the corresponding ward (i.e., ward A) and the patients "D", "A", and "D" in that ward based on the ward identification number, the correspondence between wards and patients, and the second unique identifier. The processing device 130 can generate a second information list based on the relevant information of these patients. Alternatively, the processing device 130 can further determine whether patients "D", "A", and "D" include patients under the target doctor's care. If not, the processing device 130 can send a prompt message to the first terminal 110 (e.g., "There are no patients under your care in the current ward; please confirm before entering"). If they are included, it obtains the relevant information of patients "A" and "D" under the target doctor's care and generates a second information list. In some embodiments, after the processing device 130 generates the second information list, it can directly display the second information list through the first terminal. Alternatively, the processing device 130 can issue a prompt through the first terminal to ask the target doctor whether they want to display the second information list.
[0073] Furthermore, after the target doctor enters ward A, he can interact with the NFC tag (i.e., the first identifiable tag) placed on the target patient's bed through the first terminal, so that the target patient view corresponding to the bed is displayed on the first terminal.
[0074] In some embodiments of this specification, a list of patients in a ward is obtained through near-field interaction between the terminal and a identifiable marker in the ward. This allows doctors to quickly view information about all or some of the patients in the ward and to plan the order of ward rounds in a coordinated manner, thereby further optimizing the process of managing the patient's condition in the ward.
[0075] In some embodiments of this specification, NFC tags and Bluetooth beacons are used as identifiable markers for hospital beds and wards, respectively, taking into account the different accuracy and coverage requirements of near-field interaction, ensuring the rapid and stable acquisition of patient information and ward information, and guaranteeing the reliability of view triggering and list display.
[0076] In some embodiments, the processing device 130 can receive a third unique identifier from the second terminal of the target patient. The third unique identifier is obtained by the second terminal through near-field interaction with a third identifiable mark set on the doctor's nameplate. In response to determining the target doctor corresponding to the doctor's nameplate based on the third unique identifier, the processing device 130 obtains relevant information about the target doctor and displays the relevant information about the target doctor through the second terminal.
[0077] The third unique identifier is used to identify the doctor. Each third unique identifier corresponds to one doctor. For example, the third unique identifier for the target doctor "Zhang San" is "D01". The third identifiable tag is a physical tag carrier set on the doctor's nameplate to identify a specific doctor. For example, the third identifiable tag may include an NFC tag. The processing device receives the third unique identifier from the target patient's second terminal in a similar manner to receiving the first unique identifier from the first terminal, and will not be described again here.
[0078] The target doctor's information includes basic information such as name, department, and areas of expertise, as well as corresponding communication controls. These communication controls serve as the entry point for interaction with the target doctor. Patients can interact with the target doctor on their primary terminal (e.g., by sending messages or leaving comments) by clicking the communication control on their secondary terminal.
[0079] Figure 6 This is a schematic diagram illustrating the near-field interaction process with a second terminal according to some embodiments of this specification. (In conjunction with...) Figure 6 As shown, after receiving the third unique identifier "D01" from the second terminal device, the processing device 130 determines the target doctor "Zhang San" corresponding to the doctor's nameplate based on the correspondence between the doctor and the third unique identifier. The processing device 130 further determines whether the target doctor "Zhang San" is the doctor responsible for the target patient. If not, the processing device 130 can send a prompt message to the second terminal 120 (such as "The current doctor is not your attending physician, please ask the other party to confirm"). If yes, it obtains the relevant information of the target doctor and displays the relevant information of the target doctor through the second terminal.
[0080] In some embodiments of this specification, doctor-related information is displayed through interaction between the patient terminal and the doctor's nameplate, which facilitates patients to quickly obtain doctor information and facilitates doctor-patient communication.
[0081] Step 320: Obtain patient information of the target patient. In some embodiments, the processing device 130 or the acquisition module 220 may perform step 320.
[0082] The patient information of the target patient is information related to the target patient's condition. In some embodiments, the patient information of the target patient may include the target patient's basic information, target disease, target disease course, examination information, etc. The target disease is the type of disease the target patient suffers from. The target disease course is the current treatment stage of the target patient. For a detailed description of the disease and disease course, please refer to the relevant description in step 310. The examination information includes a set of various indicators (e.g., health indicators and / or diagnostic indicators, hereinafter referred to as indicators) of the target patient obtained through medical testing methods and their corresponding values. In some embodiments, the examination information includes the indicator values of multiple indicators of the target patient.
[0083] In some embodiments, the processing device 130 can obtain patient information of the target patient from a hospital information system, such as an outpatient information database, a patient condition management database, or an inpatient management database.
[0084] Step 330: Determine a patient view template based on the target disease and target disease course. In some embodiments, the processing device 130 or the determination module 230 may perform step 330.
[0085] A patient view template is a view template used to guide the construction of a patient view (i.e., a target patient view). It is a view template selected from the view template library based on the target patient and / or target doctor's situation.
[0086] When diagnosing and treating patients with different diseases and disease stages in different departments, doctors focus on different information. Therefore, some embodiments in this specification can construct a view template library, including setting different view templates for patients with different diseases and disease stages in different departments. A view template corresponding to a certain disease and disease stage in a certain department can be used to generate patient views corresponding to patients with that disease and disease stage in that department. For example, the view template library includes view templates corresponding to patients with different diseases and disease stages in the target department where the target patient is located. The processing device 130 can select a view template corresponding to the target disease stage and target disease from the view template library as the patient view template.
[0087] In some embodiments, the patient view template may include indicator weight information, interface design information, etc., corresponding to multiple view areas.
[0088] A view area is a separate interface space unit in the target patient view that is divided by function and used to display specific types of clinical information. Figure 7 This is a schematic diagram of a target patient view according to some embodiments of this specification. For example, as shown... Figure 7 As shown, the view area of the target patient view may include a first area 710, a second area 720, a third area 730, and a fourth area 740.
[0089] The first area 710 is configured to display summary information on changes in indicators. This summary information is a briefing of information that is automatically extracted and structured to represent the dynamic changes in certain core indicators of the target patient. For example, summary information on postoperative indicator changes for a tumor surgery patient could include "Right anterior thoracic drainage volume on September 10th was 300ml, an increase of 120ml compared to September 9th."
[0090] The second area 720 is configured to display early warning indicators related to complications. These early warning indicators are quantifiable metrics that can characterize in advance the risk, trend, or potential likelihood of a target patient developing a target complication after a specific medical intervention (such as surgery). For example, postoperative complication indicators for cancer surgery patients may include inflammatory markers and exudate markers.
[0091] Zone 730 is configured to display core metrics. Core metrics are quantifiable indicators that have a critical impact on the target patient. A detailed description of core metrics can be found in the relevant description in step 310.
[0092] Zone 740 is configured to display indicators corresponding to core indicator categories. Indicator categories are collections formed by categorizing multiple indicators based on clinical attributes, therapeutic uses, etc. Core indicator categories are those that have a critical impact on the target patient. For example, ... Figure 4 As shown, the core indicators after lung tumor surgery can include drainage indicators, laboratory indicators, physical signs indicators, and nutritional indicators. Indicators corresponding to different core indicator categories can be integrated and displayed in different subpages or sub-regions. The indicators corresponding to core indicator categories are those belonging to the core indicator category. For example, drainage indicators include multiple indicators such as drainage volume, drainage color, and drainage characteristics.
[0093] In some embodiments, the target patient view may also include other view areas. For example, a view area for displaying warning prompts, or a view area for presenting communication information. In some embodiments, the indicators in the second area 720 may also be displayed in a categorized manner.
[0094] In some embodiments of this specification, the view area is divided into modules such as indicator change summary, complication warning, and core indicators according to function, so as to realize the classified display of disease information, allowing doctors to quickly locate different types of diagnostic and treatment data as needed, and improving the convenience of information retrieval.
[0095] Indicator weight information reflects the importance of individual indicators or indicator categories in clinical decision-making. As mentioned earlier, different view templates correspond to different diseases and / or disease courses. Therefore, the indicator weight information contained in different view templates is specifically designed for their corresponding diseases and disease courses. For example, the patient view template selected for a target patient contains indicator weight information that reflects which indicators or indicator categories are more valuable for clinical decision-making for the target patient's target disease and target disease course. In some embodiments, indicator weight information may include indicator category weights and indicator weights. Indicator category weights reflect the importance of various indicators in clinical decision-making. Indicator weights reflect the importance of individual indicators in clinical decision-making.
[0096] As mentioned earlier, different view areas can present different information, and therefore the indicator weight information corresponding to different view areas also differs. For example, the indicator weight information corresponding to the first, second, and third areas includes indicator weights, which reflect the importance of each indicator based on the functional positioning of that area. Taking the first area as an example, its function focuses on monitoring the dynamics of the disease, so indicators that need to be closely tracked will be given higher weights; while in the second area, due to a greater focus on the risk of complications, indicators related to complications have relatively higher weights. As another example, the weight information corresponding to the fourth area includes not only indicator weights but also indicator category weights. The higher the indicator category weight, the more prominent the overall importance of that category in the fourth area; and within each indicator category, each specific indicator is also assigned a different indicator weight to further refine its relative importance. In some embodiments, the indicator weight information corresponding to a view area only includes the indicator weight information of a preset indicator set related to that view area. The preset indicator set can be determined according to medical guidelines, etc., or it can be set manually by the user. For example, the indicator weight information corresponding to the third area only includes the weight information of indicators in a preset indicator set related to complications.
[0097] The interface design information is related to the interface design of the target patient view, including indicator display rules, interaction logic, and visual presentation specifications.
[0098] Indicator display rules are pre-defined display rules for indicators within each view area. For example, indicator display rules can include layout, display rules, and content presentation format (such as numerical values or trend charts). The layout refers to the arrangement of the various view areas. For example... Figure 7 As shown, the layout includes the first area 710 and the second area 720 on the left; the third area 730 and the fourth area 740 on the right, sharing the view area. Display rules are the rules governing how various indicators or indicator categories are displayed (e.g., display order). For example, as... Figure 7 As shown, the display rules for the first area 710 may include "prioritizing the display of indicators with abnormal values". For example, the display rules for the second area 720 may include "displaying only 3 indicators in the second area". Furthermore, taking the fourth area 740 as an example, the display rules may include: the higher the weight of an indicator category, the earlier that indicator category is displayed in the fourth area 740; the higher the indicator weight, the earlier that indicator is displayed in the view areas of each indicator category.
[0099] Interaction logic refers to the response rules (such as view area switching rules and triggering rules for detailed indicator information) that govern the interaction between the target doctor and the patient's view interface. For example, using... Figure 7Taking the third region 730 and the fourth region 740 as examples, the interaction logic includes that when the "core indicators", "traffic-generating indicators", "test indicators", "vitality indicators" and "nutrition indicators" in the third region 730 and the fourth region 740 are clicked, the shared view area of the third region 730 and the fourth region 740 will display multiple indicators of the corresponding core indicators or multiple indicators of indicator categories.
[0100] Visual presentation guidelines are the interface visual design standards for the target patient view, including color schemes, font styles, icon labels, and the labeling format for abnormal indicators.
[0101] In some embodiments, the interface design information may be pre-set and / or set based on expert first-behavior data.
[0102] In some embodiments, the view template library includes standard view templates, expert view templates, and personalized view templates corresponding to patients with different diseases and disease stages in the target department of the target patient. The patient view template corresponding to the target patient is any one of the standard view templates, expert view templates, and personalized view templates corresponding to the target disease and disease stage.
[0103] The standard view template is generated based on the first-behavioral data of multiple experts in a specific department, reflecting the consensus experience of the expert group in that department. For example, the standard view template for a target department is obtained by learning from the first-behavioral data of experts in the target department.
[0104] Experts in the target department are those with extensive clinical experience in the relevant field. For example, based on doctors' professional titles, associate chief physicians and above in the target department can be identified as experts. Another example is based on expert evaluations at different levels (such as national or hospital-level), where doctors rated as Level 1 experts or above can be identified as experts. Yet another example is that all doctors in the target department, excluding interns, can be considered experts in that department.
[0105] First-order behavioral data refers to data related to the behaviors generated by experts during clinical diagnosis and treatment. For example, first-order behavioral data includes data related to interface interaction behaviors and doctor-patient communication behaviors. Data related to interface interaction behaviors (referred to as interaction behavior data) can include the expert's operational data when using the patient view, including actions such as clicking, browsing, hiding, or sorting indicators, as well as related information such as time and frequency. For example, when viewing the patient view of a post-tumor surgery patient, an expert always prioritizes clicking "drainage" and "temperature trend graph." In some embodiments, the processing device 130 can acquire data related to the expert's interface interaction behaviors through event tracking technology. Event tracking technology is a technique that inserts specific code into the patient management application (e.g., doctor's assistant) and / or the system it accesses (e.g., hospital HIS system, electronic medical record system) of the first terminal to capture, process, and send user behavior or event data. By recording user operational behaviors (such as clicking, browsing, and text input), event tracking technology ensures that the collected interaction behavior data has quantifiable, analyzable, and applicable characteristics.
[0106] Data related to doctor-patient communication behavior (hereinafter referred to as communication behavior data) may include doctor-patient communication dialogues or corresponding communication records (such as ward round records) during clinical communication processes such as consultations and ward rounds. For example, a bedside terminal device can collect doctor-patient communication dialogues during ward rounds, and transcribe these dialogues into text using speech recognition and natural language processing (NLP) technologies, extracting indicators mentioned during the doctor-patient communication process. In some embodiments, the processing device 130 can obtain data related to doctor-patient communication behavior from a storage device 140 (e.g., an outpatient system, an inpatient system, etc.).
[0107] In some embodiments of this specification, the first line of data covers interface interaction and doctor-patient communication behavior, making the learning dimensions of the standard view template more comprehensive. It not only learns the doctor's clinical diagnosis and treatment ideas, but also takes into account the clinical needs related to doctor-patient communication, making the generated template more in line with the actual diagnosis and treatment process and improving its practicality.
[0108] Figure 9 This is a schematic diagram illustrating the generation of view templates according to some embodiments of this specification. (In conjunction with...) Figure 9As shown, the processing device 130 can acquire first-behavioral data from multiple experts in the target department and generate a standard view template based on this data. Specifically, it can acquire first-behavioral data from multiple experts regarding patients with different diseases and disease stages, such as interaction and communication data with patients of different diseases and disease stages. The processing device 130 can preprocess the first-behavioral data by deduplicating and removing abnormal data (e.g., expert errors). Then, it determines the weight of each indicator or the category weight of each indicator based on factors such as click frequency, dwell time, and number of mentions. Furthermore, it further statistically analyzes the number and frequency of indicators viewed by experts in each view area to determine the interface design (e.g., indicator display rules).
[0109] In some embodiments of this specification, the standard view template is derived from the first-behavioral data learning of multiple experts in the target department. This not only incorporates the clinical experience and diagnostic consensus of multiple experts, but also ensures the professionalism and universality of the template, providing doctors with an information display solution that conforms to the department's diagnostic and treatment standards and reducing the cost of information interpretation.
[0110] Expert view templates are generated based on the expert behavior data of a specific expert in a particular department, reflecting that expert's personal experience, habits, and preferences. In some embodiments, each expert view template is obtained by learning from the expert behavior data of a single expert in the target department. Expert behavior data may include individual expert interaction behavior data and / or communication behavior data. Different experts can generate their own corresponding expert view templates. Figure 9 As shown, the content and acquisition method of expert behavior data are similar to those of the first behavior data, and will not be repeated here. The method of generating an expert view template based on the expert behavior data of a single expert is similar to the method of generating a standard view template based on the first behavior data of multiple experts, and will not be repeated here.
[0111] Personalized view templates are view templates that doctors in the target department can set or adjust themselves. Combined with... Figure 9 As shown, personalized view templates are constructed by the target physician based on any expert view template or standard view template. For example, the processing device 130 uses a standard view template corresponding to a certain disease and a certain disease course by default to generate patient views for patients with that disease and disease course. Physicians can adjust the settings to generate patient views based on a certain expert view template as needed, or further modify indicators, layouts, etc., based on the standard view template or expert view template to form a personalized view template exclusive to the physician.
[0112] In some embodiments of this specification, personalized view templates can be built based on expert view templates, which not only inherit the high-quality clinical experience of individual experts, but also allow doctors to make their own adjustments, thus lowering the threshold for creating personalized templates and enriching the content of the view template library to better meet the usage needs of different doctors.
[0113] In some embodiments, initial view templates corresponding to different diseases and disease courses can be constructed first, based on clinical guidelines and expert experience for different diseases in the target department. In the initial stage of using the disease management application in the target department, these initial view templates can be used to generate patient views, and first-action data from multiple experts can be collected, including communication behavior data and interaction behavior data with these initial view templates. The processing device 130 can periodically, or after the first-action data has accumulated to a certain amount, generate standard view templates corresponding to different diseases and / or disease courses. After the standard view templates are generated, patient views can be generated based on them. The processing device 130 can also periodically, or after the first-action data of a certain expert has accumulated to a certain amount, generate expert view templates corresponding to different diseases and / or disease courses for that expert. After the expert view templates are completed, patient views can be generated for that expert based on them, or with the expert's consent, patient views can be generated using the expert view templates.
[0114] In some embodiments, the processing device 130 may determine a target standard view template corresponding to the target disease and target disease course from a view template library as a patient view template. In some embodiments, the processing device 130 may determine a personalized view template set by a target physician for the target disease and target disease course as a patient view template. For details on determining the patient view template, please refer to [link to relevant documentation]. Figure 8 Related descriptions.
[0115] Step 340: Based on the patient view template and examination information, a target patient view for the target patient is generated and displayed via a first terminal. In some embodiments, the processing device 130 or the generation module 240 may perform step 340.
[0116] The target patient view is a personalized patient view built based on the patient view template. It includes some examination information of the target patient (such as the value of the core indicators) and is used to present the indicator information of the target patient that the target doctor needs to pay attention to.
[0117] In some embodiments, the processing device 130 may generate a target patient view based on anomaly inspection rules, patient view templates, and inspection information.
[0118] The abnormality check rules include normal value ranges for multiple indicators, used to identify abnormal indicators. In some embodiments, the processing device 130 may determine the abnormality check rules statistically based on medical guidelines. For example, the abnormality check rules may include "normal range of blood oxygen: 95% to 100%".
[0119] Figure 10 This is a schematic diagram illustrating the generation of a target patient view according to some embodiments of this specification. For example... Figure 10 As shown, generating a target patient view based on anomaly detection rules includes the following steps:
[0120] Specifically, the processing device 130 determines the anomaly check results for multiple indicators based on anomaly check rules. The anomaly check results include the indicators whose values exceed the normal range corresponding to the indicators in the anomaly check rules, and their corresponding values. For example, the anomaly check results may include the presence of blood oxygen saturation, with a value of 92%.
[0121] Furthermore, based on each view area, the processing device 130 determines at least one first target indicator to be displayed in the view area, based on the anomaly detection results and the indicator weight information corresponding to the view area. The first target indicator is the indicator to be displayed in the view area, determined based on the anomaly detection results and the indicator weight information in the patient view template.
[0122] For example, processing device 130 determines the initial weight of at least one candidate indicator related to the view area from among multiple indicators based on the indicator weight information corresponding to the view area in the patient view template. The candidate indicators for the view area are indicators among multiple indicators for the target patient that are related to that view area and may be displayed in that view area. For example, as mentioned above, the indicator weight information corresponding to the view area only includes the indicator weight information of a preset set of indicators related to that view area. Therefore, the candidate indicators for the view area can be one or more indicators included in their corresponding preset set of indicators.
[0123] The initial weights are the weights of the candidate indicators in the patient view template. For example, based on the weight information (i.e., indicator weights) of the inflammatory indicators "blood oxygen, white blood cell count, calcitonin, and neutrophil count" in the second region 720 of the patient view template, the initial weights of at least one candidate indicator "blood oxygen, white blood cell count, calcitonin, and neutrophil count" are determined to be "0.2, 0.3, 0.3, 0.2".
[0124] Furthermore, the processing device 130 determines the weight of at least one candidate indicator based on its initial weight and the anomaly check results. The weight of the candidate indicator is the adjusted weight based on the anomaly check results. For abnormal indicators, the processing device 130 can increase their initial weight to determine their weight, or directly set their weight to the highest weight value. For normal indicators, the processing device can directly use their initial weight as the weight. For example, continuing the above example, if blood oxygen is abnormal, the initial weight of at least one candidate indicator "blood oxygen, white blood cell count, calcitonin, neutrophil count" can be adjusted to weights "1, 0.3, 0.3, 0.2".
[0125] The processing device 130 determines at least one first target indicator based on the weight of at least one candidate indicator. For example, based on the interface design information of the second area 720 in the patient view template, "the second area only displays 3 indicators", the top three indicators with the highest weight among the candidate indicators, "blood oxygen, white blood cell count, and calcitonin", are determined as the first target indicator.
[0126] In some embodiments of this specification, the weights of candidate indicators are adjusted by combining initial weights with anomaly detection results, and then the first target indicator is determined. This ensures that the indicators displayed in the view area not only conform to weight priority but also highlight abnormal situations, accurately matching the clinical needs for attention to key abnormal indicators and optimizing the information display logic.
[0127] Furthermore, the processing device 130 generates a target patient view based on at least one first target indicator and its value corresponding to each view area. In some embodiments, the processing device may arrange and render the first target indicators and their values for each view area based on the interface design information in the patient view template to generate the target patient view.
[0128] Figure 11 This is a schematic diagram of a target patient view according to some embodiments of this specification. For example, as shown... Figure 11 As shown, taking the second region 720 as an example, the processing device 130 arranges and displays the first target indicators in the second region 720 in descending order of indicator weight based on the first target indicators "blood oxygen, white blood cell count, and calcitonin" and their indicator values.
[0129] In some embodiments, the processing device 130 adds anomaly annotations to indicators showing abnormalities in the target patient view based on anomaly checking rules. The anomaly annotations are prompts indicating the presence of abnormal indicators. For example, such as... Figure 11 As shown, an "downward arrow" annotation is added to the abnormal indicator "blood oxygen" to indicate that the blood oxygen value is below the normal range.
[0130] In some embodiments of this specification, abnormal annotations are added to abnormal indicators to clearly indicate the type, degree, and reference basis of the abnormality, helping doctors to quickly understand the meaning of the abnormality, avoid misjudging abnormal data, and improve the accuracy of disease assessment.
[0131] In some embodiments of this specification, the first target indicator for each view area is determined by combining anomaly detection rules and indicator weights, so that the patient view prioritizes displaying high-weight, abnormal key indicators, helping doctors quickly focus on the key aspects of the condition, reducing the filtering of invalid information, and improving the efficiency of identifying and handling abnormal indicators.
[0132] In some embodiments, the processing device 130 may further generate a target patient view based on the clinical warning rules of the target department.
[0133] Clinical warning rules are the digital expression of standardized decision-making logic used for risk warning. They can identify data combinations and evolution patterns that lead to adverse clinical consequences, informing physicians of potential adverse clinical outcomes and recommending appropriate actions.
[0134] In some embodiments, clinical early warning rules include multiple early warning conditions and their corresponding response actions. An early warning condition is a specific indicator or combination of indicators that must be met to trigger an early warning. For example, an early warning condition may be a value or change in a single indicator, or a combination of values or changes in multiple indicators. The response action corresponding to an early warning condition is the operation performed after the early warning is triggered. As an example only, the response action corresponding to the early warning condition "patient's drainage volume exceeds 300ml, body temperature continues to rise" includes: issuing an early warning of "suspected infection" and suggesting "consider etiological examination".
[0135] Clinical early warning rules are derived from the analysis of expert experience and consensus, and are typically related to changes in indicators, combinations of multiple different indicators, etc. In some embodiments, clinical early warning rules are learned by learning from the second behavioral data of experts in the target department. Second behavioral data is related to the issuance of medical orders. For example, historical medical orders issued by experts can be identified, and the interventions mentioned in those orders (such as increasing medication dosage or conducting special examinations) and the referenced indicator information can be extracted. The interventions and indicator information corresponding to each historical order can be used as second behavioral data. Furthermore, when the indicator information referenced in historical orders includes the value of a certain indicator at different times, the change information of that indicator can also be determined as second behavioral data. For another example, when historical orders do not reference indicator information, the indicator information (including indicator values and indicator change information) from historical reports reviewed by the expert before issuing the historical order can be determined as second behavioral data.
[0136] As an example only, the processing device 130 can obtain expert second-behavioral data through data embedding technology and / or semantic analysis of historical medical orders. Further, the processing device 130 analyzes the second-behavioral data to obtain clinical early warning rules. In some embodiments, the analysis of the second-behavioral data includes: extracting intervention measures and associated indicator information from the second-behavioral data to form "indicator-intervention" data pairs; based on a large number of "indicator-intervention" data pairs, identifying recurring or statistically significant indicator patterns and their corresponding intervention measures through data mining or machine learning methods. For example, frequent itemset mining, association rule learning (such as the Apriori algorithm), or classification models can be used to automatically discover the intervention measures that experts tend to take when certain indicators reach a specific threshold, exhibit a specific trend, or multiple indicators form a specific combination, thereby summarizing this correspondence into clinical early warning rules. Here, the indicator pattern is the early warning condition, and the associated intervention measure is the response action.
[0137] Optionally, the analysis process also includes processing and refining rules for indicator changes. Specifically, when the indicator information associated with historical medical orders includes indicator change information, time-series characteristics such as the rate of change, cumulative value, or duration of continuous abnormality can be calculated. By analyzing the correlation between these time-series characteristics and intervention measures, early warning conditions dependent on dynamic changes in indicators can be identified, such as "heart rate increases by more than 20% within 2 hours" or "blood pressure shows a downward trend in 3 consecutive measurements." Finally, through pattern learning and validation on a large amount of second-behavioral data, a clinically prospective early warning rule base can be automatically or semi-automatically generated, typically in the form of "if [indicator condition] then [trigger early warning and suggest response action]".
[0138] In some embodiments, the learning of clinical early warning rules is conducted on a departmental basis. By analyzing the second behavioral data of experts from different departments, a differentiated early warning rule system applicable to each department can be constructed. Furthermore, to achieve more accurate risk warnings, the above learning process can be refined to be based on different diseases and / or different disease stages. For example, by analyzing the second behavioral data generated by experts in a certain department for patients with a specific disease (such as acute myocardial infarction), it is possible to learn and extract refined clinical early warning rules specifically applicable to that disease within that department.
[0139] Specifically, the processing device 130 can obtain the clinical warning rules corresponding to the target department where the target patient is located. For example, the processing device 130 can obtain the clinical warning rules for the target department "Lung Oncology" where the target patient "A" is located from multiple clinical warning rules stored in the storage device 140. In some embodiments, the processing device 130 can obtain clinical warning rules corresponding to the target department and the target disease.
[0140] Furthermore, in response to determining that at least one second target indicator among multiple indicators satisfies the target warning condition among multiple warning conditions, the processing device 130 can generate a target patient view based on at least one first target indicator and its value, at least one second target indicator and its value, and the target response action corresponding to the target warning condition for each view area.
[0141] The second target indicator is the indicator that meets the early warning conditions. The target early warning conditions are the early warning conditions that the second target indicator must meet. (Combined) Figure 10 As shown, the processing device 130 can determine whether any one or more indicators in the patient's examination information meet any of the multiple warning conditions. If so, it identifies the one or more indicators as the second target indicator and the warning condition as the target warning condition. For example, if the patient's examination information includes "body temperature of 38℃, 39℃, and 40℃ for three consecutive days, and drainage volume of 500ml", and meets the warning condition "the patient's drainage volume exceeds 300ml, and the body temperature continues to rise", then "body temperature of 38℃, 39℃, and 40℃ for three consecutive days, and drainage volume of 500ml" is identified as the second target indicator, and "the patient's drainage volume exceeds 300ml, and the body temperature continues to rise" is identified as the target warning condition. The device then obtains the corresponding target response action: a warning of "suspected infection" and a prompt to "consider etiological examination". It should be understood that at least one second target indicator may or may not be included in at least one first target indicator.
[0142] In some embodiments, the view area of the target patient view further includes a fifth area for displaying warning prompts. The processing device 130 can generate warning prompts based on at least one second target indicator and its value, and a target response action, and present them in the fifth area. For example, the warning prompt includes a description of at least one second target indicator and its value, and the target response action. In some embodiments, the processing device 130 generates warning prompts based solely on the target response action and presents them in the fifth area; the display content corresponding to at least one second target indicator and its value can be displayed in any other view area.
[0143] For example, such as Figure 11 As shown, the processing device 130 can generate the display content of inflammatory indicators in the second area 720 of the target patient view based on the first target indicators "blood oxygen, white blood cell count, calcitonin" and their indicator values, generate the display content of core indicators in the third area 730 of the target patient view based on the second target indicators "body temperature for 3 consecutive days" and "drainage volume" and their indicator values, and based on the target response action: warning "suspected infection" and prompt "consider etiological examination", display the warning prompt "suspected infection, consider etiological examination" in the fifth area 750.
[0144] In some embodiments of this specification, clinical early warning rules are derived from expert second-behavioral data (data related to medical order issuance behavior). This allows for the accurate identification of potential risks and the display of corresponding risk alerts, enabling patients to integrate risk warnings and treatment suggestions. It also helps doctors promptly identify disease risks and develop intervention plans based on expert experience, thereby strengthening disease risk management. Compared to abnormal examination rules, clinical early warning rules are more proactive, alerting doctors to specific possibilities and taking intervention measures before risks fully manifest or worsen, truly achieving a shift from "passive response" to "proactive defense."
[0145] In some embodiments, the processing device 130 can receive communication information input via a communication control from a second terminal, send the communication information to a first terminal, or display the communication information in a target patient view. The communication information may include the target patient's complaints, questions regarding the condition and procedures, etc. Figure 11 As shown, the communication information “vomiting multiple times on the evening of September 1” can be presented in the sixth area 760 of the target patient view.
[0146] In some embodiments of this specification, corresponding communication controls are provided for doctors and communication information is supported, establishing a convenient communication channel between doctors and patients. Patients can promptly report their condition or ask questions, and doctors can quickly receive and process information, improving the interactivity and timeliness of disease management.
[0147] Step 350: Based on the interaction behavior data between the target doctor and the target patient view, a prompt is issued. In some embodiments, the processing device 130 or the prompting module 250 may perform step 340.
[0148] For a detailed description of step 350, please refer to Figure 12 And its related description. In some embodiments, step 350 may be omitted.
[0149] In some embodiments of this specification, by matching patient view templates based on target diseases and target disease courses and generating personalized patient views, accurate and structured display of disease information can be achieved, avoiding information clutter, helping doctors quickly obtain core diagnostic and treatment data, and improving the intelligence and efficiency of disease management.
[0150] In some embodiments, the processing device 130 can generate an indicator focus view and an early warning indicator trend view based on the interaction behavior data of the target doctor and the target patient view, and display them through a first terminal.
[0151] The Indicator Focus View is a magnified view that displays the core indicators of the target patient view or multiple indicators within any indicator category, along with their value trends. The Indicator Focus View supports displaying the values and trends of multiple indicators by category, and uses trend lines to visually illustrate the direction of indicator changes, allowing users to quickly grasp indicator fluctuations.
[0152] After the processing device 130 detects that the target doctor performs a trigger operation (e.g., click, double-click, etc.) at any position in the view area corresponding to the core indicator or any indicator category, it can obtain the indicator values corresponding to multiple time points of the corresponding core indicator or multiple indicators in the indicator category, and generate the corresponding indicator change trend line, which is displayed through the indicator focus view; if you need to exit the indicator focus view, you can perform the trigger operation again.
[0153] The early warning indicator trend view is a display of the changing trends of early warning indicators related to complications in the target patient view. After the target doctor clicks on the menu item for complications (e.g., inflammation, exudate) in the second area 720 of the target patient view, the processing device 130 acquires the various early warning indicators corresponding to the complication and displays a responsive pop-up window in the target patient view, showing the recent changing trends of the corresponding indicators in the form of data lists, trend charts, etc. At the same time, it can also present the normal reference range of the indicators, abnormal annotations, etc., to help the target doctor track the dynamic fluctuations of complication-related indicators in a targeted manner and assist in the assessment of the complication's condition.
[0154] In some embodiments, the processing device 130 can further analyze the target patient view to generate electronic medical documents related to the management of the target patient's condition. Examples include electronic handover logs, intelligent analysis reports of key cases, and electronic medical records.
[0155] An electronic handover log is an electronic log that records handover information between medical staff. The electronic handover log includes at least key patient information and handover report content for the current shift. Key patient information refers to information that needs to be considered during the handover and may include sudden changes in patient indicators within 24 hours (e.g., heart rate suddenly increasing from 60 beats / min to 120 beats / min, abnormally high body temperature), changes in the patient's reported condition, etc. The processing device 130 uses a first intelligent agent to extract changes in key indicators from the target patient view during the current shift and uses preset indicators whose changes exceed a certain threshold, along with their corresponding values, as key patient information. This information is then displayed to the target doctor via the first terminal 110. The target doctor completes the handover report based on this key information, and the first terminal 110 records and sends the target doctor's handover report to the processing device 130. The processing device 130 generates an electronic handover log based on the key patient information and the handover report content, according to the handover log template. The first intelligent agent can automatically determine preset indicators and their corresponding change thresholds by learning from historical handover logs.
[0156] A key case analysis report is an electronic report analyzing key medical records (e.g., records of patients with complex or rare diseases, or records of patients requiring surgical discussion). The report may include multi-dimensional presentation of key disease indicators, a summary of the core medical record, comparative analysis of previous medical records, and key points for case discussion. The processing device 130 can obtain data such as the target patient's laboratory test results, treatment plan execution records, and past medical history from relevant hospital systems. Using a second intelligent agent, it extracts key disease indicators from the target patient's view, performs multi-dimensional integration and in-depth analysis of these data, automatically extracting the essence of the patient's condition and key diagnostic and treatment points, presenting indicator trends and comparisons with similar previous cases, and generating targeted key points for case discussion based on clinical guidelines. The analysis results are then presented to the target physician through the first terminal 110 to assist in case discussion. The processing device 130 can further record the physician's supplementary discussion content, ultimately generating a complete intelligent analysis report for the key case. The second intelligent agent can acquire analytical capabilities by learning data such as key case analysis report templates, historical key case analysis reports, and clinical guidelines.
[0157] Electronic medical records are standardized electronic medical documents that record a patient's daily condition development and treatment process. Electronic medical records may include changes in relevant indicators, records of medical actions, execution of medical orders, and summaries of diagnostic conclusions and treatment plans. The processing device 130 can dynamically extract relevant indicators (such as heart rate, blood pressure, body temperature, etc.) from the target patient's view using a third-party intelligent agent. Simultaneously, it can retrieve corresponding imaging reports, treatment operation records (such as medication adjustments, surgical procedures, nursing interventions, etc.), and medical order execution progress from the hospital's relevant systems. The processing device 130 categorizes and organizes the relevant indicators in the target patient's view and the aforementioned associated data, focusing on analyzing the changing trends of the indicator values and the impact of treatment behaviors and medical order execution on the indicator values. It clarifies the correspondence between the disease progression trajectory and treatment measures, and extracts core treatment nodes and key disease change characteristics. The processing device 130 displays the initial medical record to the target doctor through the first terminal 110. The target doctor can supplement subjective diagnostic judgments, disease assessments, etc., based on the actual treatment situation, or modify and confirm the initial medical record. The first terminal 110 records the doctor's feedback and sends it to the processing device 130. The processing device 130 optimizes and improves the record based on the feedback, generating the final electronic medical record and synchronizing it to the electronic medical record system. Among them, the third intelligent agent can determine relevant indicators by learning data such as medical record templates, historical medical record documents, clinical diagnosis and treatment guidelines and medical order execution standards, as well as the logic for correlation analysis between relevant indicators and other diagnosis and treatment data, the information screening dimensions of medical records, and the content expression standards.
[0158] Figure 8 This is a flowchart illustrating the process of determining a patient view template according to some embodiments of this specification. In some embodiments, Figure 8 The flowchart 800 shown can be used to implement step 330. For example... Figure 8 As shown, process 800 may include the following steps.
[0159] Step 810: Based on the account information logged in on the first terminal, determine whether the target doctor using the first terminal has a personalized view template set for the target disease and the target disease course.
[0160] Account information is the unique identification information used by the target doctor when logging into the patient management application on the primary terminal. It is linked to the target doctor's personal information, target department, permission scope, and personalized configurations (e.g., personalized view templates). As mentioned earlier, personalized view templates are view templates set or adjusted by the doctor themselves. For a detailed description of personalized view templates, please refer to [link to relevant documentation]. Figure 3 And related descriptions.
[0161] In response to determining that the target doctor using the first terminal has a personalized view template set for the target disease and the target disease course, step 820 is executed. In response to determining that the target doctor using the first terminal does not have a personalized view template set for the target disease and the target disease course, step 830 is executed.
[0162] Step 820: Use the personalized view template as the patient view template.
[0163] Step 830: In the view template library, determine the target standard view template corresponding to the target disease and the target disease course as the patient view template.
[0164] As mentioned earlier, the standard view template is generated based on the first-behavioral data of multiple experts in a specific department, reflecting the consensus experience of the expert group in that department. Specifically, the processing device 130 can obtain the standard view template corresponding to the target disease and the target disease course from the view template library as the target standard view template.
[0165] Figure 12 This is a flowchart illustrating the issuance of prompts based on interaction data between a target doctor and a target patient, according to some embodiments of this specification. In some embodiments, Figure 12 The flowchart 1200 shown can be used to implement step 350. For example... Figure 12 As shown, process 1200 may include the following steps.
[0166] Step 1210: Determine whether the patient view template is a personalized view template. If the patient view template is a personalized view template, proceed to step 1220; otherwise, end process 1200 (step 350 is not required at this time).
[0167] Step 1220: Obtain the interaction behavior data of the target doctor and the target patient view.
[0168] Interactive behavior data can be all the operational data of the target doctor during the process of viewing the target patient view using a personalized view template. The target doctor's behavioral interaction data and... Figure 3 The data on the interactive behaviors of the experts described are similar, so they will not be repeated here.
[0169] Step 1230: Based on the target standard view template and interaction behavior data, determine whether the target doctor has missed any core indicators.
[0170] Specifically, the processing device 130 can identify the core indicators in the target standard view template, and then determine whether the target doctor has performed operations such as "deleting core indicators, not browsing core indicators, or sorting core indicators to the back" based on interactive behavior data, so as to determine whether the target doctor has missed core indicators.
[0171] Step 1240: In response to the determination that the target doctor has missed a core indicator, a prompt is issued through the first terminal.
[0172] For example, a pop-up message could be sent to the target via the first terminal, prompting them to ask, "Please note whether you have been paying attention to changes in body temperature?"
[0173] In some embodiments of this specification, when using personalized view templates, by monitoring interactive behavior data and alerting to omissions of core indicators, the flexibility of personalized configuration is preserved, while avoiding the neglect of key medical data due to template adjustments, thus ensuring the comprehensiveness and security of diagnosis and treatment decisions.
[0174] In some embodiments, the processing device 130 can determine whether the target doctor is an expert in the target department. If the doctor is an expert, step 350 can be omitted. If the doctor is not an expert, steps 1220-1240 can be performed to prevent the target doctor from missing key indicators.
[0175] The basic concepts have been described above. Obviously, for those skilled in the art, the detailed disclosure above is merely illustrative and does not constitute a limitation of this specification. Although not explicitly stated herein, those skilled in the art may make various modifications, improvements, and corrections to this specification. Such modifications, improvements, and corrections are suggested in this specification and therefore remain within the spirit and scope of the exemplary embodiments described herein.
[0176] Furthermore, this specification uses specific terms to describe embodiments thereof. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Moreover, certain features, structures, or characteristics in one or more embodiments of this specification can be appropriately combined.
[0177] Furthermore, unless expressly stated in the claims, the order of processing elements and sequences, the use of numbers and letters, or other names described in this specification are not intended to limit the order of the processes and methods described herein. Although various examples have been discussed in the foregoing disclosure of some embodiments of the invention that are currently considered useful, it should be understood that such details are for illustrative purposes only, and the appended claims are not limited to the disclosed embodiments; rather, the claims are intended to cover all modifications and equivalent combinations that conform to the spirit and scope of the embodiments described herein. For example, while the system components described above can be implemented using hardware devices, they can also be implemented solely using software solutions, such as installing the described system on existing servers or mobile devices.
[0178] Similarly, it should be noted that, in order to simplify the description disclosed herein and thus aid in the understanding of one or more embodiments of the invention, the foregoing description of embodiments in this specification may sometimes combine multiple features into a single embodiment, drawing, or description thereof. However, this method of disclosure does not imply that the subject matter of this specification requires more features than those mentioned in the claims. In fact, the embodiments contain fewer features than all the features of a single embodiment disclosed above.
[0179] In some embodiments, numbers describing the quantity of components and attributes are used. It should be understood that such numbers used in the description of embodiments are modified in some examples with the terms "approximately," "approximately," or "generally." Unless otherwise stated, "approximately," "approximately," or "generally" indicates that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may be changed depending on the characteristics required by individual embodiments. In some embodiments, numerical parameters should take into account specified significant digits and employ a general method of digit reservation. Although the numerical ranges and parameters used to confirm their breadth of range in some embodiments of this specification are approximate values, in specific embodiments, such values are set as precisely as feasible.
[0180] For each patent, patent application, patent application publication, and other material, such as articles, books, specifications, publications, and documents, referenced in this specification, the entire contents of which are incorporated herein by reference. This excludes historical application documents that are inconsistent with or conflict with the content of this specification, as well as documents that limit the broadest scope of the claims in this specification (currently or subsequently appended to this specification). It should be noted that in the event of any inconsistency or conflict between the descriptions, definitions, and / or terminology used in the supplementary materials to this specification and the content of this specification, the descriptions, definitions, and / or terminology used in this specification shall prevail.
[0181] Finally, it should be understood that the embodiments described in this specification are merely illustrative of the principles of the embodiments described herein. Other variations may also fall within the scope of this specification. Therefore, alternative configurations of the embodiments described herein are intended to be illustrative rather than limiting, and should be considered consistent with the teachings of this specification. Accordingly, the embodiments described herein are not limited to those explicitly introduced and described herein.
Claims
1. An intelligent method for managing disease symptoms, characterized in that, The method includes: In response to the detection that the target patient meets the view display conditions, Obtain patient information of the target patient, including the target disease, target disease course, and examination information; Based on the target disease and the target disease course, a patient view template is determined; and Based on the patient view template and the examination information, a target patient view for the target patient is generated and displayed via a first terminal.
2. The method as described in claim 1, characterized in that, The process of determining the patient view template based on the target disease and the target disease course includes: In the view template library, target standard view templates corresponding to the target disease and the target disease course are determined as the patient view templates. The view template library includes standard view templates corresponding to patients with different diseases and different disease courses in the target department where the target patient is located. The standard view templates are obtained by learning from the first behavioral data of experts in the target department.
3. The method as described in claim 2, characterized in that, The first behavioral data includes data related to interface interaction behavior and doctor-patient communication behavior.
4. The method as described in claim 2, characterized in that, The step of determining the target standard view template corresponding to the target disease and the target disease course as the patient view template includes: Based on the account information logged in on the first terminal, determine whether the target doctor using the first terminal has a personalized view template set for the target disease and the target disease course; and In response to determining that the personalized view template exists, the personalized view template is used as the patient view template; or in response to determining that the personalized view template does not exist, the target standard view template is determined from the view template library as the patient view template.
5. The method as described in claim 4, characterized in that, The view template library includes multiple expert view templates corresponding to patients with different diseases and different disease stages in the target department. Each expert view template is obtained by learning from the expert behavior data of a single expert in the target department. The personalized view template is constructed by the target doctor based on any expert view template.
6. The method as described in claim 4, characterized in that, The method further includes: In response to the patient view template being the personalized view template, Obtain the interaction behavior data between the target doctor and the target patient view; Based on the target standard view template and the interaction behavior data, determine whether the target doctor has missed any core indicators; In response to the determination that the target doctor has missed a core indicator, a prompt is issued through the first terminal.
7. The method as described in claim 1, characterized in that, The examination information includes the index values of multiple indicators for the target patient, and the patient view template includes index weight information corresponding to multiple view areas. Generating a target patient view for the target patient based on the patient view template and the examination information includes: Based on the anomaly detection rules, determine the anomaly detection results of the indicator values of the multiple indicators; For each view region, based on the anomaly detection result and the corresponding indicator weight information of the view region, at least one first target indicator to be displayed in the view region is determined; and The target patient view is generated based on at least one first target indicator and its value corresponding to each view region.
8. The method as described in claim 7, characterized in that, The view area includes at least one of the following areas: The first area is configured to display summary information about the changes in the indicators; The second area is configured to display early warning indicators related to complications; The third area is configured to display core metrics; The fourth area is configured to display the metrics corresponding to the core metric categories.
9. The method as described in claim 7, characterized in that, Generating the target patient view based on at least one first target indicator and its value corresponding to each view region includes: The clinical early warning rules of the target department where the target patient is located are obtained. The clinical early warning rules include multiple early warning conditions and their corresponding response actions. The clinical early warning rules are obtained by learning the second behavioral data of the experts in the target department. The second behavioral data is related to the behavior of issuing medical orders. In response to determining that at least one second target indicator among the plurality of indicators satisfies the target warning condition among the plurality of warning conditions, the target patient view is generated based on at least one first target indicator and its indicator value, at least one second target indicator and its indicator value, and the target response action corresponding to the target warning condition for each view area.
10. The method as described in claim 1, characterized in that, The detection that the target patient meets the view display conditions includes: The first terminal displays a first information list of patients whose conditions need to be managed to the target doctor. The first information list includes information thumbnails of multiple patients whose conditions need to be managed. The information thumbnails include the status markers of the corresponding patients and at least one core indicator. In response to detecting that the target doctor selects a target information thumbnail of the target patient through the first terminal, it is determined that the target patient meets the view display conditions.
11. The method as described in claim 1, characterized in that, The detection that the target patient meets the view display conditions includes: The first unique identifier is received from the first terminal, and the first unique identifier is obtained by the first terminal through near-field interaction with a first identifiable marker set on the hospital bed; The patient corresponding to the bed is determined based on the first unique identifier, and the patient is identified as the target patient who meets the view display conditions.
12. The method as described in claim 11, characterized in that, The method further includes: The first terminal receives a second unique identifier, which is obtained by the first terminal through near-field interaction with a second identifiable marker set in the ward. A second information list of patients corresponding to the ward is determined based on the second unique identifier, and the second information list is displayed through the first terminal.
13. The method as described in claim 1, characterized in that, The method further includes: The second terminal of the target patient receives a third unique identifier, which is obtained by the second terminal through near-field interaction with a third identifiable mark set on the doctor's nameplate; In response to determining the target doctor corresponding to the doctor's nameplate based on the third unique identifier, relevant information about the target doctor is obtained and displayed through the second terminal.