Method and device for collecting multi-source heterogeneous medical data based on a knowledge base

Abstract

The present disclosure provides a multi-source heterogeneous medical data collection method and device based on a collection knowledge base. The method comprises: identifying vendor information and version information of a medical system; matching a corresponding collection strategy from the collection knowledge base based on the vendor information and the version information, wherein the collection strategy comprises a strategy identifier and a data processing rule; collecting medical data from the medical system according to the collection strategy and outputting standardized medical data; recording the strategy identifier, the data processing rule, and a collection log corresponding to the vendor information and the version information; and analyzing the collection log to optimize the collection strategy, and storing the optimized collection strategy into the collection knowledge base, wherein optimizing the collection strategy comprises: analyzing the collection log to identify an abnormal log; generating an optimization rule for the abnormal log; and updating the data processing rule based on the optimization rule.

Description

Technical Field

[0001] This disclosure relates to the field of medical information technology, and more specifically, to a method and device for acquiring multi-source heterogeneous medical data based on a knowledge base. Background Technology

[0002] Currently, healthcare information systems (including but not limited to Hospital Information Systems (HIS), Electronic Medical Record Systems (EMRS), Laboratory Information Systems (LIS), Picture Archiving and Communication Systems (PACS), surgical anesthesia systems, pathology systems, and ICU monitoring systems) are widely deployed in various medical institutions. These systems continuously generate and accumulate large amounts of medical data during operation. However, this data exhibits significant heterogeneity in its source, format, and storage method: data sources encompass multiple independent business systems; data formats include structured, semi-structured, and unstructured data; and data storage is dispersed across various media such as relational databases, file systems, and interface services. Furthermore, even systems from the same vendor often differ in data format and content definition due to variations in hospital deployment versions. These factors collectively lead to fragmented distribution of medical data, difficulties in interoperability between systems, and the formation of so-called "data silos," severely hindering the integration, utilization, and value extraction of medical data resources.

[0003] Current medical data acquisition technologies have the following main shortcomings:

[0004] (1) Customized development of data acquisition interfaces leads to low development efficiency. Traditional solutions require writing separate data acquisition scripts or interface programs for each heterogeneous data source, forming a "one-to-one" data acquisition mode. This mode not only has a long development cycle and is labor-intensive and repetitive, but also has high maintenance costs in the later stage. Furthermore, when the data source structure or interface protocol changes, the data acquisition program is difficult to adapt quickly, resulting in poor system scalability.

[0005] (2) General data extraction, transformation, and loading (ETL) tools are not well-suited for the medical field. Although traditional commercial ETL tools have basic data integration functions, they lack a deep understanding of medical business processes and data semantics, especially when processing semi-structured and unstructured medical data. In addition, such tools usually adopt a closed architecture, have high licensing fees, and are difficult to seamlessly integrate with existing hospital information systems.

[0006] (3) Long deployment cycle and difficulty in ensuring data quality. Existing data collection solutions generally have a long implementation cycle, complex operation and configuration, low execution efficiency and automation, which can easily lead to quality problems such as data integrity loss and poor consistency, making it difficult to meet the clinical and scientific research needs for real-time and accurate medical data collection.

[0007] Therefore, there is an urgent need for an intelligent data acquisition platform that can automatically process multi-source heterogeneous data in order to improve acquisition efficiency, reduce maintenance costs, and ensure data quality. Summary of the Invention

[0008] To address the aforementioned technical issues, this disclosure constructs a multi-source heterogeneous big data intelligent acquisition platform based on a multi-level, associative, and traceable acquisition knowledge base, and designs a complete closed-loop process from automatic identification, intelligent matching, execution acquisition, effect evaluation to knowledge base optimization.

[0009] According to one aspect of this disclosure, a method for acquiring multi-source heterogeneous medical data based on an acquisition knowledge base is provided. The method includes: identifying vendor information and version information of a medical system; matching a corresponding acquisition strategy from the acquisition knowledge base based on the vendor information and version information, wherein the acquisition strategy includes a strategy identifier (ID) and data processing rules; acquiring medical data from the medical system according to the acquisition strategy and outputting standardized medical data; recording the strategy identifier, data processing rules, and acquisition logs corresponding to the vendor information and version information; and analyzing the acquisition logs to optimize the acquisition strategy, and storing the optimized acquisition strategy in the acquisition knowledge base. Optimizing the acquisition strategy includes: analyzing the acquisition logs to identify abnormal logs; generating optimization rules for abnormal logs; and updating the data processing rules based on the optimization rules.

[0010] According to embodiments of this disclosure, generating optimization rules for abnormal logs includes: analyzing the abnormal logs to generate multiple processing suggestions, the multiple processing suggestions including optimizing one or more rules in the data processing rules and adding sub-rules of one or more rules; and manually reviewing and testing the multiple processing suggestions to select one processing suggestion from the multiple processing suggestions as the optimization rule.

[0011] According to embodiments of this disclosure, matching a corresponding acquisition strategy from the acquisition knowledge base includes: in response to the acquisition knowledge base including acquisition strategies that precisely match manufacturer information and version information, applying the precisely matched acquisition strategy; in response to the acquisition knowledge base including acquisition strategies that are similarly matched to manufacturer information and version information, selecting the optimal acquisition strategy from the acquisition knowledge base based on a strategy matching algorithm, and manually fine-tuning the optimal acquisition strategy to obtain a fine-tuned acquisition strategy; and in response to the acquisition knowledge base not including acquisition strategies that precisely match or are similarly matched to manufacturer information and version information, manually configuring a new acquisition strategy.

[0012] According to embodiments of this disclosure, selecting the optimal acquisition strategy based on the strategy matching algorithm includes recommending the optimal acquisition strategy based on vendor information, version information, and the data structure of the database corresponding to the vendor information and version information, and through similarity calculation.

[0013] According to embodiments of this disclosure, the knowledge base includes a case library, and the method further includes: storing manufacturer information and version information, as well as a finely tuned collection strategy corresponding to the manufacturer information and version information, as first supplementary cases in the case library, and storing manufacturer information and version information, as well as a new collection strategy corresponding to the manufacturer information and version information, as second supplementary cases in the case library.

[0014] According to embodiments of this disclosure, the knowledge base includes a case library, and matching a corresponding collection strategy from the knowledge base includes using a machine learning model to automatically recommend a collection strategy based on historical cases in the case library or to generate a new collection strategy.

[0015] According to embodiments of this disclosure, the method further includes performing an effectiveness evaluation after collecting medical data and outputting standardized medical data, and analyzing the collection logs based on the results of the effectiveness evaluation to optimize the collection strategy, wherein the effectiveness evaluation includes data quality evaluation and collection efficiency evaluation.

