Medical seeing method based on handheld medical insurance service terminal and related equipment

Abstract

The invention discloses a medical seeing method based on a handheld medical insurance service terminal and related equipment. The method comprises the following steps: acquiring historical doctor seeing data, health monitoring data and medical resource data of a patient through a medical cloud platform; determining a doctor-seeing demand of the patient based on the historical doctor-seeing data and the health monitoring data; based on the treatment demand, correlation analysis is conducted on the historical treatment data and the medical resource data, multiple treatment paths of the patient are generated, and each treatment path at least comprises personal information, a treatment institution, department information corresponding to the treatment institution, registration queuing information and examination items; and determining an optimal doctor-seeing path from the plurality of doctor-seeing paths, generating a doctor-seeing request according to the optimal doctor-seeing path, and sending the doctor-seeing request to a second mobile terminal of a doctor-seeing institution corresponding to the optimal doctor-seeing path. According to the invention, the treatment efficiency of the patient can be improved.

Description

Technical Field

[0001] The present application relates to the field of medical informationization, and specifically to a medical treatment method and related equipment based on a handheld medical insurance service terminal. Background Art

[0002] Currently, with the popularization of Internet technology and smart phones, more and more medical services are being provided with the help of mobile devices, aiming to improve the efficiency of medical services, reduce patient waiting time, and optimize the allocation of medical resources.

[0003] In related technologies, existing handheld medical insurance service platforms can basically meet functions such as online registration and payment, which are usually achieved through APPs built by medical institutions themselves or third-party health service platforms, which to a certain extent optimizes the patient's medical experience.

[0004] However, during the medical treatment process, users can usually only rely on personal experience or one-sided information to choose hospitals and departments. Choosing corresponding medical services through the medical institution’s self-built APP or third-party health service platform may result in the patient’s selected medical institution not fully matching their actual needs, further affecting the uneven distribution of medical resources and reducing the patient’s medical efficiency. Summary of the invention

[0005] The present application provides a medical treatment method and related equipment based on a handheld medical insurance service terminal, which are used to improve the patient's medical treatment efficiency.

[0006] In a first aspect of the present application, a medical treatment method based on a handheld medical insurance service terminal is provided, which is applied to a first mobile terminal, which is a patient end. The method includes: obtaining the patient's historical medical treatment data, health monitoring data and medical resource data through a medical cloud platform, the historical medical treatment data being the medical treatment data generated during the patient's medical service acceptance process at multiple target medical treatment institutions within a preset historical time period, and the target medical treatment institution being a medical service provider that has a medical service relationship with the patient within the preset time period; determining the patient's medical treatment needs based on the historical medical treatment data and health monitoring data; based on the medical treatment needs, performing correlation analysis on the historical medical treatment data and the medical resource data to generate multiple medical treatment paths for the patient, each medical treatment path including at least personal information, medical treatment institutions, department information corresponding to the medical treatment institutions, registration queue information and examination items; determining the optimal medical treatment path from multiple medical treatment paths, generating a medical treatment request based on the optimal medical treatment path, and sending the medical treatment request to a second mobile terminal of the medical treatment institution corresponding to the optimal medical treatment path.

[0007] Optionally, before obtaining the patient's historical medical data, health monitoring data, and medical resource data through the medical cloud platform, the method further includes: Define the access rules and data protocols for medical data through preset rules, and build a data access framework for medical data corresponding to all target medical institutions based on the access rules and data protocols. The medical data at least includes historical medical data, health monitoring data and medical resource data; formulate data flow rules and permission management mechanism for medical data based on the data access framework; build a medical cloud platform based on the access framework, data flow rules and permission management mechanism.

[0008] Optionally, determine the patient's medical needs based on historical medical data and health monitoring data, including: Extract disease characteristics from historical medical data; semantically associate disease characteristics with health monitoring data through a preset medical knowledge graph to generate a health profile of the patient; determine medical needs based on the health profile.

[0009] Optionally, before obtaining the patient's historical medical data, health monitoring data, and medical resource data, the method further includes: Obtain the patient's historical verification behavior data within a preset historical time period and current verification behavior data, the historical verification behavior data including historical verification time distribution, historical verification geographical location distribution and historical verification device information; establish a verification behavior model based on the historical verification behavior data; input the current verification behavior data into the verification behavior model to obtain the behavior matching degree; generate a verification instruction sequence based on the behavior matching degree; based on the verification instruction sequence, obtain the patient's dynamic behavior feature data; compare the dynamic behavior feature data with a preset feature template to obtain the feature similarity; when the behavior matching degree is greater than the preset matching degree threshold, and the feature similarity is greater than the preset similarity threshold, confirm that the patient's identity authentication has passed.

[0010] Optionally, after determining the optimal medical consultation path from multiple medical consultation paths, generating a medical consultation request according to the optimal medical consultation path, and sending the medical consultation request to the second mobile terminal of the medical consultation institution corresponding to the optimal medical consultation path, the method further includes: Receive a second medical consultation path sent by a second mobile terminal so that the patient can receive medical consultation according to the second medical consultation path, the second medical consultation path is based on the target medical consultation data and the patient's health monitoring data and is generated through a preset medical consultation model, the difference between the first medical consultation path and the second medical consultation path is greater than a preset threshold, and the target medical consultation data is the historical medical treatment data that the patient is authorized to access.

[0011] Optionally, before receiving the second medical consultation path sent by the second mobile terminal so that the patient can receive medical consultation according to the second medical consultation path, the method further includes: Obtain the patient's authorization information, and determine the scope of data that is allowed to be accessed based on the authorization information. The data scope includes at least the data type, access rights, and time range of the historical medical data; calculate the correlation between the historical medical data within the data range and the optimal medical path to obtain the correlation; determine the historical medical data with a correlation greater than a preset correlation value as the target medical data.

[0012] Optionally, after determining the optimal medical consultation path from multiple medical consultation paths, generating a medical consultation request according to the optimal medical consultation path, and sending the medical consultation request to the second mobile terminal of the medical consultation institution corresponding to the optimal medical consultation path, the method further includes: Receive the diagnosis result sent by the second mobile terminal, the diagnosis result is generated based on the target virtual human body model corresponding to the patient in the virtual medical scene, the virtual medical scene is obtained through the medical institution information, the target virtual human body model is marked according to the disease characteristic words, and the disease characteristic words are semantically analyzed by semantic analysis technology on the patient's voice data and extracted according to preset rules.

[0013] In a second aspect of the present application, a medical treatment system based on a handheld medical insurance service terminal is provided, comprising: The acquisition module is used to obtain the patient's historical medical data, health monitoring data and medical resource data through the medical cloud platform. The historical medical data refers to the medical data generated during the patient's medical service reception at multiple target medical institutions within a preset historical time period. The target medical institution is the medical service provider that has a medical service relationship with the patient within the preset time period. The first determination module is used to determine the patient's medical needs based on historical medical data and health monitoring data; A generation module is used to perform correlation analysis on historical medical data and medical resource data based on medical needs, and generate multiple medical paths for patients, each of which includes at least personal information, medical institution, department information corresponding to the medical institution, registration queue information, and examination items; The sending module is used to determine the optimal medical treatment path from multiple medical treatment paths, generate a medical treatment request according to the optimal medical treatment path, and send the medical treatment request to the second mobile terminal of the medical treatment institution corresponding to the optimal medical treatment path.

[0014] In the third aspect of the present application, an electronic device is provided, including a processor, a memory, a user interface and a network interface, the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory so that the electronic device executes any one of the methods described above.

[0015] In a fourth aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores instructions, and when the instructions are executed, any of the methods described above is executed.

[0016] In summary, one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: 1. Obtain and integrate the patient's historical medical data, health monitoring data and medical resource data through the medical cloud platform, clarify the patient's actual medical needs based on data analysis, and analyze the correlation with medical resources to generate multiple candidate medical paths, select the best path and generate a medical request to directly connect with the medical institution. This solves the problem that patients cannot scientifically choose medical institutions and departments due to lack of personal experience or lack of comprehensive information, avoids low medical efficiency and waste of medical resources due to improper selection, and improves the efficiency of patients' medical treatment.

