Multi-platform medical data integration and diagnosis and treatment assisting method and system

Abstract

According to the multi-platform medical data integration and diagnosis and treatment assistance method and system, data such as patient chatting records, behavior logs and past medical histories stored in all medical service platforms are received and subjected to normalization processing, multi-platform data matching is completed with identity information of patients as the core, and a patient identity mapping table is established to achieve full-platform data association; during diagnosis and treatment, corresponding full-platform patient data are retrieved from a patient identity mapping table through patient identity information, disease information is accurately extracted based on an SOAP medical framework, a medical record first draft is automatically generated in combination with a medical knowledge base, and preliminary diagnosis and treatment suggestions have scientific basis and clear confidence by taking an evidence-based medical database as a support; a closed loop from data integration to clinical application is realized, accurate and efficient diagnosis and treatment decision support is provided for medical staff, normalization and accuracy of diagnosis and treatment services are promoted, and misdiagnosis and missed diagnosis risks are reduced.

Description

Technical Field

[0001] This application relates to the field of medical big data mining and diagnostic assistance, specifically to a method and system for multi-platform medical data integration and diagnostic assistance. Background Technology

[0003] The current healthcare service system still faces three major pain points in multi-channel management: First, channel fragmentation leads to service disruptions; various platforms operate independently and lack unified data interaction standards, causing patients to repeatedly verify their identity and describe their condition when switching between platforms, artificially breaking service continuity. For example, after completing a consultation on WeChat Work, patients must repeat identity verification and description of their condition when switching to DingTalk, with an average response time of over 30 minutes, creating a vicious cycle of "medical treatment - waiting - repeated medical treatment," significantly reducing the medical experience and efficiency. Second, the problem of patient data silos is prominent; chat logs, interaction behaviors, and other data generated by different platforms are stored in a scattered manner, making it impossible for doctors to obtain a complete patient medical history. Treatment decisions lack comprehensive information support, easily leading to misdiagnosis or duplicate examinations, wasting medical resources. Third, the application of AI-assisted capabilities is superficial; most medical chat systems only remain at the level of simple keyword replies, lacking a deep understanding of patient complaints and the ability to process them in a structured manner. They cannot automatically extract key symptoms, generate standardized medical records, or combine multi-channel data for comprehensive analysis to provide professional treatment suggestions, making it difficult to support the precise and efficient supply of medical services. Summary of the Invention

[0004] In view of the above problems, this application provides a method for multi-platform medical data integration and diagnosis and treatment assistance to solve the above problems.

[0005] To achieve the above objectives, the inventors provide a method for multi-platform medical data integration and diagnostic assistance, which includes:

[0006] The integration of multi-platform medical data is performed using the following steps:

[0007] The system receives patient data stored on various platforms and performs normalization processing; the patient data includes chat logs, behavior logs, and past medical history.

[0008] Based on the patient's identity information, the patient data stored on each platform is matched to obtain the full-platform patient data corresponding to each patient's identity information;

[0009] Based on the patient's identity information, the corresponding patient data across the entire platform is associated and processed to establish a patient identity mapping table;

[0010] The diagnostic and treatment assistance process includes the following steps:

[0011] Obtain the patient's identity information;

[0012] Based on the patient's identity information, obtain the corresponding full-platform patient data from the patient identity mapping table;

[0013] Based on the SOAP medical framework, disease information is obtained from patient data across the entire platform; the disease information includes chief complaint keywords, accompanying symptoms, and past medical history.

[0014] Based on symptom information and a medical knowledge base, a draft medical record is obtained; the draft medical record includes the chief complaint, present illness, and past medical history.

[0015] Based on the initial draft of the medical records and evidence-based medicine database, preliminary diagnosis and treatment suggestions and their confidence levels were obtained.

[0016] Furthermore, the step of matching patient data stored on each platform based on the patient's identity information to obtain the full-platform patient data corresponding to each patient's identity information includes the following steps:

[0017] A comprehensive search is performed on the patient data received from various platforms to extract the patient's identity information, which includes identity identifiers and auxiliary identity information.

[0018] If a complete and valid identity identifier is found in the patient data of a certain platform, then the identity identifier will be used as the matching basis to link and integrate the corresponding data of the patient across all platforms.

[0019] If a patient's data on a certain platform is found to be missing an identity identifier or contains an invalid identity identifier, the patient's auxiliary identity information will be matched with the behavioral logs in a multi-dimensional manner, and the corresponding data of the patient on all platforms will be integrated.

[0020] Furthermore, when obtaining disease information from patient data across the entire platform based on the SOAP medical framework, the process also includes determining whether disease information is missing, and if so, asking supplementary questions.

[0021] Furthermore, the chief complaint and accompanying symptoms are obtained by analyzing and judging historical chat records within a preset time window of patient data across the entire platform based on a large-scale language model.

[0022] Furthermore, it also includes storing the initial draft of the medical record, the chief complaint, preliminary treatment suggestions, and the confidence level of the suggestions in the medical CRM health record database based on the patient's identity information.

[0023] Furthermore, the medical CRM health record database also includes 360° dynamic patient profiles, which update patient tags according to a preset multi-dimensional tagging system based on the initial draft of the medical record, chief complaint, preliminary treatment suggestions, and suggestion confidence level.

[0024] Furthermore, the multi-dimensional tagging system includes basic attribute tags, health status tags, and service demand tags.

[0025] A multi-platform medical data integration and diagnosis assistance system includes:

[0026] The multi-platform API interface module is used to interact with various platforms, obtain patient data stored on each platform, and perform normalization processing; the patient data includes chat logs, behavior logs, and past medical history.

[0027] The identity recognition and association module is used to match the patient data stored on each platform, obtain the full platform patient data corresponding to the identity information of each patient, perform association processing, and establish a patient identity mapping table.

[0028] The large language processing module includes a general inspection unit, a chief complaint extraction unit, an automatic medical record generation unit, and a preliminary treatment suggestion unit. The general inspection unit is used to perform compliance and integrity checks on historical chat records of patients' identity information within a preset time window of patient data across the entire platform. The chief complaint extraction unit is used to extract symptom information from historical chat records of patients' identity information within a preset time window of patient data across the entire platform based on the SOAP medical framework. The automatic medical record generation unit combines symptom information with a medical knowledge base to obtain a draft medical record. The preliminary treatment suggestion unit combines the draft medical record with an evidence-based medicine database to obtain preliminary treatment suggestions and suggestion confidence levels.

[0029] Furthermore, it also includes a health record and patient profile improvement module, which includes a medical CRM health record database and a dynamic patient profile engine multi-dimensional tag system. The medical CRM health record database is used to store draft medical records, chief complaints, preliminary treatment suggestions, and suggestion confidence levels. The dynamic patient profile engine multi-dimensional tag system includes basic attribute tags, health status tags, and service demand tags, and updates patient tags based on draft medical records, chief complaints, preliminary treatment suggestions, and suggestion confidence levels.