[0016] According to embodiments of this disclosure, the method further includes performing data quality verification after collecting medical data, wherein: in response to the data quality verification result meeting a predetermined standard, standardized medical data is output; and in response to the data quality verification result not meeting the predetermined standard, a new collection strategy is selected, and medical data is collected according to the new collection strategy.

[0017] According to embodiments of this disclosure, the data processing rules include field mapping rules, data splicing and splitting rules, data format conversion rules, and data filtering rules.

[0018] According to embodiments of this disclosure, multi-source heterogeneous medical data includes medical data from multiple data sources, including hospital information systems, electronic medical record systems, laboratory information systems, image archiving and communication systems, surgical anesthesia systems, pathology systems, and ICU monitoring systems.

[0019] According to another aspect of this disclosure, a multi-source heterogeneous medical data acquisition device is provided, the device comprising: a memory storing computer program instructions; and a processor coupled to the memory, the processor being configured to execute the computer program instructions to implement the above-described multi-source heterogeneous medical data acquisition method based on an acquisition knowledge base.

[0020] According to another aspect of this disclosure, a computer-readable storage medium is provided, wherein computer-readable instructions are stored on the computer-readable storage medium, which, when executed by a processor, implement the above-described method for acquiring multi-source heterogeneous medical data based on an acquisition knowledge base.

[0021] According to another aspect of this disclosure, a computer program product is provided, including computer-readable instructions that, when executed by a processor, cause the processor to perform the aforementioned multi-source heterogeneous medical data acquisition method based on an acquisition knowledge base.

[0022] By utilizing the multi-source heterogeneous medical data acquisition method based on the acquisition knowledge base according to the above aspects of this disclosure, a collection knowledge base is formed by collecting various information such as the manufacturers, versions, storage methods, and storage formats of common medical information systems. When implemented in hospitals, the acquisition strategy is automatically selected according to the actual system manufacturer and version used, thereby realizing the automation and standardization of data acquisition, thereby improving efficiency, reducing manual intervention, and ensuring data quality. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are merely some exemplary embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0024] Figure 1 A first flowchart of a multi-source heterogeneous medical data acquisition method based on an acquisition knowledge base according to an embodiment of the present disclosure is shown;

[0025] Figure 2 A second flowchart of a multi-source heterogeneous medical data acquisition method based on an acquisition knowledge base according to an embodiment of the present disclosure is shown;

[0026] Figure 3 A schematic diagram of a knowledge base for acquisition according to an embodiment of the present disclosure is shown;

[0027] Figure 4 A schematic diagram of a multi-source heterogeneous medical data acquisition platform constructed according to the method of an embodiment of the present disclosure is shown;

[0028] Figure 5 A flowchart illustrating the acquisition process of multi-source heterogeneous medical data according to embodiments of the present disclosure is shown; and

[0029] Figure 6 A block diagram of a multi-source heterogeneous medical data acquisition device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the described embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0031] Unless otherwise defined, the technical or scientific terms used in this disclosure shall have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. The terms "first," "second," and similar terms used in this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Terms such as "comprising" or "including" mean that the element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Terms such as "connection" or "coupled" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect. Terms such as "upper," "lower," "left," and "right" are used only to indicate relative positional relationships, and these relative positional relationships may change accordingly when the absolute position of the described object changes. To keep the following description of the embodiments of this disclosure clear and concise, detailed descriptions of some known functions and components are omitted.

[0032] This disclosure uses flowcharts to illustrate the steps of a method according to embodiments of this disclosure. It should be understood that the preceding or following steps are not necessarily performed in exact order. Instead, the steps can be processed in reverse order or simultaneously. Furthermore, other operations can be added to these processes, or one or more steps can be removed from them.

[0033] In the specification and drawings of this disclosure, elements are described in singular or plural forms according to embodiments. However, the singular and plural forms are suitably chosen for the presented cases merely for ease of explanation and are not intended to limit the disclosure thereto. Thus, a singular form may include a plural form, and a plural form may include a singular form, unless the context clearly indicates otherwise.

[0034] The following description, with reference to the accompanying drawings, details the multi-source heterogeneous medical data acquisition method, multi-source heterogeneous medical data acquisition device, computer-readable storage medium, and computer program product provided in this disclosure.

[0035] Figure 1 A first flowchart S100 of a multi-source heterogeneous medical data acquisition method based on an acquisition knowledge base according to an embodiment of the present disclosure is shown. Reference will now be made to... Figure 1The following describes in detail the various steps of the multi-source heterogeneous medical data acquisition method based on a knowledge base in the embodiments of this disclosure.

[0036] First, such as Figure 1 As shown, the first flowchart S100 of the multi-source heterogeneous medical data acquisition method based on the acquisition knowledge base disclosed herein may include the various steps shown in processes S1020 to S1100.

[0037] In process S1020, the manufacturer information and version information of the medical system can be identified.

[0038] In the initial stage of data acquisition, a secure connection with the target data source is first established. According to the acquisition method disclosed herein, multiple data access adapters are integrated to establish encrypted communication channels with various medical information systems deployed in the hospital environment. Specifically, medical information systems may include, but are not limited to, mainstream medical business platforms such as Hospital Information Systems (HIS), Electronic Medical Record Systems (EMRS), Laboratory Information Systems (LIS), Picture Archiving and Communication Systems (PACS), surgical anesthesia systems, pathology systems, and ICU monitoring systems.

[0039] Furthermore, the data collection method disclosed herein has multi-protocol access capabilities, providing a configurable access layer that supports at least one or more of the following combinations: direct database connection mode, connecting to relational and non-relational databases through standard database drivers; API interface call mode, supporting standard protocol interfaces such as RESTful API, SOAP Web Service, and HL7FHIR; file transfer mode, supporting FTP, SFTP, FTPS protocols and timed reading of shared file directories (SMB / NFS); and message queue mode, connecting to message middleware such as Kafka and RabbitMQ to achieve asynchronous data subscription.

[0040] Furthermore, the data collection method disclosed herein can establish a secure connection with the data source. For example, all connection channels use TLS / SSL encrypted transmission by default and support a two-way authentication mechanism based on IP whitelists and digital certificates to ensure that the data transmission process complies with medical information security standards.

[0041] After a secure connection is successfully established with the data source, the system vendor and version can be automatically identified according to the collection method of this disclosure. According to embodiments of this disclosure, the collection method can automatically identify the identity characteristics of the target system through metadata collection, and then compare the collected metadata feature vector with a system / version information database. After identification, the collection method automatically loads a predefined data parsing rule package corresponding to the vendor and version to implement subsequent collection processes.