[0017] 2. By presetting access rules and data protocols, building a unified data access framework, and formulating data flow rules and authority management mechanisms, we solved the problems of heterogeneous data sources, inconsistent formats, low data sharing efficiency and insufficient security among different medical institutions, and achieved information exchange and efficient integration between various medical institutions and the medical cloud platform. We ensured that historical medical data, health monitoring data, medical resource data and other data can be accessed in a standardized manner and shared safely, effectively optimizing the collaborative efficiency and service quality of cross-institutional medical services.

[0018] 3. By receiving the second medical treatment path sent by the second mobile terminal of the target medical institution, and dynamically adjusting the medical treatment plan according to the patient's health monitoring data, target medical treatment data and the preset medical treatment model, the problem that the original optimal path is no longer applicable due to changes in the patient's health status or real-time medical resource status updates is solved. This method ensures that the patient's medical treatment plan is adjusted in time when the difference exceeds the preset threshold by judging the difference between the optimal medical treatment path and the second medical treatment path, so that the medical treatment path can more accurately match the patient's real-time needs and the resource status of the medical institution. This dynamic optimization mechanism improves the patient's medical treatment efficiency and treatment effect, avoids resource waste and medical delays caused by changes in health status or medical resources, and strengthens information exchange and collaboration between patients and medical institutions.

[0019] 4. By generating diagnostic results based on the target virtual human model in the virtual medical scene, the problem of low efficiency and incomplete diagnostic information caused by reliance on face-to-face consultations in the traditional medical process is solved. The semantic analysis technology is used to extract disease feature words from the patient's voice data, and the virtual human model is marked in combination with preset rules. The virtual medical scene is constructed based on the medical institution information, realizing the intelligent analysis of the patient's symptom information and the preliminary generation of diagnosis. This method not only improves the real-time and accuracy of diagnosis, but also optimizes the interaction between patients and medical institutions, provides accurate reference for subsequent actual medical treatment, and improves the efficiency of diagnosis and treatment. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a flowchart of a medical treatment method based on a handheld medical insurance service terminal in an embodiment of the present application; Figure 2 It is a structural schematic diagram of a medical treatment system based on a handheld medical insurance service terminal in an embodiment of the present application; Figure 3 It is a schematic diagram of the structure of an electronic device in an embodiment of the present application.

[0021] Explanation of the accompanying drawings: 201, acquisition module; 202, first determination module; 203, generation module; 204, sending module; 205, construction module; 206, verification module; 207, receiving module; 208, second determination module; 209, medical consultation module; 301, processor; 302, communication bus; 303, user interface; 304, network interface; 305, memory. DETAILED DESCRIPTION

[0022] In order to enable technicians in this field to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments.

[0023] In the description of the embodiments of the present application, words such as "for example" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "for example" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "for example" or "for example" is intended to present related concepts in a specific way.

[0024] In the description of the embodiments of the present application, the meaning of the term "multiple" refers to two or more. For example, multiple systems refer to two or more systems, and multiple screen terminals refer to two or more screen terminals. In addition, the terms "first" and "second" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Thus, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. The terms "include", "comprise", "have" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0025] Figure 1 It is a flow chart of a medical treatment method based on a handheld medical insurance service terminal in an embodiment of the present application.

[0026] See also Figure 1 In an embodiment of the present application, a medical treatment method based on a handheld medical insurance service terminal is applied to a first mobile terminal, and the method includes: S101. Obtain the patient's historical medical data, health monitoring data, and medical resource data through the medical cloud platform. The historical medical data refers to the medical data generated during the patient's medical service receipt at multiple target medical institutions within a preset historical time period. The target medical institution refers to the medical service provider that has a medical service relationship with the patient within the preset time period. Before step S101, a medical cloud platform is first constructed. Specifically, access rules and data protocols for medical data are defined through preset rules, and a data access framework for medical data corresponding to all target medical institutions is constructed based on the access rules and data protocols. The medical data includes at least historical medical data, health monitoring data, and medical resource data; data flow rules and authority management mechanisms for medical data are formulated based on the data access framework; and a medical cloud platform is constructed based on the access framework, data flow rules, and authority management mechanisms.

[0027] Among them, in order to ensure that medical data can be effectively accessed and shared, it is first necessary to clarify the specific specifications of data access through preset rules, and formulate rules for data sources, data formats, and field standardization. For example, it is clear that historical medical data comes from the HIS (hospital information system) or EMR (electronic medical record system) of each medical institution, health monitoring data comes from smart devices (such as smart bracelets or blood pressure monitors), and medical resource data is provided by the hospital's scheduling system or registration system. At the same time, in order to ensure data consistency, it is necessary to unify the field names and formats, for example, the patient ID fields provided by all hospitals are uniformly named patient_id, and the time fields are unified in the ISO 8601 standard format (such as 2025-01-22T10:00:00Z). On this basis, formulate data communication protocols (such as using RESTful API and HTTPS encrypted transmission) and data exchange protocols (such as using international medical data standards HL7 or FHIR) to standardize the interaction of data between different systems. In addition, to protect patient privacy, regulations require that sensitive information (such as name and ID number) be desensitized. For example, the name "Zhang San" is stored as "Z***", and only the first 6 digits of the ID number are retained. These rules and protocols together build the basic framework for data access.

[0028] Based on access rules and data protocols, a data access framework is constructed to achieve standardized access to multi-source medical data. The framework includes data collection, transmission, storage and cleaning modules. The data collection module uses the API interface to access the historical medical data of different medical institutions, the data uploaded by health monitoring devices, and the medical resource information of the hospital in real time. For example, the registration data is collected through the API interface of the HIS system, or the health monitoring data such as heart rate and blood pressure are collected through the cloud interface of the smart bracelet manufacturer. The data transmission module uses message queues (such as Kafka or RabbitMQ) to achieve high-concurrency real-time data transmission, and supports breakpoint resumption function to prevent data loss due to network interruption. For the storage module, a distributed database (such as MySQL or PostgreSQL) is used to store structured data, such as patient medical records; for unstructured data (such as image files or surgical records), Hadoop HDFS or Elasticsearch is used for storage. Finally, the data cleaning module processes the collected data, removes duplicate records, corrects erroneous data, and standardizes the field format. For example, the field "diagnosis results" returned by different hospitals is unified as diagnosis, thereby ensuring the integrity and consistency of the data.

[0029] On the basis of the data access framework, data flow rules and permission management mechanisms need to be formulated to ensure efficient data flow and safe use. Data flow rules define the complete path from data collection to sharing. For example, after the patient's health monitoring data is uploaded from the smart device to the medical cloud platform, it is pushed to the second mobile terminal of the relevant medical institution after cleaning and analysis for real-time diagnosis. In addition, data flow can be based on different trigger conditions, such as daily synchronization of health monitoring data through scheduled tasks, or automatic push of registration information to the second mobile terminal of the department or doctor when the patient makes an appointment. In addition, in order to ensure the security of data flow, full encryption transmission (such as using SSL / TLS protocol) is stipulated to prevent data from being tampered with or leaked during transmission. The permission management mechanism clarifies the scope of permissions of different user roles through hierarchical permission management and fine-grained access control. For example, patients can access their own diagnosis and treatment data, doctors can only access patient data authorized by patients and related to the doctor's diagnosis and treatment, and system administrators can view and manage all data.

[0030] Relying on the data access framework, data flow rules and authority management mechanism, the medical cloud platform is constructed. The technical architecture of the medical cloud platform is divided into four levels: front-end layer, service layer, data layer and security layer. The front-end layer provides a friendly user interface for patients and doctors. For example, patients can view their medical records, health monitoring data and registration status through the first mobile terminal (such as mobile phones, tablets, etc.), and doctors can query patients' medical records and the latest health monitoring information through the second mobile terminal. The service layer provides a unified API interface to support front-end function calls and third-party system integration. The data layer uses a distributed storage system (such as MySQL or Elasticsearch) to uniformly store patients' historical medical data, health monitoring data and medical resource data, and uses cache technology (such as Redis) to improve data query efficiency. The security layer ensures the security of data during storage and transmission through data encryption, intrusion detection, firewall technology and privacy protection mechanism. Through the medical cloud platform, patients' historical diagnosis and treatment data can be integrated and shared, for example, multiple medical records of patients in different hospitals can be merged into a complete medical record, which is convenient for doctors to view and analyze.