[0030] Furthermore, it also includes an application output module, which includes a cross-channel unified user service unit, a medical record draft output unit, and a precision medicine service push unit; the cross-channel unified user service unit is used to obtain the patient's own full-platform patient data; the medical record draft output unit is used to output the medical record draft; the precision medicine service push unit pushes corresponding medical services based on the dynamic patient profile engine's multi-dimensional tag system.

[0031] Unlike existing technologies, the above-mentioned technical solution receives and normalizes patient chat logs, behavioral logs, and past medical histories stored on various medical service platforms. Using patient identity information as the core, it completes multi-platform data matching, establishes a patient identity mapping table to achieve data association across all platforms, and realizes multi-platform data interoperability. This ensures the comprehensiveness and accuracy of symptom information extraction and effectively reduces information omissions caused by data fragmentation. During diagnosis and treatment, the corresponding patient data from the patient identity mapping table is retrieved using the patient's identity information. Based on the SOAP medical framework, symptom information is accurately extracted, and combined with a medical knowledge base, a draft medical record is automatically generated. This simplifies the medical record writing process, improves the work efficiency of medical staff, and, supported by an evidence-based medicine database, ensures that preliminary treatment recommendations have a scientific basis and clear confidence, significantly reducing bias caused by subjective judgment. This achieves a closed loop from data integration to clinical application, providing medical staff with accurate and efficient decision support for diagnosis and treatment, helping to improve the standardization and accuracy of medical services, reducing the risk of misdiagnosis and missed diagnosis, and ensuring that patients receive higher-quality and more personalized medical services. This promotes the upgrading of clinical diagnosis and treatment towards digitalization and intelligence.

[0032] The above description of the invention is merely an overview of the technical solution of this application. In order to enable those skilled in the art to better understand the technical solution of this application and to implement it based on the description and drawings, and to make the above-mentioned objectives and other objectives, features and advantages of this application easier to understand, the following description is provided in conjunction with the specific embodiments and drawings of this application. Attached Figure Description

[0033] The accompanying drawings are only used to illustrate the principles, implementation methods, applications, features, and effects of specific embodiments of the present invention and other related contents, and should not be considered as limitations on this application.

[0034] In the accompanying drawings of the instruction manual:

[0035] Figure 1 This is a flowchart illustrating the multi-platform medical data integration and diagnosis assistance method described in the specific implementation method;

[0036] Figure 2 This is a schematic diagram of the modules of the multi-platform medical data integration and diagnosis and treatment assistance system described in a specific implementation. Detailed Implementation

[0037] To illustrate the possible application scenarios, technical principles, implementable specific solutions, and achievable objectives and effects of this application in detail, the following description, in conjunction with the listed specific embodiments and accompanying drawings, provides a detailed explanation. The embodiments described herein are merely illustrative of the technical solutions of this application and are therefore intended only as examples, not as limiting the scope of protection of this application.

[0038] In this document, the term "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The term "embodiment" appearing in various places throughout the specification does not necessarily refer to the same embodiment, nor does it specifically limit its independence or connection with other embodiments. In principle, in this application, as long as there are no technical contradictions or conflicts, the technical features mentioned in each embodiment can be combined in any way to form corresponding implementable technical solutions.

[0039] Unless otherwise defined, the technical terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the use of related terms herein is merely for the purpose of describing particular embodiments and is not intended to limit this application.

[0040] In the description of this application, the term "and / or" is used to describe the logical relationship between objects, indicating that three relationships can exist. For example, A and / or B means: A exists, B exists, and A and B exist simultaneously. Additionally, the character " / " in this document generally indicates that the preceding and following objects have an "or" logical relationship.

[0041] In this application, terms such as “first” and “second” are used only to distinguish one entity or operation from another, and do not necessarily require or imply any actual quantity, hierarchy or order between these entities or operations.

[0042] Without further limitations, the use of terms such as “comprising,” “including,” “having,” or other similar open-ended expressions in this application is intended to cover non-exclusive inclusion, which does not exclude the presence of additional elements in a process, method, or product that includes the stated elements, such that a process, method, or product that includes a list of elements may include not only those defined elements but also other elements not expressly listed, or elements inherent to such a process, method, or product.

[0043] As understood in the Examination Guidelines, in this application, expressions such as "greater than," "less than," and "exceeding" are understood to exclude the stated number; expressions such as "above," "below," and "within" are understood to include the stated number. Furthermore, in the description of the embodiments in this application, "multiple" means two or more (including two), and similar expressions related to "multiple" are also understood in this way, such as "multiple groups" and "multiple times," unless otherwise explicitly specified.

[0044] In the description of the embodiments of this application, the space-related expressions used, such as "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "vertical," "top," "bottom," "inner," "outer," "clockwise," "counterclockwise," "axial," "radial," and "circumferential," indicate the orientation or positional relationship based on the orientation or positional relationship shown in the specific embodiments or drawings. They are only for the purpose of describing the specific embodiments of this application or for the reader's understanding, and do not indicate or imply that the device or component referred to must have a specific position, a specific orientation, or be constructed or operated in a specific orientation. Therefore, they should not be construed as limitations on the embodiments of this application.

[0045] The processor described in the embodiments of this application can be implemented by hardware, firmware, software, or a combination thereof. It can be a circuit, one or more of an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a digital signal processing device (DSPD), a programmable logic device (PLD), a field-programmable gate array (FPGA), a central processing unit (CPU), a controller, a microcontroller, or a microprocessor. It also includes other physical, biological, or chemical structures that can implement the same or equivalent functions as the processors listed above, such as biological neurons, quantum computing units, DNA computing units, etc., so that the processor can execute some or all of the steps in the computer program or method involved in the various embodiments of this application, or any combination of the steps mentioned therein.

[0046] The computer program involved in the embodiments can be stored in a computer device readable storage medium, which includes, but is not limited to, disks, magnetic tapes, magnetic cards, floppy disks, flash memory, optical disks, optical cards, read-only memory (ROM), random access memory (RAM), erasable programmable ROM (EPROM), and electrically erasable programmable ROM (EEPROM), etc., and also includes other biological, physical, or chemical structures that can achieve the same or equivalent functions as the storage media listed above, such as DNA, RNA, proteins, and other units with information storage capabilities. In specific embodiments, the storage medium involved can be one of the above-mentioned media types, or a combination of the above-mentioned media types. In different embodiments, the computer program involved in the embodiments can be centrally stored in a single medium, or distributed and stored in multiple media. The memory containing the computer device readable storage medium can be non-volatile memory or random access memory. These computer device readable storage media can be built into the device, or can be connected to the device involved in the embodiments as an external device or part of an external device. In some embodiments, the memory having a computer device readable storage medium is deployed locally; in other embodiments, the memory may be deployed remotely from the processor, for example, as a network-attached memory accessed via RF circuitry or an external port and a communication network, wherein the communication network may be the Internet, one or more intranets, a local area network (LAN), a wide area network (WLAN), a storage area network (SAN), or a suitable combination thereof, as long as computer device access to the memory is enabled. Furthermore, the computer program involved in the embodiments may be stored in plaintext / ciphertext form, or it may be designed as training data, integrated and recombined through model training and implicitly stored in the parameter states of a deep neural network or other machine learning model.