[0042] Through the aforementioned automated identification and connection mechanism, this disclosure can quickly complete the detection, identification, and initial configuration of the access system. Compared with the traditional manual survey and configuration method, it can effectively improve efficiency and avoid the risk of data collection interruption caused by human configuration errors.

[0043] In process S1040, a corresponding collection strategy can be matched from the collection knowledge base based on manufacturer information and version information. The collection strategy may include a strategy identifier and data processing rules.

[0044] According to embodiments of this disclosure, matching a corresponding acquisition strategy from the acquisition knowledge base may include: applying the precisely matched acquisition strategy in response to the acquisition knowledge base including acquisition strategies that precisely match manufacturer information and version information; selecting the optimal acquisition strategy from the acquisition knowledge base based on a strategy matching algorithm in response to the acquisition knowledge base including acquisition strategies that similarly match manufacturer information and version information, and manually fine-tuning the optimal acquisition strategy to obtain a fine-tuned acquisition strategy; and manually configuring a new acquisition strategy in response to the acquisition knowledge base not including acquisition strategies that precisely match and similarly match manufacturer information and version information.

[0045] Specifically, after the automatic identification of the target system is completed, strategy matching is performed according to the collection method disclosed herein. Through multi-level query and intelligent comparison mechanisms, accurate matching and dynamic loading of collection strategies are achieved. This process is based on a collection knowledge base, which adopts a layered architecture design, including a knowledge base management center, a data processing strategy library, an implementation case library, and a system / version information library. It also supports efficient pattern matching and similarity retrieval. The data processing strategy library includes multiple collection strategies, each of which includes a strategy identifier and its corresponding data processing rules.

[0046] In one example, the data collection method encapsulates the metadata feature vectors (including vendor name, version number, database table structure features, etc.) identified in the previous stage into a structured query statement and sends it to the data processing strategy library for multi-dimensional reverse index query. The specific query mechanism includes: precise index matching: performing a hash lookup in the main index table of the data collection knowledge base based on the system's unique identifier (such as vendor name + version number). For example, querying the key value "vendor A_V4.0.2" can directly locate the corresponding strategy record; fuzzy pattern matching: if the precise index does not match, fuzzy matching is performed, such as calculating the similarity of system features. For example, when the system version is identified as "V4.0.3" (which does not yet exist in the data collection knowledge base), the platform calculates its feature similarity with the existing version "V4.0.2" (table structure similarity ≥ 95%, API path similarity ≥ 90%). If both exceed the preset threshold, it is determined to be a candidate similar strategy. If there is no matching strategy, it switches to manual configuration mode. After the expert configuration is completed, the new strategy is stored in the data collection knowledge base.

[0047] According to embodiments of this disclosure, in the case of similar strategy matching, selecting the optimal acquisition strategy based on the strategy matching algorithm may include recommending the optimal acquisition strategy based on vendor information and version information, as well as the data structure of the database corresponding to the vendor information and version information, and through similarity calculation.

[0048] In one example, when an exact match fails but candidate similar strategies exist (e.g., similarity ≥ 85%), the human-machine collaborative configuration mode is activated. Specifically, the system selects the closest similar strategies, sorts them by similarity, and recommends them to the visual configuration interface. It then automatically labels the differences (e.g., differences in database data structures) and provides a difference comparison analysis report. Operators can then fine-tune the mapping configuration for the differing content on the configuration interface and confirm the adjusted strategy. This fine-tuned strategy is stored in the knowledge base as a new version record, thus achieving incremental self-learning of the knowledge base. Additionally, in the absence of a matching strategy, i.e., when the query result is empty or the highest similarity is below a preset threshold (e.g., < 85%), the system switches to expert configuration mode. After expert configuration is completed, the new strategy is automatically stored in the knowledge base, completing the closed-loop update of the knowledge base.

[0049] Furthermore, the entire strategy matching and judgment process is recorded in the operation audit log, including the matching type (e.g., exact match, similar match, or no match), decision time, operator identity information, and strategy identifier, ensuring the traceability of the configuration process. Simultaneously, this data collection method employs a knowledge base version management mechanism, generating a new version for all strategy changes while retaining historical versions for rollback, thus guaranteeing system stability and maintainability.

[0050] Next, in process S1060, medical data can be collected from the medical system according to the collection strategy and standardized medical data can be output.

[0051] In one example, after matching and loading the acquisition strategy, the acquisition method extracts, transforms, and loads data according to preset rules. Specifically, based on the strategy configuration, the acquisition method extracts raw medical data from the connected source system, supporting both full-data acquisition and incremental acquisition modes. After acquisition, the raw medical data is intelligently transformed and standardized according to predefined data processing rules in the acquisition knowledge base, ensuring automatic mapping of heterogeneous data to a unified data model.

[0052] According to embodiments of this disclosure, data processing rules may include field mapping rules, data splicing and splitting rules, data format conversion rules, and data filtering rules.

[0053] Specifically, according to the field mapping rules, this collection method converts the original field names in the source system into the standard field names of the target data model. This mapping supports multiple modes such as one-to-one, one-to-many, many-to-one, and conditional mapping. This collection method splits and splices fields according to data splicing and splitting rules (such as regular expressions, delimiter rules). Scenarios for splitting fields can include: (1) Name field splitting: Split the value "Zhang San" of the "BRXM" field according to the characteristics of the first and last characters of the Chinese name. The first character "Zhang" is stored in last_name, and the remaining character "San" is stored in first_name; for the English name "JohnSmith", it is split by spaces and stored in first_name and last_name respectively; (2) Address field splitting: Split the "ADDRESS" field "Province AA, City BB, District CC, Road DD, No. EE" into province = "Province AA", city = "City BB", district = "District CC", and detail_address = "Road DD, No. EE"; (3) Test item result splitting: For the "LIS_JG" field "White blood cell count: 5.2×10 9 / L; Red blood cell count: 4.5×10 12 / L", it is parsed into structured item-result key-value pairs according to semicolons and colons as delimiters. The splitting success rate will be automatically recorded during the splitting process, and an exception alarm will be triggered if it is lower than the threshold. Scenarios for splicing fields can include: For example, splice the four fields PROVINCE (province), CITY (city), DISTRICT (district), and ADDRESS (detailed address) in the source system into a complete address string through the template {PROVINCE},{CITY},{DISTRICT},{ADDRESS}, automatically removing null values and adding delimiters. For the problem of inconsistent medical data formats, this collection method automatically converts various non-standard formats into formats that conform to international standards such as ISO 8601, ICD-10, and LOINC according to data format conversion rules. Typical conversions can include: (1) Date and time format conversion: Unify the conversion of the strings "20231001", "2023 / 10 / 01", and "01-OCT-2023" into the standard ISO date format "2023-10-01", and automatically identify and convert time zones; (2) Numerical unit conversion: Convert the test result "5.2×10 9 / L” is converted to standard scientific notation “5.2E9” and the UCUM unit code 10^9 / L is added; (3) Coding standardization: the gender codes, ethnic codes and drug codes of different manufacturers are converted to national standard codes (such as GB / T 2261.1) through mapping and comparison tables; (4) Text cleaning: HTML tags and special symbols are removed from unstructured text (such as chief complaint in medical records), full-width and half-width characters are unified, and entities (such as disease names and symptoms) are identified through natural language processing (NLP) models and standardized annotations are performed. All conversion operations are recorded in conversion logs, including the original value before conversion, the new value after conversion, and the application rule ID, which supports data traceability and quality audit. In addition, according to the actual situation, this collection method uses data filtering rules to find the data that needs to be processed by combining conditions and regular expression matching for diagnosis names and diagnosis codes, and saves it into the corresponding rules. It can be directly applied in other projects later. For example, the “lung cancer patient filtering rule” only retains the data of lung cancer patients.