[0031] In step 101S, through the constructed medical cloud platform, the system can obtain the patient's historical medical data, health monitoring data and medical resource data, where the historical medical data refers to the medical records generated by the patient in the process of receiving medical services in multiple target medical institutions within a preset historical time period, including but not limited to the patient's diagnosis results, test reports, prescription records and surgical information. The target medical institution refers to the medical service provider that has a medical service relationship with the patient within the preset time period, such as the hospital, clinic or other medical institution where the patient has been treated. At the same time, health monitoring data is physical health indicator data collected in real time by the patient's smart device (such as wearable device) or health management system, such as heart rate, blood pressure, body temperature, blood sugar and other information; medical resource data includes information such as department information of each medical institution, doctor scheduling, registration queue and resource status of related examination items, so as to provide comprehensive and accurate data support for subsequent medical demand analysis and medical path planning.

[0032] S102, determining the patient's medical needs based on historical medical data and health monitoring data; Specifically, disease characteristics are extracted from historical medical data; through the preset medical knowledge graph, disease characteristics are semantically associated with health monitoring data to generate a health portrait of the patient; and medical needs are determined based on the health portrait.

[0033] First, the disease-related characteristic information is extracted from the patient's historical medical data generated in multiple target medical institutions. These disease characteristics can include the patient's previous diagnosis results, disease classification (such as ICD-10 code), abnormal values ​​of test indicators, imaging results (such as CT, MRI reports), and patient medication records. For example, a patient's historical medical records may contain information such as "diabetes (E11)", "fasting blood sugar value 9.0mmol / L (higher than the normal range)", and "HbA1c value 7.5%", which together reflect the patient's diabetes characteristics.

[0034] After extracting disease features, the preset medical knowledge graph is used to semantically associate disease features with the patient's health monitoring data. The medical knowledge graph is a semantic network built based on large-scale medical field data and knowledge, which contains the association between diseases and symptoms, test indicators, and health monitoring data. For example, the medical knowledge graph may contain the following rules: "Diabetes" is closely related to "elevated fasting blood sugar".

[0035] "Dizziness" is related to "hypoglycemia" or "hypertension".

[0036] "Abnormal blood sugar levels" and "large fluctuations in heart rate" in health monitoring data may indicate the risk of complications from diabetes. In specific applications, the system can semantically match and analyze the patient's disease characteristics (such as diabetes) with health monitoring data (such as blood sugar levels exceeding 11mmol / L for three consecutive days) to identify potential risks or complications. For example, through semantic association, the system finds that the patient's "abnormally high blood sugar levels" and "large fluctuations in heart rate in the past two days" may indicate the risk of diabetes combined with cardiovascular problems.

[0037] Through semantic correlation analysis of disease characteristics and health monitoring data, a health profile of the patient is further generated. A health profile is a comprehensive digital description of the patient's health status, including the patient's disease information, health monitoring indicator trends, and potential health risks. For example, a health profile of a diabetic patient may include the following: Disease information: Diabetes mellitus (E11), accompanied by hypertension (I10).

[0038] Health monitoring data trends: blood sugar levels have been abnormally high for a week (average fasting blood sugar level 10mmol / L), and blood pressure fluctuates greatly (systolic blood pressure range 135-160mmHg).

[0039] Risk assessment: There may be early signs of diabetic retinopathy (based on the association between diabetes and retinopathy) and a high risk of cardiovascular disease.

[0040] Health portraits can vividly present the patient's health status and help medical service providers quickly understand the patient's health status and potential needs.

[0041] Based on the generated health profile, the system further analyzes the patient's health status and potential risks to clarify the patient's current medical needs. Medical needs may include recommended departments, priorities, and required examinations or treatments. For example: For a diabetic patient, if the health profile shows that his blood sugar level continues to rise and is accompanied by abnormal heart rate fluctuations, the system may determine that he needs to go to the endocrinology department as soon as possible for further blood sugar control evaluation, and recommend that he register with the cardiology department to check cardiovascular risk. If the health profile indicates that the patient may have early signs of diabetic retinopathy, the patient is recommended to go to the ophthalmology department for a fundus examination.

[0042] S103. Based on the medical treatment needs, historical medical treatment data and medical resource data are correlated and analyzed to generate multiple medical treatment paths for the patient, each of which includes at least personal information, medical institution, department information corresponding to the medical institution, registration queue information, and examination items; The system first extracts elements that match the medical resource data from the patient's historical medical data. These elements can include the patient's historical medical institution preferences, historical examination and treatment records, disease characteristics, and medical time habits. Historical medical institution preferences reflect the patient's trust in certain medical institutions or doctors, such as whether the patient has chosen certain hospital departments for medical treatment many times. Historical examination and treatment records can avoid repeated arrangements for examinations, such as whether the patient has recently completed an HbA1c test or an electrocardiogram, and whether the results are still valid. In addition, the system will also extract disease characteristics and potential risks in combination with the patient's health profile, and these data are used to clarify the patient's department needs. For example, the system can extract the patient's diabetes diagnosis record (E11) and related treatment data, and combine the cardiovascular risk shown in the health profile to clarify that the patient's needs are for joint diagnosis and treatment of "endocrinology" and "cardiology". The system will also analyze the patient's preferences for medical time, such as whether the patient prefers to visit on weekend mornings, which can help recommend a more appropriate time arrangement.

[0043] Next, the system extracts real-time dynamic information related to patient needs from the medical resource data, including the department settings of medical institutions, registration queue information, availability of examination items, and geographical location. Medical resource data is updated in real time and can reflect the current service capabilities of each target institution. For example, the system can extract the doctor scheduling information, registration queue number, and estimated waiting time of the endocrinology and cardiology departments of Hospital A and Hospital B. If the current queue number of the endocrinology department of Hospital A is 5, the estimated waiting time is 45 minutes, and the queue number of Hospital B is 10 and the waiting time is 1 hour, the system can prioritize them accordingly. In addition, the system will also analyze whether the examination items required by the patient (such as blood sugar monitoring, electrocardiogram) can be completed on the same day, and whether the examination equipment is available. For example, if the blood sugar monitoring project of Hospital A is available on the same day, and Hospital B needs to be arranged until the next day, the system will give priority to Hospital A.

[0044] After extracting the patient's historical data and medical resource data, the system uses a semantic association analysis algorithm to perform multi-dimensional matching between the two to generate a recommended treatment path that meets the patient's needs. The system first screens medical institutions that have the departments required by the patient based on the treatment needs clearly stated in the patient's health portrait. For example, if the patient needs an endocrinology department for diabetes management and a cardiology department for cardiovascular risk examination, the system will prioritize medical institutions that have both departments. If the patient's historical treatment data shows that he has chosen the endocrinology department of Hospital A for treatment many times, the system will prioritize Hospital A. Further analysis is performed to determine whether the examination items required by the patient (such as blood sugar monitoring, electrocardiogram examination) can be efficiently completed in the recommended institution. For example, if blood sugar monitoring at Hospital A can be arranged on the same day, while Hospital B needs to wait until the next day, the system will prioritize Hospital A. In addition, the system will check whether the patient has recently completed relevant examinations. For example, if the patient has recently completed an HbA1c test at Hospital B and the result is still valid, the system will avoid arranging the examination repeatedly, thereby saving time and resources.