[0047] A multi-platform medical data integration and diagnosis assistance method receives and normalizes patient chat logs, behavioral logs, and past medical histories stored on various medical service platforms. Using patient identity information as the core, it completes multi-platform data matching, establishes a patient identity mapping table to achieve data association across all platforms, and realizes data interoperability. This ensures the comprehensiveness and accuracy of symptom information extraction and effectively reduces information omissions caused by data fragmentation. During diagnosis, the method retrieves corresponding patient data from the patient identity mapping table based on the patient's identity information, accurately extracts symptom information using the SOAP medical framework, and automatically generates initial draft medical records using a medical knowledge base. This simplifies the medical record writing process, improves the work efficiency of medical staff, and, supported by evidence-based medicine databases, ensures that preliminary diagnosis and treatment recommendations have scientific basis and clear confidence, significantly reducing bias caused by subjective judgment. This achieves a closed loop from data integration to clinical application, providing medical staff with accurate and efficient decision support for diagnosis and treatment, helping to improve the standardization and accuracy of diagnosis and treatment services, reducing the risk of misdiagnosis and missed diagnosis, and ensuring that patients receive higher-quality and more personalized medical services, thus promoting the digital and intelligent upgrading of clinical diagnosis and treatment.

[0048] The following combination Figure 1 An implementation method for multi-platform medical data integration and diagnosis assistance is provided, including:

[0049] S10. The multi-platform medical data integration process includes the following steps:

[0050] S101. Receive patient data stored on various platforms and perform normalization processing; the patient data includes chat logs, behavior logs, and past medical history;

[0051] S102. Match the patient data stored on each platform based on the patient's identity information to obtain the full-platform patient data corresponding to the identity information of each patient.

[0052] S103. Based on the patient's identity information, perform association processing on the corresponding full-platform patient data to establish a patient identity mapping table;

[0053] S20. The diagnostic and treatment assistance shall perform the following steps:

[0054] S201. Obtain the patient's identity information;

[0055] S202. Obtain the corresponding full-platform patient data from the patient identity mapping table based on the patient's identity information;

[0056] S203. Obtain disease information from patient data across the entire platform based on the SOAP medical framework; the disease information includes chief complaint keywords, accompanying symptoms, and past medical history.

[0057] S204. Based on symptom information and a medical knowledge base, obtain a draft medical record; the draft medical record includes the chief complaint, present illness, and past medical history.

[0058] S205. Based on the initial draft of the medical record and the evidence-based medicine database, obtain preliminary diagnosis and treatment suggestions and the confidence level of the suggestions.

[0059] In the above step S10, which involves the integration of medical data across multiple platforms, the "platform" refers to a medical service interaction platform that has one or more functions such as online consultation, patient feedback, medication guidance, appointment scheduling, and multidisciplinary consultation, including but not limited to H5 pages, WeChat Work, Lark, and DingTalk.

[0060] In step S101, the patient data received from each platform is limited to use within the necessary scope related to diagnosis and treatment, ensuring the patient's right to know and right to choose, and is received with the patient's authorization. Specifically, it covers core data directly related to the patient's diagnosis, treatment plan formulation, and health management, including chat logs, behavior logs, and past medical history. Among them, the chat logs only include content related to diagnosis and treatment, such as the patient's description of symptoms, feedback on symptoms, treatment questions, and recovery status, in communication on the platform. The behavior logs focus on the patient's medical-related operation trajectory on each platform, including key information that reflects the patient's health needs and treatment progress, such as consultation on diseases, medication records, appointment of examination items, and application for diagnosis and treatment services. The past medical history covers the patient's past disease diagnosis results, treatment experience, surgical history, allergy history, family medical history, and other core medical record information, providing complete medical history support for cross-platform diagnosis and treatment services. Specifically, a standardized data interface layer can be established by calling the open APIs of medical service interaction platforms (such as Enterprise WeChat Customer Contact API, Lark Message Notification API, and DingTalk Smart Workflow API). The interface layer can support the real-time reception of chat messages, behavior logs, and past medical history from various platforms, and perform data normalization processing (such as JSON format) to ensure the consistency of data structure across different platforms.

[0061] In step S102, matching patient data stored on each platform based on the patient's identity information is only conducted for legitimate medical purposes such as medical diagnosis and service continuity assurance, and the identity information is not used for purposes other than medical treatment. Finally, a corresponding cross-platform data identity mapping table is established based on the patient's identity information. The establishment and use of the mapping table are strictly limited to necessary scenarios that improve the efficiency of medical services and ensure cross-platform diagnosis and treatment continuity. Security protection measures can be taken, such as deployment from multiple dimensions such as data storage, access, transmission, and supervision, to prevent the leakage, tampering, or illegal use of patient identity information and related data.

[0062] In some embodiments, the identity information includes an identity identifier; the identity identifier refers to key information that can directly and uniquely identify the patient's identity, such as ID card number, medical insurance card number, or a unique patient ID uniformly assigned by a medical institution, etc., which have legal or system-specific attributes and can directly and uniquely locate a specific patient, ensuring the accuracy and uniqueness of identity recognition; that is, the step of matching patient data stored on each platform based on the patient's identity information to obtain the full-platform patient data corresponding to each patient's identity information includes the following steps: extracting the associated identity identifier from the patient data of each platform, and performing identity identifier comparison and retrieval matching on the patient data of each platform using the patient's identity identifier as a unified matching keyword, associating and aggregating the patient data containing the same identity identifier across all platforms, and directly obtaining the full-platform patient data corresponding to each identity identifier; this helps to significantly improve the efficiency of multi-platform data integration, and at the same time, relying on the uniqueness of the identity identifier, effectively avoids matching errors caused by information duplication or similarity, ensuring that the full-platform data of each patient can be accurately matched, providing strong support for the rapid establishment of subsequent patient identity mapping tables and the efficient application of medical data.

[0063] In some embodiments, the identity information includes, in addition to the identity identifier, auxiliary identity information. This auxiliary identity information refers to supplementary information used to assist in verifying the patient's identity, such as one or more of the patient's name, contact information, date of birth, and home address. It does not possess unique identification but can be combined with behavioral logs (such as consultation types and medication records) to locate a specific patient. The process of matching patient data stored on various platforms based on the patient's identity information to obtain the full-platform patient data corresponding to each patient's identity information includes the following steps:

[0064] A comprehensive search is performed on the patient data received from various platforms to extract the patient's identity information, which includes identity identifiers and auxiliary identity information.