[0054] In process S1080, policy identifiers, data processing rules, and collection logs corresponding to manufacturer information and version information can be recorded.

[0055] To ensure the data collection process is traceable and auditable, and to meet the compliance requirements of medical data governance, this collection method records the complete context information of the task execution in a structured manner for each collection task, including policy identifiers, data processing rules, and collection logs. All log records are appended with timestamps and execution IDs, and are asynchronously written to a log database or log file, supporting subsequent rapid retrieval and fault location using the execution ID.

[0056] Next, in process S1100, the acquisition logs can be analyzed to optimize the acquisition strategy, and the optimized acquisition strategy can be stored in the acquisition knowledge base. Specifically, optimizing the acquisition strategy may include: analyzing the acquisition logs to identify abnormal logs; generating optimization rules for abnormal logs; and updating the data processing rules based on the optimization rules.

[0057] To continuously improve the adaptability and accuracy of data collection, this collection method automatically analyzes collection logs, proactively identifies potential defects and generates optimization rules, realizes strategy iteration and self-evolution of the collection knowledge base, and forms a closed-loop feedback mechanism of "execution-analysis-optimization-update".

[0058] In one example, the types of anomalies in the collected logs can include structural anomalies, semantic anomalies, and performance anomalies. Structural anomalies typically refer to anomalies caused by changes in the source system's data structure, such as missing fields, type mismatches, and expanded encoding tables. Semantic anomalies typically refer to anomalies caused by misunderstandings of business logic, such as out-of-bounds value ranges, invalid relationships, and conflicting business rules. Performance anomalies typically refer to anomalies caused by increased data volume or network fluctuations, such as collection timeouts, increased failure rates, and excessive resource consumption.

[0059] According to embodiments of this disclosure, generating optimization rules for abnormal logs may include: analyzing the abnormal logs to generate multiple processing suggestions, the multiple processing suggestions including optimizing one or more rules in the data processing rules and adding one or more sub-rules to the rules; and manually reviewing and testing the multiple processing suggestions to select one processing suggestion from the multiple processing suggestions as the optimization rule.

[0060] To further improve the targeting and accuracy of strategy optimization, this data collection method performs root cause analysis and diagnosis on abnormal logs and generates actionable optimization suggestions. After manual confirmation, the strategy is updated incrementally.

[0061] In one example, when an abnormal increase in the average processing time of a data collection task was detected, all rule execution logs for that task were analyzed one by one. It was found that the "patient address intelligent splitting rule" failed to match complex addresses containing special symbols because the regular expression did not cover nested bracket scenarios, triggering abnormal retry logic and causing a surge in single-call time. After root cause identification, specific optimization suggestions for the root cause were automatically generated. Each suggestion included suggestion type, target rule ID, optimization scheme description, and expected effect evaluation. Taking the aforementioned address splitting rule as an example, the system automatically generated two suggestions: suggestion (a) rule logic optimization: revise the regular expression to optimize the original address splitting rule to support optional matching of bracket content; suggestion (b) abnormal handling sub-rule supplement: add an abnormal capture branch so that when address splitting fails, instead of triggering a global retry, the record is marked as "awaiting manual verification" and complex address parsing is skipped, directly retaining the original address string to avoid blocking subsequent data processing. The generated optimization suggestions can be submitted to the data quality engineer's workbench for review. Engineers can test suggestion (b) to compare the success rate and processing time of the old and new strategies when handling the same abnormal samples. After the test is passed, engineers can use a visual interface to extend the optimized sub-rule (b) as an extension of the original rule and define its activation conditions (e.g., only enabled when source_system="XX vendor" and version="V3.0"). The updated strategy is stored in the knowledge base as a new version (e.g., Rule_Address Splitting_V1.1), while the original rule version is retained as a historical version. At the same time, the "recommendation weight" parameter of the case that triggered this optimization is automatically increased in the case library, and future similar abnormal logs will be preferentially matched with the optimized rule generated by this case, forming a positive feedback loop.

[0062] Once the optimized data collection strategy is released, the method stores the new strategy in the data collection knowledge base. Subsequently, for data collection tasks on systems from the same vendor and with the same version, Rule_Address Splitting_V1.1 will be automatically loaded during the strategy matching phase, significantly improving execution efficiency and fault tolerance. Furthermore, the entire optimization process, from root cause analysis and suggestion generation to manual review and version release, is recorded in an immutable blockchain-like log (including operator information, timestamps, and changes), ensuring that any strategy changes are fully traceable and meeting the compliance audit requirements for medical data governance.

[0063] This application adopts the aforementioned intelligent strategy selection mechanism, which not only performs simple version matching, but also introduces multi-dimensional similarity calculation (vendor, version, data structure), and can recommend the closest and verified "strategy package". It also supports manual interactive fine-tuning, and the fine-tuning results can be fed back into the knowledge base.

[0064] Through the aforementioned closed-loop optimization mechanism, this application achieves adaptive optimization of the data collection strategy, enabling it to continuously improve itself as the source system data environment changes. This reduces the traditional manual maintenance cycle from several weeks to several hours, significantly lowers the long-term operating cost of the knowledge base, and improves the long-term stability and data quality of the system.

[0065] Figure 2 A second flowchart S200 of a multi-source heterogeneous medical data acquisition method based on an acquisition knowledge base according to an embodiment of the present disclosure is shown.