[0045] The system recommends the institution with the shortest waiting time and the most matching doctor's professional field by analyzing the registration queue information and doctor resources. For example, if Dr. Zhang, an endocrinologist at Hospital A, specializes in diabetes treatment and the registration queue time is 45 minutes, while the doctor at Hospital B is better at metabolic syndrome treatment and the queue time is 1 hour, the system will give priority to recommending Hospital A. In addition, the system will also evaluate the doctor's free time and match it with the patient's time preference. For example, if a patient prefers to see a doctor on weekend mornings, and the endocrinologist at Hospital A sees patients on weekend mornings, this doctor will be recommended first. Through the above multi-dimensional matching, the system can achieve accurate docking of patient needs and medical resources, and generate multiple treatment paths that meet patient needs.

[0046] After completing the semantic association analysis, the system combines patient needs and medical resource data to generate multiple treatment paths. Each treatment path includes at least the following: Patient personal information: including patient ID, medical history summary, health portrait summary, etc., to help doctors quickly understand the patient's background.

[0047] Recommended medical institution: The specific name of the target hospital or clinic.

[0048] Corresponding department information: recommended department name and doctor’s professional field (e.g. Dr. Zhang from the Endocrinology Department, who specializes in diabetes treatment).

[0049] Registration queue information: the number of registered patients in the recommended department, the estimated waiting time and the doctor's free time.

[0050] Examination item arrangement: the specific time arrangement of the examinations required by the patient and whether they can be completed in the same visit.

[0051] When generating a medical treatment path, the system will sort the comprehensive scores of each target medical institution and provide patients with multiple medical treatment paths with high priority. For example, Medical Treatment Path 1 will give priority to recommending Hospital A, which is closer, has a shorter waiting time for registration, and can be completed on the same day, while Medical Treatment Path 2 will recommend Hospital B, which is slightly farther away but has a faster arrangement for examinations. The detailed information of each medical treatment path will be presented to the patient for selection.