[0065] If a complete and valid identity identifier is found in the patient data of a certain platform, then the identity identifier will be used as the matching basis to link and integrate the corresponding data of the patient across all platforms.

[0066] If a patient's data on a certain platform is missing or has an invalid identity identifier, the patient's auxiliary identity information will be matched with behavioral logs in multiple dimensions. This includes, but is not limited to, combinations of patient auxiliary identity information (such as name and contact information) and combinations of patient auxiliary identity information and behavioral logs (such as contact information and medication records). Similarity analysis will be performed to accurately locate specific patients. Then, patient data scattered across different platforms will be collected and integrated to finally obtain the full-platform patient data corresponding to each patient's identity information.

[0067] By employing a hierarchical matching mechanism that prioritizes identity identification and supplements auxiliary information, the efficiency and accuracy of identity identification matching are preserved. Furthermore, by combining auxiliary identity information with behavioral logs, the mechanism effectively addresses the industry pain point of incomplete identity identification on some platforms. This significantly improves the coverage and completeness of multi-platform medical data integration, ensuring accurate association of patient data even in scenarios with incomplete identity information. This provides a reliable guarantee for the subsequent establishment of patient identity mapping tables and the application of full-dimensional medical data.

[0068] In step S103, the process of associating the corresponding patient data across all platforms based on the patient's identity information to establish a patient identity mapping table involves, after completing the matching of patient data stored on each platform and obtaining the patient data across all platforms corresponding to each patient's identity information, using the patient's identity information as the core index, systematically associating the patient data scattered across various platforms (such as H5 pages, WeChat Work, Lark, DingTalk, etc.), and constructing a mapping table that includes legal identity identifiers (such as ID card numbers) and auxiliary identity information (such as mobile phone numbers), and the unique IDs exclusive to each platform. This mapping table is stored in a structured form, accurately binding the patient's core identity identifier with the user IDs of each platform, forming a unified identity system of "one person, one table, multiple ID correspondences." This allows for quick location of the patient's exclusive identifier on each platform through ID card number and mobile phone number, and also allows for reverse association of the patient's core identity information through the user ID of any platform, effectively breaking down identity barriers between channels and achieving unique and standardized management of patient identities across platforms.

[0069] In the diagnostic and treatment assistance execution integration process described in step S20 above, the patient's identity information obtained in step S201 is obtained with the patient's right to know and right to choose, and with the patient's authorization, and is limited to use within the scope necessary for diagnosis and treatment.

[0070] In step S203, obtaining symptom information from patient data across the entire platform based on the SOAP medical framework is achieved through in-depth analysis of multi-dimensional data, including integrated patient chat logs, behavioral logs, and past medical histories. Specifically, the chief complaint keywords and accompanying symptoms can be extracted from historical chat logs within a preset time window of patient data across the entire platform using natural language processing technology. This extraction process captures key information such as "persistent cough for a week" and "severe abdominal pain," accurately pinpointing the core reason for the patient's visit. Preferably, a large-scale medical language model is used to extract these from historical chat logs within the preset time window of patient data across the entire platform. This large-scale medical language model, trained on medical research literature and electronic medical records, is a large-scale pre-trained language model specifically adapted to the needs of medical scenarios. It can accurately identify the correspondence between professional terminology, colloquial expressions, and standardized expressions of symptom descriptions in medical scenarios, effectively filtering out non-diagnosis-related content from chat logs. This significantly improves the accuracy and efficiency of chief complaint keyword extraction. Compared to general large-scale language models, it is better suited to the professionalism and specificity of medical data, avoiding the omission or misjudgment of core symptom requests due to semantic ambiguity. The standardized extraction process using the SOAP framework not only ensures the comprehensiveness and accuracy of symptom information but also transforms unstructured chat logs and other data into structured clinical diagnosis and treatment information. This provides standardized and precise data support for the generation of subsequent draft medical records and the output of treatment recommendations, effectively improving the scientific rigor and practicality of diagnostic and treatment assistance. The aforementioned preset time window is a specific time range defined for accurately extracting patient chief complaint keywords and used to filter historical chat logs from across the platform. Its core purpose is to focus on the patient's recent symptom descriptions, filtering out historical information irrelevant to current treatment needs, ensuring that the extracted chief complaint keywords accurately reflect the patient's current health status, and avoiding information interference or invalidation due to excessively long time spans. The preset time window value can be flexibly set according to the clinical diagnosis and treatment scenario. Specifically, it can be within 24 hours (suitable for rapid diagnosis and treatment of acute diseases, such as sudden abdominal pain, high fever, etc.), within 7 days (suitable for routine follow-up visits for common chronic diseases or subacute diseases, such as cough, joint pain, etc.), or within 14 days (suitable for diagnosis and treatment scenarios that require observation of the evolution of symptoms, such as postoperative recovery follow-up, chronic disease monitoring, etc.). Medical staff can also manually adjust the time range according to the patient's specific disease type and diagnosis and treatment needs, taking into account both the accuracy and flexibility of information extraction.

[0071] In some embodiments, the step of obtaining symptom information from patient data across the platform based on the SOAP medical framework also includes performing integrity checks on chat logs to identify key information gaps, such as missing symptom duration, i.e., determining whether symptom information is missing. If so, supplementary questions are asked. This ensures the compliance and completeness of subsequent diagnosis and treatment-related data. Specifically, relying on the structured requirements of the SOAP framework for clinical diagnosis and treatment information, the integrity of symptom description dimensions in chat logs is verified, focusing on identifying missing key information such as symptom duration, pain intensity, frequency of attacks, and factors that relieve or aggravate the symptoms. For example, if a patient only states "headache" without specifying the duration or pattern of the headache, the system will automatically trigger a standardized supplementary questioning mechanism when privacy-sensitive information or key information gaps are detected. This mechanism promptly prompts medical staff to perform data anonymization for privacy risks and pushes precise guiding questions to the patient for information gaps, such as "How long have your headache symptoms lasted?" and "Does your headache accompany nausea, vomiting, etc." Through automated process intervention, the system ensures that the finally extracted symptom information meets both compliance requirements and the completeness and accuracy required for clinical diagnosis and treatment, laying a high-quality data foundation for subsequent draft medical records and output of treatment recommendations.

[0072] Step S204 above, which obtains a draft medical record based on symptom information and a medical knowledge base, automatically generates a standardized and complete draft medical record using structured symptom information extracted from the SOAP medical framework and a built-in medical knowledge base. The structured symptom information includes core diagnostic and treatment data such as patient chief complaint keywords, accompanying symptoms, and past medical history. The medical knowledge base integrates professional medical resources such as clinical treatment guidelines, disease diagnostic criteria, medical record writing standards, and symptom description paradigms for common diseases. First, the extracted symptom information undergoes semantic parsing and dimensional verification to ensure the completeness and accuracy of symptom descriptions and medical history information. Then, matching rules from the medical knowledge base are invoked to intelligently match the patient's specific symptom information with corresponding disease treatment guidelines and medical record templates. Following the clinical medical record structure of "chief complaint - present illness - past medical history - auxiliary examination suggestions," relevant content is automatically filled and organized to generate a draft medical record that conforms to medical document standards. It replaces the cumbersome process of traditional manual medical record writing, significantly shortens the time for medical record writing, and can avoid problems such as information omissions and non-standard expressions that may occur in manual writing based on a standardized medical knowledge base, providing high-quality basic document support for subsequent diagnosis and treatment.