[0066] like Figure 2 As shown, the multi-source heterogeneous medical data acquisition method based on the acquisition knowledge base disclosed herein may further include the steps shown in process S2020. Specifically, process S2020 is executed after process S1060. In process S2020, effect evaluation and data quality verification can be performed.

[0067] According to embodiments of this disclosure, after collecting medical data and outputting standardized medical data, an effectiveness evaluation can be performed, and the collection logs can be analyzed based on the results of the effectiveness evaluation to optimize the collection strategy, wherein the effectiveness evaluation includes data quality evaluation and collection efficiency evaluation.

[0068] In one example, during the effectiveness evaluation phase, firstly, the data integrity rate of this collection task is calculated using the formula: the number of records actually successfully collected divided by the total number of records to be collected. For example, for the patient basic information table of the target HIS system, 100,000 records should be collected, and 98,500 records were successfully collected, resulting in a data integrity rate of 98.5%. Missing data is automatically recorded in an exception queue with specific reasons for the missing data (such as logical deletion of records in the source system, primary key conflicts, and failed validation), providing a basis for subsequent supplementary collection. Secondly, the field mapping accuracy is evaluated, calculated as: the number of correctly mapped field instances divided by the total number of mapped field instances. Through sampling comparison of the collection results (the sampling ratio can be configured from 1% to 5%) and automatic verification, it was found that in all field mapping operations, 99.2% of the field values ​​successfully completed semantic conversion and format standardization according to the field mapping rules, and the 0.8% error was mainly concentrated in special character encoding anomalies and edge value handling scenarios. In addition, the execution time is evaluated. Anomalies are identified by statistically comparing the total time taken for this data collection task (e.g., 45 minutes) with the time distribution of similar cases (i.e., historical tasks with the same system type, similar data size, and the same data collection mode) in the knowledge base. For example, if the average time for similar tasks is 30 minutes, and this task takes 1.5 times the average time, it is judged as a performance anomaly, triggering a performance analysis subprocess to pinpoint the efficiency bottleneck of the aforementioned "intelligent splitting rule for patient addresses".

[0069] According to another embodiment of this disclosure, a data quality check can be performed after medical data is collected, wherein, in response to the data quality check result meeting a predetermined standard, standardized medical data is output; and in response to the data quality check result not meeting the predetermined standard, a new collection strategy is selected, and medical data is collected according to the new collection strategy.

[0070] To ensure that the medical data output to the target system meets the requirements of completeness, accuracy, and business logic rationality for clinical and research use, the standardized data is verified for data quality before data output according to the data collection method disclosed herein, and a differentiated processing procedure is executed based on the verification results.

[0071] Specifically, automated verification of the collected data record by record and field by field can include: Integrity verification: verifying whether required fields (such as patient ID, visit serial number, and test request number) contain null or NULL values; verifying whether the total number of records matches the number extracted from the source system to prevent data loss due to network interruptions; verifying the uniqueness of primary keys to prevent duplicate records from being entered into the database; Consistency verification: verifying the logical consistency of cross-table relationships, such as ensuring that the patient_id in the test report must have a corresponding record in the patient's basic information table; verifying the consistency of coded value ranges, such as ensuring that the gender field value must be "M", "F", or "U"; verifying the consistency of content between multi-source data, such as whether the name and ID number of the same patient match in the HIS and EMR; Business logic rationality verification: verifying the rationality of the data according to medical industry business rules, such as ensuring that the patient's age field value should be between 0 and 150 years old; and ensuring that the test result values ​​are within the reference range of the corresponding test item (such as white blood cell count should be between 3.5 and 9.5 × 10⁻⁶). 9 / L); the appointment date must not be later than the current system date; the surgery start time must be earlier than the surgery end time. These rules are predefined in the knowledge base by medical business experts and can be customized according to the hospital.

[0072] If all verifications pass, a success log can be recorded. If verification fails, a tiered rollback, strategy adjustment, and retry are performed. If any verification fails, a tiered exception handling process is triggered based on the failure type and severity. Specifically, the exception handling process includes: Level 1: For non-critical errors (such as a single record with an abnormal format), the record is rolled back to a temporary isolation area, the reason for failure and the verification rule ID are marked, and subsequent records continue to be processed to avoid the entire batch of data failing. Isolated data automatically triggers an alarm notification to the data quality engineer, who can correct and re-enter the database or permanently discard it after manual confirmation; Level 2: If the error rate exceeds a preset threshold (such as 5%) or the error type points to a flaw in the strategy logic (such as a regular expression not covering the new encoding), all data in the current batch is rolled back, and the strategy optimization process is initiated. Specifically, rule patches are generated for failed samples, and the data quality engineer submits the optimized collection strategy after reviewing the patches, without restarting the collection task; Level 3: Task termination and global strategy rollback. If multiple retries fail, or if an error points to a flaw in the underlying knowledge base (such as a missing field mapping dictionary), the current task will be terminated, and the relevant data processing strategy will be globally rolled back to the previous stable version to prevent systemic data pollution. Simultaneously, a fault report will be generated and submitted to the system administrator and the knowledge base maintenance team for root cause investigation.

[0073] Through the above-mentioned hierarchical processing mechanism, this invention achieves closed-loop management of data quality issues, ensuring the quality of core data while maximizing the fault tolerance and self-healing ability of the data collection process and significantly reducing the frequency of manual intervention.

[0074] Figure 3 A schematic diagram of a knowledge base acquired according to an embodiment of the present disclosure is shown.

[0075] like Figure 3 As shown, the knowledge base uses a relational data model for structured storage, with each strategy record corresponding to a complete collection specification for a specific medical information system under a specific business scenario. The core field design of the knowledge base enables parameterized configuration of the entire process from source system query construction to target table mapping, achieving rapid adaptation to heterogeneous systems without hard coding.

[0076] The core fields of the collected knowledge base are described as follows:

[0077] Query condition (SELECT statement) field: Stores predefined SQL templates for data extraction, using a parameterized placeholder mechanism. For example... Figure 3 The example shows that inpatient information queries from different vendors' systems (such as vendors A, B, and C) need to map different source fields. The knowledge base achieves fine-grained isolation of the strategy by independently storing these differences.

[0078] The WHERE clause field stores the expression template for data filtering logic, supporting multiple condition combinations and nested logical operators. This field not only includes regular equality judgments (such as ZAIYUANZT="0" indicating in-hospital status), but also supports complex business rules, such as "remove cancelled inpatients" and "exclude test data".