[0052] S104, determining an optimal medical consultation path from multiple medical consultation paths, generating a medical consultation request according to the optimal medical consultation path, and sending the medical consultation request to a second mobile terminal of a medical consultation institution corresponding to the optimal medical consultation path; In step S104, the system needs to determine the optimal medical treatment path from the multiple medical treatment paths generated in the aforementioned step S103, and generate a medical treatment request based on the medical treatment path, and then send the request to the second mobile terminal of the corresponding medical institution (such as the terminal system of the hospital or the front-end device of the doctor's department).

[0053] First, the system calculates the time cost based on medical resource data. The time cost includes the registration queue time and the examination arrangement time. For example, if the waiting time for the endocrinology department of Hospital A recommended by Treatment Path 1 is 45 minutes, and the cardiology examination requires a waiting time of 1 hour, while the waiting time for Hospital B recommended by Treatment Path 2 is 30 minutes but the examination needs to be arranged the next day, then the treatment path 1 with lower time cost will be better. Secondly, calculate the matching degree of medical resources, that is, the fit between the patient's needs and the departments and doctors recommended in the treatment path. For example, if the patient's health portrait shows that he has diabetes, Dr. Zhang, an endocrinologist at Hospital A, focuses on diabetes treatment, while doctors at Hospital B are better at metabolic syndrome management, then the matching degree of Treatment Path 1 is higher. In addition, the patient's historical preferences will be referred to, such as whether the patient has chosen Hospital A many times or is highly satisfied with its services, which can be used as a weighted factor for the treatment path score. Finally, the system can use a multi-indicator weighted scoring algorithm to comprehensively calculate factors such as time cost, resource matching, and historical preferences. The treatment path with the highest score is the optimal treatment path. For example, in the above-mentioned comparison of medical treatment pathways, if the comprehensive score of medical treatment pathway 1 is 85 points and that of medical treatment pathway 2 is 70 points, medical treatment pathway 1 is determined to be the optimal medical treatment pathway.

[0054] After determining the optimal treatment path, the system will generate a detailed treatment request based on the optimal treatment path to notify the target treatment institution to reserve medical resources for the patient. The content of the treatment request includes patient information, department and doctor information, examination arrangements and other relevant data.

[0055] The system includes the patient's basic information in the request, including name, gender, contact information, and health profile summary. For example, the patient's health profile may show that he or she has diabetes (E11) and hypertension (I10), requiring joint diagnosis and treatment by the endocrinology and cardiology departments. The system extracts this key information to ensure that doctors at medical institutions can quickly understand the patient's background. Secondly, the consultation request will include the recommended department and doctor information. For example, the system will clearly mark "Recommend Dr. Zhang from the Endocrinology Department of Hospital A (focusing on diabetes management), and the registration waiting time is expected to be 45 minutes." If the consultation path involves multiple departments (such as endocrinology and cardiology), the system will generate separate scheduling information for each department and record it uniformly in the request.

[0056] In addition, the medical request will also include the specific arrangements for the examination items. For example, the system will indicate in the request that "the blood sugar monitoring time is 10:30 and completed on the same day; the electrocardiogram time is 11:15". These arrangements are based on the dynamic analysis results of the medical resources in S103 above to ensure that the patient's examination items can be completed efficiently. Finally, the medical request will also generate a registration appointment number or a queue number to ensure that the patient can successfully complete the registration and subsequent examinations after arriving at the hospital.

[0057] When generating a medical request, the system will format all information about the optimal path into a data format recognizable by the target medical institution (such as JSON, XML, or HL7 standard) for subsequent transmission and processing.

[0058] After the medical consultation request is generated, the system needs to send it to the second mobile terminal of the medical institution corresponding to the optimal medical consultation path. This terminal may be the registration system in the hospital, the management terminal of the doctor's department, the scheduling equipment of the examination center, etc. The sending process includes the determination of the target terminal, information transmission and feedback confirmation.

[0059] The system locates the corresponding second mobile terminal based on the target institution and department information in the optimal treatment path. For example, if the optimal treatment path recommends the Endocrinology Department and Cardiology Department of Hospital A, the system will send the request to the registration terminal and examination scheduling terminal of the Endocrinology Department and Cardiology Department of Hospital A respectively. Secondly, the system pushes the request to the corresponding terminal by connecting to the interface of the target institution's IT system. The transmission method can be to directly connect to the hospital information system (HIS) or to send data to the mobile terminal through a message push protocol (such as MQTT, HTTP). For example, the registration request will directly enter the hospital registration system, and the examination arrangement will be synchronized to the scheduling system of the examination center.

[0060] After the request is sent, the target terminal will return feedback information to indicate whether the request is successfully processed. For example, the registration system may return "registration successful, appointment number is 12345", and the examination center may return "blood sugar monitoring time has been confirmed, scheduled for 10:30". The system will receive these feedback information in real time and synchronize it to the patient side (first mobile terminal) to ensure that the patient knows his or her appointment arrangement. After completing the sending of the appointment request, the system will synchronize the confirmation result to the patient side and prompt the patient to complete the appointment preparation. For example, the system will push a notification to the patient's mobile terminal, including the final confirmation information of the recommended appointment path, such as "endocrinology department registration successful, appointment number is 12345, please arrive at Hospital A at 9:30". If an examination item is involved, the specific time and place of the examination will also be indicated in the notification. At the same time, the system will provide reminders for preparation for the appointment, such as carrying relevant examination reports or fasting in advance. For example, "blood sugar monitoring requires fasting, please make sure not to eat within 8 hours before the examination."

[0061] In one possible scenario, assuming that a patient requires joint diagnosis and treatment by the endocrinology department and the cardiology department, two treatment paths are generated in S103: Treatment Path 1: We recommend Hospital A, Dr. Zhang, an endocrinologist (focusing on diabetes management). The waiting time for registration is 45 minutes, and the cardiology examination requires a waiting time of 1 hour, but blood sugar monitoring and electrocardiogram can be completed on the same day.

[0062] Treatment route 2: Recommended is Hospital B, Dr. Li, an endocrinologist. The registration waiting time is 30 minutes, but the electrocardiogram examination needs to be arranged until the next day, and the hospital is far away.

[0063] Through scoring, the system determines that treatment path 1 is the optimal treatment path. The system generates a treatment request, which includes the patient's basic information (name, health portrait summary, etc.), recommended departments and doctors, examination arrangements (blood sugar monitoring time is 10:30, electrocardiogram time is 11:15) and registration appointment number. Subsequently, the system sends the request to the registration system of the Endocrinology Department and the Cardiology Department of Hospital A, and the dispatch terminal of the examination center, and receives confirmation information. Finally, the system synchronizes the confirmation information to the patient, prompting the patient to go to Hospital A on time to complete the relevant diagnosis and treatment.

[0064] S105, receiving a second medical consultation path sent by a second mobile terminal, so that the patient can receive medical consultation according to the second medical consultation path, the second medical consultation path is generated based on the target medical consultation data and the patient's health monitoring data and through a preset medical consultation model, the difference between the first medical consultation path and the second medical consultation path is greater than a preset threshold, and the target medical consultation data is the historical medical consultation data authorized by the patient to access; Before step S105, the target medical data that the patient is authorized to access in the historical medical data must be determined. Specifically, the patient's authorization information is obtained, and the data range that is allowed to be accessed is determined based on the authorization information. The data range includes at least the data type, access rights, and time range of the historical medical data; the historical medical data within the data range and the optimal medical path are correlated to obtain the correlation; the historical medical data with a correlation greater than a preset correlation value is determined as the target medical data.

[0065] The system obtains authorization information to clarify the scope of historical medical data that the patient is allowed to share. Authorization information includes data types (such as medical records, examination reports, imaging data, etc.), access rights (such as read-only or modifiable), and time ranges (such as data from the past year or two). For example, when a patient authorizes access to his or her diabetes-related medical records and examination data from the past two years, the system will filter out diabetes-related medical records, laboratory reports, and related imaging data based on this authorization information, and ensure that access rights are limited to read-only operations in the current diagnosis and treatment task.

[0066] After obtaining the authorization information, define the scope of historical data that can be accessed based on the authorization content, and perform a preliminary screening of the data. The definition of the data scope includes three key elements: data type, access rights, and time range. For example, if the patient only authorizes access to medical records and laboratory reports, other types of data (such as imaging data or expense records) will be excluded; if the patient authorizes access to data within the past year, the system will automatically remove historical records that exceed the time range.

[0067] According to the determined data range, the system selects qualified records from the patient's historical medical data. Historical medical data may include medical records, examination and test reports, medication records, and medical records. For example, if the patient authorizes access to the diagnosis and treatment records and examination data of the endocrinology and cardiology departments, the system will extract the medical records of the endocrinology department, diabetes-related examination reports, and electrocardiogram examination data of the cardiology department from the patient's historical data, while records of other departments (such as dermatology or gastroenterology) will be excluded.

[0068] After screening out the historical data that meets the authorization conditions, the degree of match between these data and the optimal treatment path is further identified through correlation algorithms (such as cosine similarity, Pearson correlation coefficient, mutual information algorithm or feature matching algorithm based on deep learning). The correlation calculation is based on multiple dimensions, including department matching, disease feature matching and examination item matching. For example, if the optimal treatment path recommends diabetes management in the endocrinology department and cardiovascular examination in the cardiology department, the system will give priority to calculating the matching degree of the relevant historical data of these departments; if a medical record shows that the patient has recently been diagnosed with diabetic complications and the time is within the last three months, its correlation score is high; while a record about the common cold has a low correlation. The specific calculation process is explained by taking the feature analysis model as an example. First, the system extracts the key features of the historical data and the optimal path, including department information, disease characteristics, examination items, diagnosis and treatment time, etc., and converts them into structured feature vectors. Then, based on these feature vectors, the system uses a weighted similarity algorithm (such as cosine similarity or Euclidean distance) to calculate the matching degree between the two. For example, if the department in the historical data is consistent with the recommended department in the optimal path, the disease characteristics are highly consistent (such as the record of diabetes complications matches the diabetes diagnosis in the current health portrait), and the diagnosis and treatment time is close, the relevance score will be higher; conversely, if the department or disease characteristics do not match, the score will be lower. Finally, the system compares the calculated relevance score with the preset threshold and only retains historical data with a relevance score greater than the threshold as the target medical data. For example, if the relevance threshold is set to 0.75, the system will retain data with a relevance score greater than 0.75, including endocrinology medical records, diabetes-related test results, and cardiology electrocardiogram reports, while other data with lower relevance (such as diagnosis and treatment records for the common cold) will be excluded.

[0069] In step S105, after confirming the optimal treatment path, the first mobile terminal (the patient's device) sends a treatment request to the second mobile terminal (the terminal system of the medical institution) through the system. The request content includes the patient's basic information (such as name, ID number, contact information), health monitoring data (such as real-time blood sugar value, heart rate, etc.), target treatment data (such as historical medical records, examination reports) and detailed information on the optimal treatment path (recommended medical institutions, departments, doctors and examination arrangements). This interaction ensures that the second mobile terminal can receive the patient's complete health background and optimal path information.

[0070] After receiving the medical consultation request, the second mobile terminal generates a second medical consultation path through a preset medical consultation model based on the patient's target medical consultation data, health monitoring data, and the real-time resource situation of the medical institution. The preset medical consultation model is an intelligent algorithm that comprehensively analyzes the patient's medical treatment needs, current health status, the medical institution's resource situation (such as doctor scheduling, equipment availability), time priority, and historical medical records, examination reports and other information in the target medical consultation data. For example, when the patient's real-time health monitoring data shows abnormally high blood sugar or unstable heart rate, the preset medical consultation model may give priority to emergency examinations in the cardiology department and dynamically adjust other original medical arrangements. Finally, the second mobile terminal generates a second medical consultation path, which is an optimized solution based on the patient's current health status and medical needs.

[0071] After generating the second medical treatment path, the second mobile terminal will compare the specific content of the optimal medical treatment path with the second medical treatment path, and calculate the difference between the two medical treatment paths. The calculation of the difference is based on preset measurement indicators, including at least: changes in medical institutions or departments, such as adjustment from Hospital A to Hospital B, or adjustment from Endocrinology Department to Cardiology Department; increase or decrease or order adjustment of examination items, such as adding an electrocardiogram, or advancing the time of blood glucose monitoring; changes in schedule, such as the adjustment range of registration time and examination time. By calculating these indicators, the system generates a difference score. For example, if the second medical treatment path adds an emergency examination item and adjusts the medical institution and schedule at the same time, the difference value may be high; if it is only a slight adjustment in time, the difference value will be low. The system compares the difference value with the preset difference threshold.

[0072] The second mobile terminal compares the calculated difference with the preset threshold. If the difference is greater than the preset threshold, it means that there is a significant difference between the optimal treatment path and the second treatment path. The optimization and adjustment of the second treatment path is of great significance to the patient's diagnosis and treatment needs. The system needs to send the second treatment path to the first mobile terminal. If the difference does not exceed the preset threshold, it is considered that the optimal treatment path is still suitable for the current diagnosis and treatment situation. The system will not send the second treatment path, but continue to arrange the patient's treatment according to the optimal treatment path.

[0073] When the difference is greater than the preset threshold, the second mobile terminal will send the details of the second medical treatment path to the first mobile terminal (patient device). The content sent includes the optimized medical treatment arrangement, such as the recommended medical institution, department, doctor, registration information, examination items and specific time, and the main differences from the optimal medical treatment path will be marked. For example, the system may prompt the patient: "Because your real-time health monitoring data shows an abnormally high blood sugar level, the adjusted path has added an emergency examination in the cardiology department. The registration time is 10:00 am, and the original examination time is postponed to 1:00 pm." Through this detailed path information and difference description, patients can clearly understand the adjustments and reasons for the new path.

[0074] After receiving the second medical treatment path, the first mobile terminal will show the patient detailed information about the optimized path, and compare it with the original path (optimal medical treatment path), highlighting the differences between the two. For example, the interface may display "The new path adds cardiology examinations and adjusts the examination time" so that patients can quickly understand the reasons and necessity for the path change. The patient can confirm the second medical treatment path on the first mobile terminal, and after confirmation, the system will prompt the patient to follow the new path (second medical treatment path) for medical treatment. If the patient has any questions about the path adjustment, he or she can also interact with the second mobile terminal through the first mobile terminal for feedback (such as contacting a doctor or consulting a medical institution) to further adjust the medical treatment path or confirm the diagnosis and treatment arrangements.

[0075] When the patient confirms the second medical treatment path through the first mobile terminal, the system will synchronize the confirmation status to the second mobile terminal to ensure that the resource adjustment of the medical institution can take effect in time. For example, the second mobile terminal will rearrange the registration order for the patient, reserve the examination time, and notify the relevant doctors or departments to prepare according to the confirmed path. At the same time, the second mobile terminal will synchronize the confirmed resource arrangement (such as appointment number, examination time, etc.) back to the first mobile terminal so that the patient can obtain the latest medical information in real time. This two-way synchronous interaction mechanism ensures the accuracy of the execution of path optimization.

[0076] After confirming the second medical treatment route, the patient goes to the target medical institution for treatment through the first mobile terminal according to the arrangement of the route. The first mobile terminal will provide real-time reminders to the patient, such as "Please arrive at the registration office of the Department of Cardiology of Hospital A at 10:00 am" or "Your blood sugar monitoring appointment time is 2:00 pm, please arrive at the examination room 10 minutes in advance." At the same time, the second mobile terminal will dynamically update the resource status of the medical institution, such as the use of the inspection equipment or the doctor's diagnosis and treatment arrangements, to ensure that the patient's medical treatment process is smooth and efficient.

[0077] In one possible scenario, suppose that the optimal treatment path for a patient recommends Dr. Zhang, an endocrinologist at Hospital A, with a registration time of 10:30 a.m., and blood glucose monitoring and electrocardiogram examinations are arranged. However, when generating the second treatment path, the second mobile terminal found that the patient's health monitoring data (such as real-time blood glucose value and heart rate) showed that he had cardiovascular risks, so the path was adjusted: priority was given to an emergency examination in the Department of Cardiology of Hospital A at 10:00 a.m., and the blood glucose monitoring time was postponed to the afternoon. By comparing the two paths, the system calculated that the difference value was greater than the preset threshold (for example, 0.8), so the second treatment path was sent to the first mobile terminal. After the patient confirms the path on the first mobile terminal, the system synchronously updates the resource arrangement of the medical institution, and finally the patient completes the optimized treatment process according to the second treatment path.

[0078] Optional, in Figure 1 The following steps may be performed before step S101 of the illustrated embodiment: Obtain the patient's historical verification behavior data within a preset historical time period and current verification behavior data, the historical verification behavior data including historical verification time distribution, historical verification geographical location distribution and historical verification device information; establish a verification behavior model based on the historical verification behavior data; input the current verification behavior data into the verification behavior model to obtain the behavior matching degree; generate a verification instruction sequence based on the behavior matching degree; based on the verification instruction sequence, obtain the patient's dynamic behavior feature data; compare the dynamic behavior feature data with a preset feature template to obtain the feature similarity; when the behavior matching degree is greater than the preset matching degree threshold, and the feature similarity is greater than the preset similarity threshold, confirm that the patient's identity authentication has passed.

[0079] The system first obtains the patient's historical verification behavior data within a preset historical time period and the patient's current verification behavior data from the medical cloud platform or related database. The historical verification behavior data includes the patient's verification time distribution when using the system in the past (for example, patients usually verify more frequently between 9 and 11 a.m.), geographic location distribution (for example, patients mainly verify in a certain city or near a hospital), and verification device information (such as the patient's commonly used mobile phone model or operating system). The current verification behavior data is the real-time data submitted by the patient during this verification, including the time, geographic location, and device information used for this verification.

[0080] After obtaining historical verification behavior data, the system can use machine learning algorithms or statistical analysis methods to establish a verification behavior model based on the patient's historical behavior characteristics. The model learns the patient's typical verification behavior characteristics by analyzing the regularity of historical verification behavior data (such as time distribution patterns, geographic location activity range, and device usage stability). For example, if a patient's verification behavior is usually concentrated in certain time periods (such as morning or afternoon), and the device is always a certain model of mobile phone, the system will incorporate these features into the model to form a personalized verification behavior pattern for the patient.

[0081] The system inputs the patient's current verification behavior data (such as verification time, geographic location, device information, etc.) into the verification behavior model, compares it with the patient's historical verification behavior pattern, and calculates the behavior match. Behavior match is a numerical indicator, usually expressed as a score between 0 and 1. The closer the score is to 1, the higher the fit between the current behavior and the historical behavior characteristics. Specifically, if the patient's current verification behavior data is consistent with his historical behavior pattern (for example, the verification time is between 9 and 11 in the morning, the verification location is near a common city or hospital, and the device used is his common device), the behavior match may be 0.9 or higher, indicating that the current behavior is highly credible; if the patient's current verification behavior is obviously inconsistent with the historical behavior pattern (for example, the verification time is 3 in the morning, the verification location is not a common verification location, and a new device that has never appeared is used), the behavior match may be 0.3 or lower, indicating that the current behavior deviates greatly from the historical characteristics and needs further verification.

[0082] Based on the results of the behavior matching, the system dynamically generates a set of verification instruction sequences to further confirm the authenticity of the patient's identity. The verification instruction sequence is usually an interactive question or operation, such as requiring the patient to enter specific information (such as birthday, the last four digits of the ID card) or complete a specific action (such as gesture verification, face recognition, etc.). If the behavior matching is high (such as greater than 0.6), the system may generate simpler verification instructions; if the behavior matching is low (such as less than or equal to 0.6), the system will generate more complex verification instructions (such as fingerprint or facial recognition + dynamic action verification or voice verification + command response, etc.). The patient completes the interactive operation according to the requirements of the verification instruction sequence, and the system collects the patient's dynamic behavior feature data through the verification process. These dynamic behavior feature data may include feature information reflecting the patient's behavioral habits, such as input speed, gesture trajectory, and facial expression changes. For example, during the gesture verification process, the system will record the path and speed of the patient's finger sliding; during the face recognition process, the system will capture the slight changes in the patient's facial expression.

[0083] The system compares the collected dynamic behavior feature data with the patient's preset feature template and calculates the feature similarity. The preset feature template is the standard behavior feature collected and stored by the system during the patient's first registration or use, such as the patient's unique input habits, gesture patterns, or facial recognition data. Through comparison, the system can determine whether the dynamic behavior feature in this verification meets the patient's feature template.

[0084] After completing the calculation of the behavior match and feature similarity, the system comprehensively determines whether the identity verification has passed based on the preset match threshold and similarity threshold. If the behavior match is greater than the preset match threshold, and the feature similarity is greater than the preset similarity threshold, the system confirms that the patient's identity verification has passed and allows them to proceed to the next step; otherwise, the system considers that the identity verification has failed, and prompts the patient to re-verify or take other security measures (such as manual review). For example, if the behavior match is 0.85 (greater than the preset 0.8 threshold) and the feature similarity is 0.9 (greater than the preset 0.85 threshold), the verification is passed; if any indicator is lower than the threshold, the system will reject the verification.

[0085] Optional, in Figure 1 The following steps may be performed before step S101 of the illustrated embodiment: Receive the diagnosis result sent by the second mobile terminal, the diagnosis result is generated based on the target virtual human body model corresponding to the patient in the virtual medical scene, the virtual medical scene is obtained through the medical institution information, the target virtual human body model is marked according to the disease characteristic words, and the disease characteristic words are semantically analyzed by semantic analysis technology on the patient's voice data and extracted according to preset rules.

[0086] The system first obtains the information of the medical institution selected or recommended by the patient, including department settings, medical equipment resources, doctor's professional expertise, etc. Based on the medical institution information, the corresponding virtual medical scene is obtained, and the virtual scene can be generated through 3D modeling technology.

[0087] The patient uses the first mobile terminal equipped with a dedicated VR device to describe his or her symptoms and condition in a virtual medical consultation scene, and the system collects the patient's voice data. Subsequently, the system uses semantic analysis technology to process the voice data, including speech-to-text, natural language understanding (NLU), and key semantic extraction. The purpose of semantic analysis is to identify key information related to the condition from the patient's voice description, such as symptoms (such as "headache", "cough"), duration (such as "it's been three days"), and influencing factors (such as "the pain is worse in the morning").

[0088] Based on the results of semantic analysis, the system extracts disease feature words from the patient's voice description according to the preset medical rule library. These disease feature words are key clues for medical diagnosis and may include symptoms, signs, medical history, predisposing factors, etc. For example, if the patient describes that "I have had a severe sore throat recently, and I cough frequently, and sometimes cough up yellow sputum", the system may extract feature words such as "sore throat", "cough", and "yellow sputum". In addition, the preset rule library will filter and optimize keywords based on disease relevance and contextual logic to ensure that the extracted feature words are accurate and medically meaningful.

[0089] The system uses the extracted disease feature words to label and dynamically adjust a basic virtual human model to generate a target virtual human model. The basic virtual human model is a general human structure model that includes the capabilities of organ, system, and pathology simulation; while the target virtual human model is personalized for the patient's disease features. For example, if the disease feature words include "sore throat" and "cough", the system will mark the characteristics of inflammation or swelling in the throat area of ​​the virtual human model, and mark possible lesion locations in the respiratory system (such as the trachea or lungs). This feature labeling enables the virtual human model to intuitively reflect the patient's condition and provide support for virtual diagnosis.

[0090] After generating the target virtual human model, the system performs intelligent diagnosis on the model based on the diagnosis and treatment logic of the virtual medical scene. Specifically, the system analyzes the marked disease feature words, the patient's health data (such as historical medical records, examination reports), and the medical resources of the medical institution (such as the doctor's professional knowledge base and diagnostic rules). For example, if the virtual human model is marked with respiratory diseases, the system may simulate the doctor's diagnostic steps in real scenarios, such as asking about medical history, analyzing symptoms, making preliminary diagnoses, and recommending further examination items. The diagnostic process is driven by a preset intelligent diagnostic algorithm, which simulates the doctor's clinical decision-making behavior to generate scientific and reasonable diagnostic results.