[0073] Step S204 above, which obtains preliminary treatment recommendations and their confidence levels based on the initial draft of the medical record and the evidence-based medicine database, intelligently derives and generates preliminary treatment recommendations and their corresponding confidence levels by combining the initial draft of the medical record and the evidence-based medicine database. The evidence-based medicine database contains a large amount of clinically validated treatment protocols, drug efficacy data, disease management pathways, prognostic assessment standards, and other evidence-based medical evidence, covering conventional treatment methods and individualized treatment adjustment criteria for different diseases. When this unit runs, it first performs in-depth analysis of the core diagnostic information, symptom characteristics, and medical history background in the initial draft of the medical record to clarify the patient's core health problems; then, based on the evidence retrieval and matching algorithm of the evidence-based medicine database, it selects treatment protocols that highly match the patient's symptoms, while also verifying the protocol's suitability by considering the patient's past medical history, medication history, and other individual circumstances; finally, based on indicators such as the level of evidence-based medicine evidence, frequency of clinical application, and fit of the matched protocol, it calculates and assigns a corresponding confidence level value to the preliminary treatment recommendation, forming a complete output result of "treatment recommendation content + confidence level assessment". It provides healthcare professionals with evidence-based reference plans to help them make rapid treatment decisions. At the same time, the confidence level labeling can help healthcare professionals judge the reference value of the recommendations and improve the scientificity and rigor of treatment decisions.

[0074] In some embodiments, the system also includes storing the initial draft of the medical record, the chief complaint, preliminary treatment recommendations, and the confidence level of the recommendations in the medical CRM health record database based on the patient's identity information. The medical CRM (Customer Relationship Management) health record database records relevant data from each patient's treatment in chronological order, forming a traceable and continuous health trajectory and establishing a complete personal digital health profile. It provides medical staff with a unified and convenient entry point for querying patient health data, allowing for quick retrieval of historical medical records, evolution of chief complaints, and past treatment recommendations during follow-up visits, avoiding repetitive inquiries and data entry, improving treatment efficiency, and ensuring the continuity and consistency of medical services across scenarios and cycles. Simultaneously, the complete health record data provides solid data support for optimizing personalized treatment plans, long-term management of chronic diseases, and analysis of disease trend changes. Furthermore, the retention of recommendation confidence levels helps medical staff assess the reference value of past treatment recommendations, reducing the risk of treatment decisions. The above storage is limited to the necessary scope related to treatment, ensuring the patient's right to know and right to choose, and is stored with the patient's authorization. The storage process strictly adheres to relevant medical data security regulations, employing security measures such as encrypted storage and tiered access control to ensure the security and compliance of data storage.

[0075] In some embodiments, the medical CRM health record database also includes a 360° dynamic patient profile. This 360° dynamic patient profile automatically integrates core medical data such as the patient's initial medical record draft, chief complaint, preliminary treatment suggestions, and suggestion confidence level through a built-in algorithm model. Combined with historical health record information, it performs data classification, feature extraction, and tag matching according to a preset multi-dimensional tag system. It also has the ability to perceive data changes in real time. Whenever a patient generates new medical records or updates their health data, the engine automatically triggers a tag update mechanism to supplement, correct, or iterate the original patient profile, ensuring that the patient profile accurately and in real-time reflects their current health status, treatment needs, and disease progression trends. This provides data support and decision-making basis for medical staff to conduct personalized treatment, intelligent health management, and precise allocation of medical resources. The multi-dimensional tag system includes basic attribute tags (such as gender, age, etc.), health status tags (such as hypertension, diabetes, etc.), and service demand tags (such as "acute illness," "stable period of chronic disease," "postoperative recovery period," etc.).

[0076] This application also provides a multi-platform medical data integration and diagnosis and treatment assistance system, breaking down data silos across multiple medical service platforms. Through a standardized data integration process, it achieves cross-platform collection and structured processing of diagnosis and treatment-related data such as patient chat logs, behavioral logs, and past medical histories. This not only solves the industry pain point of doctors being unable to obtain complete patient medical histories due to data fragmentation, but also achieves accurate extraction of symptom information based on the SOAP medical framework and large-scale medical language models. Combined with medical knowledge bases and evidence-based medicine databases, it automatically generates draft medical records and preliminary diagnosis and treatment suggestions with confidence levels, significantly improving the efficiency and scientific rigor of diagnosis and treatment assistance. The following is a continuation of this... Figure 2 This paper presents an implementation method for a multi-platform medical data integration and diagnosis and treatment assistance system, including:

[0077] The multi-platform API interface module is used to interact with various platforms, obtain patient data stored on each platform, and perform normalization processing; the patient data includes chat logs, behavior logs, and past medical history.

[0078] The identity recognition and association module is used to match the patient data stored on each platform, obtain the full platform patient data corresponding to the identity information of each patient, perform association processing, and establish a patient identity mapping table.

[0079] The large language processing module includes a general inspection unit, a chief complaint extraction unit, an automatic medical record generation unit, and a preliminary treatment suggestion unit. The general inspection unit is used to perform compliance and integrity checks on historical chat records of patients' identity information within a preset time window of patient data across the entire platform. The chief complaint extraction unit is used to extract symptom information from historical chat records of patients' identity information within a preset time window of patient data across the entire platform based on the SOAP medical framework. The automatic medical record generation unit combines symptom information with a medical knowledge base to obtain a draft medical record. The preliminary treatment suggestion unit combines the draft medical record with an evidence-based medicine database to obtain preliminary treatment suggestions and suggestion confidence levels.

[0080] In the aforementioned multi-platform API integration module, data interaction is limited to the necessary scope of diagnosis and treatment, ensuring patients' right to know and right to choose, and is conducted with patient authorization. Specifically, it covers core data directly related to patient diagnosis, treatment plan development, and health management, including chat logs, behavior logs, and past medical history. The chat logs only include patient communication on the platform regarding symptom descriptions, feedback, treatment questions, and recovery status. The behavior logs focus on the patient's medical-related operational trajectory across platforms, including consultations, medication records, examination appointments, and requests for medical services—key information reflecting the patient's health needs and treatment progress. The past medical history covers core medical records such as past diagnoses, treatment experiences, surgical history, allergies, and family medical history, providing comprehensive medical history support for cross-platform diagnosis and treatment services. Specifically, stable integration with multiple platforms such as H5 pages, WeChat Work, Lark, and DingTalk is achieved by calling the open APIs of each platform's interface layer (such as the Enterprise WeChat customer contact API, Lark message notification API, and DingTalk smart workflow API). The interface layer supports real-time reception of chat messages, behavior logs, and past medical history from various platforms, and performs data normalization processing (such as JSON format) to ensure data structure consistency across different platforms.