[0079] The fields for applicable manufacturer, applicable version, and applicable database type form the hierarchical index keys, constituting the three-dimensional positioning coordinates of the knowledge base. This design supports both exact matching and range matching of policies (e.g., the applicable version field supports wildcards "4.0.*"). When a new system version is detected, the platform prioritizes searching for the exact version policy. If no match is found, it searches upwards for the nearest parent version policy, achieving automatic downgrade processing for version compatibility.

[0080] The "In-Hospital / Out-of-Hospital" field serves as a business context label, supporting differentiated data collection under different business states within the same system. For example, patient transfer status (in-hospital, expected discharge, discharged) involves different data permissions and query views. The knowledge base uses this label to implement strategy branches, ensuring that the collection logic aligns with actual business processes.

[0081] Target table field: Defines the destination of the standardized data, such as b02_1 (medical institution information table). This field is linked to the field mapping rules to ensure that heterogeneous source data is uniformly collected into the standard data model.

[0082] Field mapping rules: Stores mandatory mapping validation rules, requiring all SELECT clauses to explicitly specify the target field name using the AS keyword, eliminating the risk of field misalignment caused by implicit mapping. This design forces developers to explicitly declare semantic correspondences when configuring strategies, improving strategy readability and maintainability.

[0083] Already combined Figure 3 This paper describes the construction and application of a structured and evolvable knowledge base. Existing technologies often employ static adapters or template libraries, while this application divides the knowledge base into multiple levels, including system information, processing strategies, mapping rules, filtering rules, and implementation cases. These levels can reference each other, and all content can be continuously optimized through execution feedback. Furthermore, it collects and stores basic information, data formats, field definitions, and processing rules from various medical information systems, forming a structured knowledge base. The knowledge base includes system vendors, versions, data table structures, field mapping relationships, and common conversion rules (such as date formats and code conversions).

[0084] Figure 4 A schematic diagram of a multi-source heterogeneous medical data acquisition platform constructed according to an embodiment of the present disclosure is shown.

[0085] The data acquisition platform is a software system for automating and standardizing medical data collection. It collects, stores, and reports data from various hospital systems for subsequent processing. Its core purpose is to solve problems such as difficult and low-quality data collection caused by inconsistent information systems and disorganized data formats across hospitals. It operates through a pre-built "data acquisition knowledge base." This knowledge base acts like a vast "rule dictionary," recording the data characteristics of different vendors and versions of hospital software systems, such as basic metadata, field name mappings, data format conversion rules, and data concatenation or splitting rules.

[0086] like Figure 4 As shown, the multi-source heterogeneous big data intelligent acquisition platform adopts a layered modular architecture, which includes: data acquisition and processing, connector management, multi-source heterogeneous data sources and acquisition knowledge base. The interaction between each layer is realized through standardized interfaces to achieve data and control.

[0087] The knowledge base systematically transforms scattered, implicit implementation experience into explicit, reusable digital assets, thereby driving the intelligent upgrade of the entire data acquisition platform. The knowledge base includes a knowledge base management center, a data processing strategy library, an implementation case library, and a system / version information library. The knowledge base management center enables unified control, version evolution, and audit trail management of strategies, rules, and cases. The data processing strategy library stores sets of rules for data transformation, cleaning, and verification, such as date formatting functions, encoding mapping tables, and outlier handling scripts. The implementation case library accumulates execution logs and problem cases from historical data acquisition tasks, with each case annotated with a problem description, root cause analysis, optimization plan, and effectiveness evaluation. The system / version information library maintains an identity fingerprint database for the medical information system, recording metadata characteristics of various vendors and system versions.

[0088] The data collection method described above according to embodiments of this disclosure may include: storing vendor information and version information, along with a finely tuned collection strategy corresponding to the vendor information and version information, as first supplementary cases in an implementation case library; and storing vendor information and version information, along with a new collection strategy corresponding to the vendor information and version information, as second supplementary cases in the implementation case library. Furthermore, matching the corresponding collection strategy from the collection knowledge base may include automatically recommending a collection strategy or generating a new collection strategy based on historical cases in the implementation case library using a machine learning model.

[0089] By implementing the aforementioned optimization and update mechanisms for the case library, rich historical practical experience can be continuously accumulated, forming knowledge assets covering multiple vendors, versions, and strategy types. These historical cases not only record the configuration parameters of the strategy itself, but also include metadata information such as the applicable context, execution effect evaluation data, and optimization iteration trajectory.

[0090] In the process of matching corresponding acquisition strategies from the knowledge base, machine learning models can be used to perform deep learning and pattern mining on historical cases in the implementation case library. This machine learning model can construct a strategy recommendation model or a strategy generation model based on multi-dimensional information such as vendor characteristics, version characteristics, database data structure characteristics, and strategy execution effects from historical cases.

[0091] For example, when the system identifies the device to be collected as "Manufacturer A" and "V3.0", the machine learning model can retrieve similar historical cases from the implementation case library and automatically recommend collection strategies that have been verified to be effective for devices of the same manufacturer and version. If there are no completely matching cases in the implementation case library, the model can perform transfer learning based on historical cases of similar manufacturers (such as Manufacturer D) or similar versions to generate new collection strategies suitable for the current device.

[0092] Alternatively, if the historical case library already contains multiple versions of the collection strategy for this series, the machine learning model can automatically generate a collection strategy suitable for the new version based on the analysis of each version, or recommend optimization directions based on the existing strategy for fine-tuning.

[0093] In addition, machine learning models can also combine feedback data after policy execution (such as collection success rate, time consumption, resource consumption, etc.) for continuous reinforcement learning, continuously optimize the accuracy of policy recommendation and generation, and realize the self-evolution and capability improvement of the knowledge base.

[0094] Data acquisition and processing refers to extracting raw data from data sources, performing operations such as field mapping, concatenation, splitting, and format conversion, monitoring the processing in real time, recording errors and warnings, and storing the result data in the target database. Data acquisition and processing involves acquisition tasks, acquisition jobs, data management, data review, data quality control, and data reporting. Upon receiving an acquisition task, the acquisition job begins. Data management provides data retrieval and download capabilities. Data review is for hospital data administrators and supports manual review, correction, or disposal of abnormal data. Data quality control includes generating a data quality assessment report, which includes indicators such as completeness, accuracy, and consistency. Data reporting refers to automatically packaging and reporting data according to the data format required by the regulatory platform, such as generating a national medical quality and safety improvement target data package.