[0091] After completing the diagnosis of the target virtual human model in the virtual medical scene, the system generates a diagnostic result containing the diagnosis conclusion and suggestions. The diagnosis result may include the name of the disease (such as "acute bronchitis"), etiology analysis (such as "may be caused by viral infection"), recommended examination items (such as "chest X-ray" or "blood routine test"), and treatment suggestions (such as "anti-inflammatory treatment" or "drink more water and rest"). The system then sends the diagnosis results to the patient's first mobile terminal through the medical cloud platform for the patient to view and confirm. Based on the diagnosis results, the patient can choose the next step of treatment or make an appointment for a real offline medical consultation.

[0092] See also Figure 2, is a structural diagram of a medical treatment system based on a handheld medical insurance service terminal provided in an embodiment of the present application. A medical treatment system 200 based on a handheld medical insurance service terminal specifically includes: The acquisition module 201 is used to acquire the patient's historical medical data, health monitoring data and medical resource data through the medical cloud platform. The historical medical data is the medical data generated during the patient's medical service acceptance process at multiple target medical institutions within a preset historical time period. The target medical institution is the medical service provider that has a medical service relationship with the patient within the preset time period; A first determination module 202, for determining the patient's medical needs based on historical medical data and health monitoring data; The generation module 203 is used to perform correlation analysis on historical medical data and medical resource data based on medical needs, and generate multiple medical paths for patients, each of which includes at least personal information, medical institution, department information corresponding to the medical institution, registration queue information, and examination items; The sending module 204 is used to determine the optimal medical treatment path from multiple medical treatment paths, generate a medical treatment request according to the optimal medical treatment path, and send the medical treatment request to the second mobile terminal of the medical treatment institution corresponding to the optimal medical treatment path; Optionally, the first determining module 202 is specifically configured to: Extract disease characteristics from historical medical data; semantically associate disease characteristics with health monitoring data through a preset medical knowledge graph to generate a health profile of the patient; determine medical needs based on the health profile.