[0081] In the aforementioned identity recognition and association module, the matching of patient data stored on various platforms based on the patient's identity information is only conducted for legitimate medical purposes such as medical diagnosis and service continuity assurance, and the identity information is not used for purposes other than medical care. Finally, a corresponding cross-platform data identity mapping table is established based on the patient's identity information. The establishment and use of the mapping table are strictly limited to necessary scenarios that improve the efficiency of medical services and ensure cross-platform diagnosis and treatment continuity. Security protection measures can be taken, such as deployment from multiple dimensions such as data storage, access, transmission, and supervision, to prevent the leakage, tampering, or illegal use of patient identity information and related data.

[0082] In some embodiments, the identity information includes an identity identifier; the identity identifier refers to key information that can directly and uniquely identify the patient's identity, such as ID card number, medical insurance card number, or a unique patient ID uniformly assigned by a medical institution, etc., which have legal or system-specific attributes and can directly and uniquely locate a specific patient, ensuring the accuracy and uniqueness of identity recognition; that is, the step of matching patient data stored on each platform based on the patient's identity information to obtain the full-platform patient data corresponding to each patient's identity information includes the following steps: extracting the associated identity identifier from the patient data of each platform, and performing identity identifier comparison and retrieval matching on the patient data of each platform using the patient's identity identifier as a unified matching keyword, associating and aggregating the patient data containing the same identity identifier across all platforms, and directly obtaining the full-platform patient data corresponding to each identity identifier; this helps to significantly improve the efficiency of multi-platform data integration, and at the same time, relying on the uniqueness of the identity identifier, effectively avoids matching errors caused by information duplication or similarity, ensuring that the full-platform data of each patient can be accurately matched, providing strong support for the rapid establishment of subsequent patient identity mapping tables and the efficient application of medical data.

[0083] In some embodiments, the identity information includes, in addition to the identity identifier, auxiliary identity information. This auxiliary identity information refers to supplementary information used to assist in verifying the patient's identity, such as one or more of the patient's name, contact information, date of birth, and home address. It does not possess unique identification but can be combined with behavioral logs (such as consultation types and medication records) to locate a specific patient. The process of matching patient data stored on various platforms based on the patient's identity information to obtain the full-platform patient data corresponding to each patient's identity information includes the following steps:

[0084] A comprehensive search is performed on the patient data received from various platforms to extract the patient's identity information, which includes identity identifiers and auxiliary identity information.

[0085] If a complete and valid identity identifier is found in the patient data of a certain platform, then the identity identifier will be used as the matching basis to link and integrate the corresponding data of the patient across all platforms.

[0086] If a patient's data on a certain platform is missing or has an invalid identity identifier, the patient's auxiliary identity information will be matched with behavioral logs in multiple dimensions. This includes, but is not limited to, combinations of patient auxiliary identity information (such as name and contact information) and combinations of patient auxiliary identity information and behavioral logs (such as contact information and medication records). Similarity analysis will be performed to accurately locate specific patients. Then, patient data scattered across different platforms will be collected and integrated to finally obtain the full-platform patient data corresponding to each patient's identity information.

[0087] By employing a hierarchical matching mechanism that prioritizes identity identification and supplements auxiliary information, the efficiency and accuracy of identity identification matching are preserved. Furthermore, by combining auxiliary identity information with behavioral logs, the mechanism effectively addresses the industry pain point of incomplete identity identification on some platforms. This significantly improves the coverage and completeness of multi-platform medical data integration, ensuring accurate association of patient data even in scenarios with incomplete identity information. This provides a reliable guarantee for the subsequent establishment of patient identity mapping tables and the application of full-dimensional medical data.

[0088] Based on the patient's identity information, the corresponding patient data across all platforms is correlated to establish a patient identity mapping table. This involves matching patient data stored on each platform to obtain the patient data corresponding to each patient's identity information across all platforms. Using the patient's identity information as the core index, patient data scattered across various platforms (such as H5 pages, WeChat Work, Lark, DingTalk, etc.) is systematically correlated. This constructs a mapping table that includes legal identity identifiers (such as ID card numbers) and auxiliary identity information (such as mobile phone numbers), corresponding to the unique IDs of each platform. This mapping table is stored in a structured format, accurately binding the patient's core identity identifier with the user IDs of each platform, forming a unified identity system of "one person, one table, multiple IDs." This allows for quick location of the patient's unique identifier on each platform using their ID card number or mobile phone number, and also enables reverse association of the patient's core identity information using the user ID of any platform. This effectively breaks down identity barriers between channels and achieves unique and standardized management of patient identities across platforms.

[0089] The overall inspection unit in the aforementioned large language processing module performs integrity checks on chat logs, identifying gaps in key information such as missing symptom duration. This determines whether symptom information is missing, and if so, prompts supplementary questions. This ensures the compliance and completeness of subsequent diagnosis and treatment-related data. Specifically, relying on the SOAP framework's structured requirements for clinical diagnosis and treatment information, the system verifies the completeness of symptom descriptions in chat logs, focusing on identifying missing key information such as symptom duration, pain intensity, frequency of attacks, and factors that alleviate or aggravate the symptoms. For example, a patient might only state "headache" without specifying its duration or pattern. When privacy-sensitive information or gaps in key information are detected, the system automatically triggers a standardized supplementary questioning mechanism. It promptly alerts medical staff to anonymize data to address privacy risks and pushes precise guiding questions to the patient regarding information gaps, such as "How long have your headache symptoms lasted?" and "Are your headaches accompanied by nausea or vomiting?" Through automated process intervention, the system ensures that the final extracted symptom information meets both compliance requirements and the completeness and accuracy needed for clinical diagnosis and treatment, laying a high-quality data foundation for subsequent draft medical records and treatment recommendations.