[0095] Connector management manages various types of connectors and provides a unified connection interface to the upper layer. Connector management allows for the addition, deletion, and modification of connectors through visual configuration. Defined connectors can be referenced in the data acquisition module for data reading. Connectors support various data sources, including but not limited to HIS, EMRS, LIS, PACS, and manual data sources. Connectors can include, but are not limited to: JDBC connectors, supporting standard SQL queries for relational databases (such as Oracle, SQL Server, and MySQL); HTTP connectors, supporting RESTful API, SOAP WebService, and HL7 FHIR interface calls, with built-in authentication and rate limiting mechanisms; message connectors, connecting to message queues such as Kafka and RabbitMQ to achieve event-driven real-time data acquisition; file connectors, supporting file reading and parsing in FTP / SFTP and SMB / NFS shared directories; and custom connectors, providing plug-in development interfaces that allow extension of special protocols via Java / Python scripts. Each connector registers its capability descriptions (such as support for incremental mode and maximum concurrency) in the knowledge base. Acquisition strategies are configured protocol-independently by referencing the connector ID. When adding a new data source type, only the connector plugin needs to be developed; no modification to the platform's core code is required.

[0096] Based on the multi-source heterogeneous medical data acquisition method disclosed herein, a multi-level, associative, and traceable acquisition knowledge base-based intelligent big data acquisition platform is constructed. This platform enables a complete closed-loop process from automatic identification, intelligent matching, execution acquisition, effect evaluation, to knowledge base optimization. By collecting various information such as vendors, versions, storage methods, and storage formats of common medical information systems, an acquisition knowledge base is formed. During hospital implementation, the platform automatically selects acquisition strategies based on the actual system vendors and versions used, achieving automation and standardization of data acquisition, thereby improving efficiency, reducing manual intervention, and ensuring data quality.

[0097] Figure 5 A flowchart illustrating the acquisition process of multi-source heterogeneous medical data according to an embodiment of the present disclosure is shown.

[0098] like Figure 5 As shown, the complete data acquisition process of the acquisition platform is as follows:

[0099] First, initiate the data collection task for the hospital system.

[0100] Phase 1: System Identification and Connection

[0101] 1. Connect to the target data source: The data acquisition platform establishes a secure connection with the hospital's HIS, EMRS, LIS and other systems, supporting multiple methods such as direct database connection, API interface, and file transfer.

[0102] 2. Automatic system identification: Automatically detects system vendors and versions through metadata analysis, such as identifying "vendor A, V4.0".

[0103] Phase Two: Strategy Matching and Loading

[0104] 3. Query and collect knowledge base: Send the identified system information to the knowledge base for query, and search for the corresponding collection strategy in the rule base.

[0105] 4. Strategy matching judgment: Case A: If an exact matching strategy is found, the preset field mapping and processing rules are directly loaded, and the automated processing flow is entered; Case B: If a similar strategy is found, the closest existing strategy is recommended for comparison, and manual fine-tuning is allowed before use; Case C: If no matching strategy is found, the system switches to manual configuration mode. After expert configuration, the new strategy is stored in the knowledge base.

[0106] Phase 3: Data Acquisition and Processing

[0107] 5. Perform data collection: Extract raw data from the source system according to the strategy, supporting full collection and incremental collection.

[0108] 6. Apply rules and perform automated data processing: the core application of the knowledge base.

[0109] Field mapping: Convert field names according to knowledge base rules, e.g., patient ID → patient_id;

[0110] Data splitting: Decompose composite fields according to rules, for example, split a name into a surname and a given name.

[0111] Data concatenation: merging multiple fields, e.g., concatenating province + city + district + detailed address into a complete address.

[0112] Format conversion: unify data format, e.g., date format 20231001 → 2023-10-01

[0113] Phase 4: Quality Verification and Output

[0114] 7. Performance Evaluation and Data Quality Verification: After data processing is complete, a performance evaluation is performed. This includes calculating the "data integrity rate," "field mapping accuracy rate," and "execution time" for this task, and checking data integrity and consistency to verify key business logic. If verification is successful, standardized data is output and a success log is recorded. If verification fails, the data is rolled back, the strategy is adjusted, and the data is reprocessed.

[0115] 8. Output standardized data:

[0116] The processed, standardized data is then output to the target system, such as the MySQL database.

[0117] Phase 5: Value feedback after the process ends

[0118] 9. Analyze logs and optimize collection strategies: Collect logs and effect data from this process, optimize existing strategy rules, and store new success cases in the knowledge base to form a virtuous cycle of "becoming smarter the more it is used".

[0119] Figure 5 The data collection process clearly demonstrates how the knowledge base can transform from "passive storage" to "active driving," becoming the core engine for the intelligent transformation of the entire data collection platform.

[0120] In one example, in a hospital's actual deployment application, the data collection platform implemented according to the data collection method disclosed herein successfully connected to multiple heterogeneous data sources, shortening the service deployment cycle by 90%, reducing the average development cycle of data collection tasks by about 70%, and significantly improving the system's scalability and maintainability.

[0121] The data collection method according to the embodiments of this disclosure has closed-loop learning and adaptive capabilities, and it innovatively designs a strategy execution effect evaluation and knowledge base closed-loop evolution mode. By quantitatively analyzing the success rate and data quality of the data collection tasks, it automatically discovers rule defects, generates optimization suggestions, and updates the knowledge base after a process-oriented review, enabling the platform to have continuous self-improvement capabilities.

[0122] Figure 6 A structural diagram of a multi-source heterogeneous medical data acquisition device according to an embodiment of the present disclosure is shown.

[0123] See Figure 6 The multi-source heterogeneous medical data acquisition device 600 may include a processor 6020 and a memory 6040. Both the processor 6020 and the memory 6040 can be connected via a bus 6030. The multi-source heterogeneous medical data acquisition device 600 can be any type of portable device (such as a smart camera, smartphone, tablet, etc.) or any type of fixed device (such as a desktop computer, server, etc.).

[0124] Processor 6020 can perform various actions and processes according to the program stored in memory 6040. Specifically, processor 6020 can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), off-the-shelf programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor, and can be based on x86 architecture or ARM architecture.

[0125] Memory 6040 stores computer-executable instructions that, when executed by processor 6020, implement the aforementioned multi-source heterogeneous medical data acquisition method based on an acquisition knowledge base. Memory 6040 can be volatile memory or non-volatile memory, or may include both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct memory bus random access memory (DR RAM). It should be noted that the memory of the methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0126] Furthermore, embodiments of this disclosure can also be implemented as a computer-readable storage medium. A computer-readable storage medium according to embodiments of this disclosure stores computer-readable instructions. When executed by a processor, the computer-readable instructions can perform the multi-source heterogeneous medical data acquisition method based on an acquisition knowledge base according to various embodiments of this disclosure, as described with reference to the above figures. The computer-readable storage medium includes, but is not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc.