[0093] Optionally, the system further includes a construction module 205, specifically configured to: Define the access rules and data protocols for medical data through preset rules, and build a data access framework for medical data corresponding to all target medical institutions based on the access rules and data protocols. The medical data at least includes historical medical data, health monitoring data and medical resource data; formulate data flow rules and permission management mechanism for medical data based on the data access framework; build a medical cloud platform based on the access framework, data flow rules and permission management mechanism.

[0094] Optionally, the system further includes a verification module 206, which is specifically used to: Obtain the patient's historical verification behavior data within a preset historical time period and current verification behavior data, the historical verification behavior data including historical verification time distribution, historical verification geographical location distribution and historical verification device information; establish a verification behavior model based on the historical verification behavior data; input the current verification behavior data into the verification behavior model to obtain the behavior matching degree; generate a verification instruction sequence based on the behavior matching degree; based on the verification instruction sequence, obtain the patient's dynamic behavior feature data; compare the dynamic behavior feature data with a preset feature template to obtain the feature similarity; when the behavior matching degree is greater than the preset matching degree threshold, and the feature similarity is greater than the preset similarity threshold, confirm that the patient's identity authentication has passed.

[0095] Optionally, the system further includes a receiving module 207, which is specifically configured to: Receive a second medical consultation path sent by a second mobile terminal so that the patient can receive medical consultation according to the second medical consultation path, the second medical consultation path is based on the target medical consultation data and the patient's health monitoring data and is generated through a preset medical consultation model, the difference between the first medical consultation path and the second medical consultation path is greater than a preset threshold, and the target medical consultation data is the historical medical treatment data that the patient is authorized to access.

[0096] Optionally, the system further includes a second determining module 208, further specifically configured to: Obtain the patient's authorization information, and determine the scope of data that is allowed to be accessed based on the authorization information. The data scope includes at least the data type, access rights, and time range of the historical medical data; calculate the correlation between the historical medical data within the data range and the optimal medical path to obtain the correlation; determine the historical medical data with a correlation greater than a preset correlation value as the target medical data.

[0097] Optionally, the system further includes a medical consultation module 209, which is specifically used for: Receive the diagnosis result sent by the second mobile terminal, the diagnosis result is generated based on the target virtual human body model corresponding to the patient in the virtual medical scene, the virtual medical scene is obtained through the medical institution information, the target virtual human body model is marked according to the disease characteristic words, and the disease characteristic words are semantically analyzed by semantic analysis technology on the patient's voice data and extracted according to preset rules.

[0098] It should be noted that: when the device provided in the above embodiment realizes its function, only the division of the above functional modules is used as an example. In actual application, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. In addition, the device and method embodiments provided in the above embodiment belong to the same concept, and the specific implementation process is detailed in the method embodiment, which will not be repeated here.

[0099] This embodiment also discloses an electronic device, referring to Figure 3 The electronic device may include: at least one processor 301 , at least one communication bus 302 , a user interface 303 , a network interface 304 , and at least one memory 305 .

[0100] The communication bus 302 is used to realize the connection and communication between these components.

[0101] The user interface 303 may include a display screen (Display) and a camera (Camera). Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0102] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a WI-FI interface).

[0103] Among them, the processor 301 may include one or more processing cores. The processor 301 uses various interfaces and lines to connect various parts in the entire server, and executes various functions of the server and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 305, and calling data stored in the memory 305. Optionally, the processor 301 can be implemented in at least one hardware form of digital signal processing (Digital Signal Processing, DSP), field programmable gate array (Field-Programmable Gate Array, FPGA), and programmable logic array (Programmable Logic Array, PLA). The processor 301 can integrate one or a combination of a central processing unit (Central Processing Unit, CPU), a graphics processing unit (Graphics Processing Unit, GPU) and a modem. Among them, the CPU mainly processes the operating system, user interface and application programs; the GPU is responsible for rendering and drawing the content to be displayed on the display screen; the modem is used to process wireless communications. It can be understood that the above-mentioned modem may not be integrated into the processor 301, and it can be implemented separately through a chip.