[0090] The chief complaint extraction unit in the aforementioned large-scale language processing module obtains this information through in-depth analysis of multi-dimensional data, including patient chat logs, behavioral logs, and past medical histories, integrated across the entire platform. Specifically, the chief complaint keywords and accompanying symptoms can be extracted from historical chat logs within a preset time window of patient data across the entire platform using natural language processing technology. Key information such as "persistent cough for a week" and "severe abdominal pain" are extracted to accurately pinpoint the core reason for the patient's visit. Preferably, a large-scale medical language model is used to extract these from historical chat logs within the preset time window of patient data across the entire platform. This large-scale medical language model is a pre-trained language model specifically adapted to the needs of medical scenarios, using medical research literature and electronic medical records as training data. It can accurately identify the correspondence between professional terminology and colloquial and standardized expressions of symptom descriptions in medical scenarios, effectively filtering out non-diagnosis-related content from chat logs, significantly improving the accuracy and efficiency of chief complaint keyword extraction. Compared to general-purpose large-scale language models, it is better suited to the professionalism and specificity of medical data, avoiding the omission or misjudgment of core symptom requests due to semantic ambiguity. The standardized extraction process using the SOAP framework not only ensures the comprehensiveness and accuracy of symptom information but also transforms unstructured chat logs and other data into structured clinical diagnosis and treatment information. This provides standardized and precise data support for the generation of subsequent draft medical records and the output of treatment recommendations, effectively improving the scientific rigor and practicality of diagnostic and treatment assistance. The aforementioned preset time window is a specific time range defined for accurately extracting patient chief complaint keywords and used to filter historical chat logs from across the platform. Its core purpose is to focus on the patient's recent symptom descriptions, filtering out historical information irrelevant to current treatment needs, ensuring that the extracted chief complaint keywords accurately reflect the patient's current health status, and avoiding information interference or invalidation due to excessively long time spans. The preset time window value can be flexibly set according to the clinical diagnosis and treatment scenario. Specifically, it can be within 24 hours (suitable for rapid diagnosis and treatment of acute diseases, such as sudden abdominal pain, high fever, etc.), within 7 days (suitable for routine follow-up visits for common chronic diseases or subacute diseases, such as cough, joint pain, etc.), or within 14 days (suitable for diagnosis and treatment scenarios that require observation of the evolution of symptoms, such as postoperative recovery follow-up, chronic disease monitoring, etc.). Medical staff can also manually adjust the time range according to the patient's specific disease type and diagnosis and treatment needs, taking into account both the accuracy and flexibility of information extraction.

[0091] The automatic medical record generation unit within the aforementioned large language processing module automatically generates standardized and complete draft medical records based on structured symptom information extracted using the SOAP medical framework and a built-in medical knowledge base. The structured symptom information includes core diagnostic and treatment data such as patient chief complaint keywords, accompanying symptoms, and past medical history. The medical knowledge base integrates professional medical resources such as clinical treatment guidelines, disease diagnostic criteria, medical record writing standards, and symptom description paradigms for common diseases. During operation, this unit first performs semantic parsing and dimensional verification on the extracted symptom information to ensure the completeness and accuracy of symptom descriptions and medical history information. Then, it invokes matching rules from the medical knowledge base to intelligently match the patient's specific symptom information with corresponding disease treatment guidelines and medical record templates. Following the clinical medical record structure of "chief complaint - present illness - past medical history - auxiliary examination suggestions," it automatically fills in and organizes relevant content to generate a draft medical record that conforms to medical document standards. The application of this unit not only replaces the cumbersome process of traditional manual medical record writing and significantly shortens the time for writing medical records, but also avoids problems such as information omissions and non-standard expressions that may occur in manual writing based on a standardized medical knowledge base, providing high-quality basic document support for subsequent diagnosis and treatment work.

[0092] The preliminary treatment suggestion unit in the aforementioned large language processing module intelligently derives and generates preliminary treatment suggestions and corresponding confidence levels by combining the standardized draft medical records output by the automatic medical record generation unit with an authoritative evidence-based medicine database. The evidence-based medicine database contains a large amount of clinically validated treatment protocols, drug efficacy data, disease management pathways, prognostic assessment standards, and other evidence-based medical data, covering conventional treatment methods and individualized treatment adjustment criteria for different diseases. When this unit runs, it first performs in-depth analysis of the core diagnostic information, symptom characteristics, and medical history in the draft medical record to clarify the patient's core health problems. Then, based on the evidence retrieval and matching algorithms of the evidence-based medicine database, it selects treatment plans that highly match the patient's symptoms, while simultaneously verifying the suitability of the plans by considering the patient's past medical history, medication history, and other individual circumstances. Finally, based on indicators such as the level of evidence-based medicine evidence, frequency of clinical application, and suitability of the matched plans, it calculates and assigns a corresponding confidence level value to the preliminary treatment suggestion, forming a complete output result of "treatment suggestion content + confidence level assessment". The application of this unit can provide medical staff with reference plans supported by evidence-based medicine, assisting them in making rapid diagnosis and treatment decisions. At the same time, the confidence level labeling can help medical staff judge the reference value of the recommendations and improve the scientificity and rigor of diagnosis and treatment decisions.

[0093] In some embodiments, a health record and patient profile improvement module is also included. This module includes a medical CRM health record database, a master data management unit, and a 360° dynamic patient profile. The medical CRM health record database stores draft medical records, chief complaints, preliminary treatment suggestions, and suggestion confidence levels. The master data management unit synchronizes core treatment data such as the patient's draft medical records, chief complaints, preliminary treatment suggestions, and suggestion confidence levels to the health record database, and performs data classification, feature extraction, and tag matching to update patient tags according to a preset multi-dimensional tag system. The 360° dynamic patient profile is a real-time updated user profile based on the patient tags updated by the master data management unit.

[0094] The health record and patient profile improvement module's medical CRM health record database records relevant data from each patient's treatment in chronological order, forming a traceable and continuous health trajectory and establishing a complete personal health digital file. It provides medical staff with a unified and convenient entry point for querying patient health data. During follow-up visits, they can quickly retrieve information such as historical medical records, changes in chief complaints, and past treatment recommendations, avoiding repeated inquiries and data entry, improving treatment efficiency, and ensuring the continuity and consistency of medical services across scenarios and cycles. Simultaneously, the complete health record data provides solid data support for personalized treatment plan optimization, long-term chronic disease management, and analysis of disease trend changes. Furthermore, the retention of recommendation confidence levels helps medical staff assess the reference value of past treatment suggestions, reducing the risk of treatment decisions. The aforementioned storage is limited to necessary use related to treatment, ensuring the patient's right to know and right to choose, and storage is only permitted with the patient's authorization. The storage process strictly adheres to relevant medical data security regulations, employing security measures such as encrypted storage and hierarchical access control to ensure the security and compliance of data storage.

[0095] In some embodiments, the application output module is further included, which includes a cross-channel unified user service unit, a medical record draft output unit, and a precision medicine service push unit; the cross-channel unified user service unit is used to obtain the patient's own full-platform patient data; the medical record draft output unit is used to output the medical record draft; and the precision medicine service push unit pushes corresponding medical services based on the multi-dimensional tag system of the dynamic patient profile engine.

[0096] The aforementioned cross-channel unified user service unit, based on a patient identity mapping table, establishes a cross-platform unified identity system, providing patients with a one-stop data query portal. Patients can conveniently access their integrated patient data across all platforms through any authorized medical service interaction platform (H5 page, WeChat, Lark, DingTalk, etc.) using their own identity identifier or platform-specific ID. This includes information such as chat logs, behavior logs, past medical history, and previous treatment suggestions from various channels. At the same time, it supports patients in viewing, verifying, and authorizing the management of their personal health data, fully protecting patients' right to know and control their data.