[0127] According to embodiments of this disclosure, a computer program product or computer program is also provided, which includes computer-readable instructions stored in a computer-readable storage medium. A processor of a computer device can read the computer-readable instructions from the computer-readable storage medium and execute the instructions, causing the computer device to perform the multi-source heterogeneous medical data acquisition method based on a knowledge base described in the various embodiments above.

[0128] The program portion of a technology can be considered a "product" or "artifact" existing in the form of executable code and / or related data, and is involved in or implemented through a computer-readable medium. Tangible, permanent storage media can include memory or storage used by any computer, processor, or similar device or related module. For example, various semiconductor memories, tape drives, disk drives, or any similar device capable of providing storage functionality for software.

[0129] All software, or parts thereof, may sometimes communicate via networks, such as the Internet or other communication networks. Such communication can load software from one computer device or processor to another. For example, loading software from a server or host computer on a device to a hardware platform of a computer environment, or another computer environment that implements the system, or a system with similar functionality related to providing the required information. Therefore, another medium capable of transmitting software elements can also be used as a physical connection between local devices, such as light waves, radio waves, electromagnetic waves, etc., propagated through cables, fiber optic cables, or air. Physical media used for carrier waves, such as cables, wireless connections, or fiber optic cables, can also be considered as media carrying software. In this context, unless limited to tangible "storage" media, the term "readable medium" for a computer or machine refers to the medium involved in the execution of any instructions by the processor.

[0130] It should be noted that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing at least one executable instruction for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0131] In general, the various exemplary embodiments of this disclosure can be implemented in hardware or dedicated circuitry, software, firmware, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device. When aspects of embodiments of this disclosure are illustrated or described as block diagrams, flowcharts, or represented using some other images, it will be understood that the blocks, apparatuses, systems, techniques, or methods described herein can be implemented as non-limiting examples in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0132] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It should also be understood that terms such as those defined in a common dictionary shall be interpreted as having a meaning consistent with their meaning in the context of the relevant art, and not as having an idealized or highly formalized meaning, unless expressly defined herein.

[0133] The foregoing description is intended to illustrate the present disclosure and should not be construed as limiting it. While several exemplary embodiments of the present disclosure have been described, those skilled in the art will readily understand that many modifications may be made to the exemplary embodiments without departing from the novel teachings and advantages of the present disclosure. Therefore, all such modifications are intended to be included within the scope of the present disclosure as defined by the claims. It should be understood that the foregoing description is intended to illustrate the present disclosure and should not be construed as limiting it to the specific embodiments disclosed, and modifications to the disclosed embodiments and other embodiments are intended to be included within the scope of the appended claims. The present disclosure is defined by the claims and their equivalents.

Claims

1. A method for acquiring multi-source heterogeneous medical data based on a knowledge base, the method comprising: Identify the manufacturer and version information of the medical system; Based on the manufacturer information and the version information, a corresponding collection strategy is matched from the collection knowledge base, wherein the collection strategy includes a strategy identifier and data processing rules; Medical data is collected from the medical system according to the acquisition strategy, and standardized medical data is output. Record the policy identifier, data processing rules, and collection logs corresponding to the manufacturer information and the version information; as well as The data collection logs are analyzed to optimize the data collection strategy, and the optimized strategy is stored in the data collection knowledge base. Optimizing the acquisition strategy includes: The collected logs are analyzed to identify abnormal logs; The optimization rules for generating the aforementioned exception logs; and The data processing rules are updated based on the optimization rules.

2. The method according to claim 1, wherein, The optimization rules for generating the aforementioned exception logs include: The anomaly logs are analyzed to generate multiple processing suggestions, including optimizing one or more rules in the data processing rules and adding sub-rules to the one or more rules; and The multiple processing suggestions are manually reviewed and tested to select one processing suggestion as the optimization rule.

3. The method according to claim 1, wherein, Matching the corresponding collection strategy from the knowledge base includes: In response to the collection knowledge base including a collection strategy that precisely matches the manufacturer information and the version information, the precisely matched collection strategy is applied; In response to the knowledge base containing collection strategies that are similar to and match the vendor information and version information, an optimal collection strategy is selected from the knowledge base based on a strategy matching algorithm, and the optimal collection strategy is manually fine-tuned to obtain a fine-tuned collection strategy; and In response to the fact that the knowledge base does not contain collection strategies that precisely match or closely match the manufacturer information and the version information, a new collection strategy is manually configured.

4. The method according to claim 3, wherein, The optimal acquisition strategy is selected based on the strategy matching algorithm, which includes recommending the optimal acquisition strategy based on the manufacturer information, the version information, and the data structure of the database corresponding to the manufacturer information and the version information, and through similarity calculation.

5. The method according to claim 4, wherein, The knowledge base for data collection includes a case library, and the method further includes: The vendor information, the version information, and the fine-tuned acquisition strategy corresponding to the vendor information and the version information are stored as first supplementary cases in the case library, and The manufacturer information, the version information, and the new acquisition strategy corresponding to the manufacturer information and the version information are stored as a second supplementary case in the case library.

6. The method according to claim 1, wherein, The knowledge base includes a case library, and matching the corresponding collection strategy from the knowledge base includes using a machine learning model to automatically recommend the collection strategy or generate a new collection strategy based on historical cases in the case library.

7. The method according to claim 1 further includes performing an effectiveness evaluation after collecting medical data and outputting standardized medical data, and analyzing the collection logs based on the results of the effectiveness evaluation to optimize the collection strategy, wherein the effectiveness evaluation includes data quality evaluation and collection efficiency evaluation.

8. The method according to claim 1, further comprising performing data quality verification after collecting the medical data, wherein: In response to the data quality verification result meeting the predetermined standard, the standardized medical data is output; as well as If the data quality verification result does not meet the predetermined standard, the acquisition strategy is reselected, and the medical data is acquired according to the reselected acquisition strategy.

9. The method according to claim 1, wherein, The data processing rules include field mapping rules, data splicing and splitting rules, data format conversion rules, and data filtering rules.

10. The method according to claim 1, wherein, The multi-source heterogeneous medical data includes medical data from multiple data sources, including hospital information systems, electronic medical record systems, laboratory information systems, image archiving and communication systems, surgical anesthesia systems, pathology systems, and ICU monitoring systems.

11. A multi-source heterogeneous medical data acquisition device, the device comprising: Memory, which stores computer program instructions; as well as A processor, coupled to the memory, is configured to execute the computer program instructions to implement the method according to any one of claims 1 to 10.

12. A computer-readable storage medium, wherein, The computer-readable storage medium stores computer-readable instructions that, when executed by a processor, implement the method according to any one of claims 1 to 10.

13. A computer program product comprising computer-readable instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 10.

Images