[0104] Among them, the memory 305 may include a random access memory (Random Access Memory, RAM) and may also include a read-only memory (Read-Only Memory). Optionally, the memory 305 includes a non-transitory computer-readable storage medium. The memory 305 can be used to store instructions, programs, codes, code sets or instruction sets. The memory 305 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playback function, an image playback function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area may store data involved in the above-mentioned various method embodiments, etc. The memory 305 may also be optionally at least one storage device located away from the aforementioned processor 301. As Figure 3 As shown, the memory 305 as a computer storage medium may include an operating system, a network communication module, a user interface module, and an application program for a medical treatment method based on a handheld medical insurance service terminal.

[0105] exist Figure 3 In the electronic device shown, the user interface 303 is mainly used to provide an input interface for the user and obtain data input by the user; and the processor 301 can be used to call an application program stored in the memory 305 for a medical treatment method based on a handheld medical insurance service terminal. When executed by one or more processors 301, the electronic device executes one or more methods in the above-mentioned embodiments.

[0106] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all described as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required for the present application.

[0107] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0108] In the several embodiments provided in this application, it should be understood that the disclosed devices can be implemented in other ways. For example, the device embodiments described above are only schematic, such as the division of units, which is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some service interfaces, and the indirect coupling or communication connection of devices or units can be electrical or other forms.

[0109] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0110] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0111] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable memory 305. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a memory 305 and includes several instructions for a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned memory 305 includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a magnetic disk or an optical disk.

[0112] The above is only an exemplary embodiment of the present disclosure and cannot be used to limit the scope of the present disclosure. That is, any equivalent changes and modifications made according to the teachings of the present disclosure are still within the scope of the present disclosure. After considering the disclosure of the specification, those skilled in the art will easily think of other embodiments of the present disclosure. This application is intended to cover any modification, use or adaptation of the present disclosure, which follows the general principles of the present disclosure and includes common knowledge or customary technical means in the technical field that are not recorded in the present disclosure. The description and examples are only regarded as exemplary, and the scope and spirit of the present disclosure are defined by the claims.

Claims

1. A medical treatment method based on a handheld medical insurance service terminal, characterized in that: Applied to a first mobile terminal, where the first mobile terminal is a patient terminal, the method includes: Obtain the patient's historical medical data, health monitoring data and medical resource data through the medical cloud platform. The historical medical data refers to the medical data generated during the patient's medical service reception at multiple target medical institutions within a preset historical time period. The target medical institution refers to the medical service provider with whom the patient has a medical service relationship within the preset time period; Determining the patient's medical needs based on the historical medical data and the health monitoring data; Based on the medical treatment needs, the historical medical treatment data and the medical resource data are correlated and analyzed to generate multiple medical treatment paths for the patient, each of which includes at least personal information, medical institution, department information corresponding to the medical institution, registration queue information, and examination items; An optimal medical consultation path is determined among the multiple medical consultation paths, a medical consultation request is generated according to the optimal medical consultation path, and the medical consultation request is sent to a second mobile terminal of a medical consultation institution corresponding to the optimal medical consultation path.

2. The method according to claim 1, characterized in that: Before obtaining the patient's historical medical data, health monitoring data, and medical resource data through the medical cloud platform, the method further includes: Define access rules and data protocols for medical data through preset rules, and build a data access framework for medical data corresponding to all target medical institutions based on the access rules and data protocols, where the medical data at least includes the historical medical data, the health monitoring data, and the medical resource data; Formulate data transfer rules and authority management mechanisms for the medical data based on the data access framework; The medical cloud platform is constructed according to the access framework, the data flow rules and the authority management mechanism.

3. The method according to claim 1, characterized in that The determining the patient's medical needs based on the historical medical data and the health monitoring data specifically includes: extracting disease characteristics from the historical medical visit data; By using a preset medical knowledge graph, the disease characteristics are semantically associated with the health monitoring data to generate a health profile of the patient; The medical treatment needs are determined based on the health portrait.

4. The method according to claim 1, characterized in that Before obtaining the patient's historical medical data, health monitoring data, and medical resource data, the method further includes: Acquire the patient's historical verification behavior data within the preset historical time period and current verification behavior data, wherein the historical verification behavior data includes historical verification time distribution, historical verification geographic location distribution, and historical verification device information; Establishing a verification behavior model based on the historical verification behavior data; Inputting the current verification behavior data into the verification behavior model to obtain a behavior matching degree; generating a verification instruction sequence according to the behavior matching degree; Based on the verification instruction sequence, obtaining dynamic behavior characteristic data of the patient; Comparing the dynamic behavior feature data with a preset feature template to obtain feature similarity; When the behavior matching degree is greater than a preset matching degree threshold, and the feature similarity is greater than a preset similarity threshold, it is confirmed that the patient's identity verification has passed.

5. The method according to claim 1, characterized in that: After determining the optimal medical consultation path among the multiple medical consultation paths, generating a medical consultation request according to the optimal medical consultation path, and sending the medical consultation request to the second mobile terminal of the medical consultation institution corresponding to the optimal medical consultation path, the method further includes: Receive a second medical consultation path sent by the second mobile terminal, so that the patient can receive medical consultation according to the second medical consultation path, wherein the second medical consultation path is based on the target medical consultation data and the patient's health monitoring data and is generated through a preset medical consultation model, the difference between the first medical consultation path and the second medical consultation path is greater than a preset threshold, and the target medical consultation data is the historical medical treatment data that the patient is authorized to access.

6. The method according to claim 5, characterized in that Before receiving the second medical consultation path sent by the second mobile terminal so that the patient can receive medical consultation according to the second medical consultation path, the method further includes: Obtaining the authorization information of the patient, and determining the data scope that is allowed to be accessed according to the authorization information, wherein the data scope at least includes the data type, access permission and time range of the historical medical data; Calculating the correlation between the historical medical treatment data within the data range and the optimal medical treatment path to obtain a correlation degree; The historical medical consultation data whose correlation is greater than the preset correlation value is determined as the target medical consultation data.

7. The method according to claim 1, characterized in that After determining the optimal medical consultation path among the multiple medical consultation paths, generating a medical consultation request according to the optimal medical consultation path, and sending the medical consultation request to the second mobile terminal of the medical consultation institution corresponding to the optimal medical consultation path, the method further includes: Receive the diagnosis result sent by the second mobile terminal, wherein the diagnosis result is generated by performing diagnosis based on the target virtual human body model corresponding to the patient in a virtual medical scene, wherein the virtual medical scene is obtained through medical institution information, and the target virtual human body model is obtained by marking the virtual human body model according to disease characteristic words, and the disease characteristic words are semantically analyzed on the patient's voice data through semantic analysis technology and extracted according to preset rules.

8. A medical treatment system based on a handheld medical insurance service terminal, characterized in that: include: An acquisition module is used to acquire the patient's historical medical data, health monitoring data and medical resource data through the medical cloud platform. The historical medical data is the medical data generated during the patient's medical service reception at multiple target medical institutions within a preset historical time period. The target medical institution is a medical service provider with which the patient has a medical service relationship within the preset time period; A first determination module, configured to determine the patient's medical needs based on the historical medical data and the health monitoring data; A generation module, for performing correlation analysis on the historical medical data and the medical resource data based on the medical needs, and generating multiple medical paths for the patient, each of which includes at least personal information, a medical institution, information on the department corresponding to the medical institution, registration queue information, and examination items; The sending module is used to determine the optimal medical treatment path among the multiple medical treatment paths, generate a medical treatment request according to the optimal medical treatment path, and send the medical treatment request to the second mobile terminal of the medical treatment institution corresponding to the optimal medical treatment path.

9. A medical device based on a handheld medical insurance service terminal, characterized in that: include: one or more processors and memory; The memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to enable the medical device based on the handheld medical insurance service terminal to execute the method described in any one of claims 1-7.

10. A computer-readable storage medium comprising instructions, characterized in that: When the instruction is executed on a medical device based on a handheld medical insurance service terminal, the medical device based on a handheld medical insurance service terminal executes the method as described in any one of claims 1-7.

Images