[0097] The aforementioned medical record draft output unit is responsible for structuring and outputting the standardized medical record drafts generated by the automatic medical record generation unit in accordance with the format requirements of clinical medical documents. It supports the generation of editable or printable file formats such as PDF and Word. These files can be pushed to the work terminals of medical staff for reference, modification and improvement, or synchronized to the patient's service portal for their access. This effectively opens up the flow of medical record data between doctors and patients and improves the efficiency of the transmission of medical documents.

[0098] The aforementioned precision medicine service delivery unit connects to the dynamic patient profiles in the medical CRM health record database. Based on its multi-dimensional tagging system, it achieves personalized and precise delivery of medical services. Specifically, the unit reads patients' health status, symptom characteristics, treatment needs, risk levels, and other tag information in real time, and matches corresponding medical service resources accordingly. For example, it sends medication change reminders and follow-up appointment booking links to patients tagged "postoperative recovery period + regular dressing changes"; it sends medication guidance and condition monitoring tasks to patients tagged "chronic disease stable period + medication management"; and it prioritizes emergency access and specialist doctor matching services to patients tagged "high-risk emergencies + urgent medical treatment." Through the precise association between tags and services, it significantly improves the efficiency and suitability of medical service delivery, facilitating personalized health management.

[0099] Finally, it should be noted that although the above embodiments have been described in the text and drawings of this application, this should not limit the scope of patent protection of this application. Any technical solutions that are based on the essential concept of this application and utilize the content described in the text and drawings of this application, resulting in equivalent structural or procedural substitutions or modifications, as well as the direct or indirect application of the technical solutions of the above embodiments to other related technical fields, are all included within the scope of patent protection of this application.

Claims

1. A method for integrating medical data across multiple platforms and assisting in diagnosis and treatment, characterized in that, include: The integration of multi-platform medical data is performed using the following steps: The system receives patient data stored on various platforms and performs normalization processing; the patient data includes chat logs, behavior logs, and past medical history. Based on the patient's identity information, the patient data stored on each platform is matched to obtain the full-platform patient data corresponding to each patient's identity information; Based on the patient's identity information, the corresponding patient data across the entire platform is associated and processed to establish a patient identity mapping table; The diagnostic and treatment assistance process includes the following steps: Obtain the patient's identity information; Based on the patient's identity information, obtain the corresponding full-platform patient data from the patient identity mapping table; Based on the SOAP medical framework, disease information is obtained from patient data across the entire platform; the disease information includes chief complaint keywords, accompanying symptoms, and past medical history. Based on symptom information and a medical knowledge base, a draft medical record is obtained; the draft medical record includes the chief complaint, present illness, and past medical history. Based on the initial draft of the medical records and evidence-based medicine database, preliminary diagnosis and treatment suggestions and their confidence levels were obtained.

2. The multi-platform medical data integration and diagnosis assistance method according to claim 1, characterized in that, The steps involved in matching patient data stored on various platforms based on patient identity information to obtain the full-platform patient data corresponding to each patient's identity information include the following: A comprehensive search is performed on the patient data received from various platforms to extract the patient's identity information, which includes identity identifiers and auxiliary identity information. If a complete and valid identity identifier is found in the patient data of a certain platform, then the identity identifier will be used as the matching basis to link and integrate the corresponding data of the patient across all platforms. If a patient's data on a certain platform is found to be missing an identity identifier or contains an invalid identity identifier, the patient's auxiliary identity information will be matched with the behavioral logs in a multi-dimensional manner, and the corresponding data of the patient on all platforms will be integrated.

3. The multi-platform medical data integration and diagnosis assistance method according to claim 1, characterized in that, When obtaining disease information from patient data across the entire platform based on the SOAP medical framework, the process also includes determining whether disease information is missing, and if so, asking supplementary questions.

4. The multi-platform medical data integration and diagnosis assistance method according to claim 1, characterized in that, The chief complaint and accompanying symptoms are obtained by analyzing and judging historical chat records within a preset time window of patient data across the entire platform using a large language model.

5. The multi-platform medical data integration and diagnosis assistance method according to claim 1, characterized in that, It also includes storing the initial draft of the medical record, the chief complaint, preliminary treatment suggestions, and the confidence level of the suggestions in the medical CRM health record database based on the patient's identity information.

6. The multi-platform medical data integration and diagnosis assistance method according to claim 5, characterized in that, The medical CRM health record database also includes 360° dynamic patient profiles, which update patient tags according to a preset multi-dimensional tagging system based on the initial draft of the medical record, chief complaint, preliminary treatment suggestions, and suggestion confidence level.

7. The multi-platform medical data integration and diagnosis assistance method according to claim 6, characterized in that, The multi-dimensional tagging system includes basic attribute tags, health status tags, and service demand tags.

8. A multi-platform medical data integration and diagnosis and treatment assistance system, comprising: The multi-platform API interface module is used to interact with various platforms, obtain patient data stored on each platform, and perform normalization processing; the patient data includes chat logs, behavior logs, and past medical history. The identity recognition and association module is used to match the patient data stored on each platform, obtain the full platform patient data corresponding to the identity information of each patient, perform association processing, and establish a patient identity mapping table. The large language processing module includes a general examination unit, a chief complaint extraction unit, an automatic medical record generation unit, and a preliminary diagnosis and treatment suggestion unit; The overall inspection unit is used to perform compliance and integrity checks on the historical chat records of patients' identity information across the entire platform's patient data within a preset time window; The chief complaint extraction unit is used to extract symptom information from historical chat records within a preset time window of the patient data across the entire platform based on the SOAP medical framework; the automatic medical record generation unit combines the symptom information with the medical knowledge base to obtain a draft medical record; the preliminary treatment suggestion unit combines the draft medical record with the evidence-based medicine database to obtain preliminary treatment suggestions and suggestion confidence levels.

9. The multi-platform medical data integration and diagnosis assistance system according to claim 8, characterized in that, It also includes a health record and patient profile improvement module, which includes a medical CRM health record database and a dynamic patient profile engine with a multi-dimensional tag system; The medical CRM health record database is used to store draft medical records, chief complaints, preliminary treatment suggestions, and suggestion confidence levels; The dynamic patient profiling engine's multi-dimensional tagging system includes basic attribute tags, health status tags, and service demand tags; Patient labels were updated based on the initial draft of the medical record, the chief complaint, preliminary treatment recommendations, and the confidence level of the recommendations.

10. The multi-platform medical data integration and diagnosis assistance system according to claim 9, characterized in that, It also includes an application output module, which includes a cross-channel unified user service unit, a medical record draft output unit, and a precision medicine service push unit; the cross-channel unified user service unit is used to obtain the patient's own full-platform patient data. The initial draft medical record output unit is used to output the initial draft of the medical record. The precision medicine service push unit uses the dynamic patient profile engine's multi-dimensional tag system to push corresponding medical services.

Images