A community medical-oriented multi-source heterogeneous data integration and intelligent quality control system and method

By integrating multi-source heterogeneous data and implementing intelligent quality control system for community healthcare, the problem of data quality control schemes in community healthcare being unable to adapt to the practical needs of primary care has been solved. Flexible quality control rules and incomplete data processing have been achieved, meeting the clinical needs of primary healthcare workers.

CN122245818APending Publication Date: 2026-06-19BEIJING INFINITY VIDEO TECHNOLOGY CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
BEIJING INFINITY VIDEO TECHNOLOGY CO LTD
Filing Date
2026-03-23
Publication Date
2026-06-19

AI Technical Summary

Technical Problem

In community healthcare, quality control solutions for multi-source heterogeneous data cannot meet the practical needs of primary care, lacking a flexible quality control rule system and the ability to adaptively process incomplete data. Furthermore, existing technologies have not been adapted to the clinical needs of primary care medical staff.

Method used

A multi-source heterogeneous data integration and intelligent quality control system for community healthcare was designed, including an intelligent data acquisition and adaptation unit, an asynchronous high-performance execution unit, a configurable rule quality control unit, and an integrated data display unit. Through multi-mode data capture, session reuse, parallel task scheduling, intelligent fault-tolerant retry, configurable rule quality control, and panoramic health view display, the system achieves external loading of quality control rules and adaptive handling of missing data.

Benefits of technology

A configurable rule-based quality control unit was constructed, enabling flexible adjustment of medical quality control rules, adapting to the efficient acquisition and visualization of community medical data, meeting the needs of primary-level quality control and incomplete data, and adapting to the real-time data acquisition and visualization support of small heterogeneous community medical systems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122245818A_ABST
    Figure CN122245818A_ABST
Patent Text Reader

Abstract

This invention relates to the field of medical information management technology, specifically to a multi-source heterogeneous data integration and intelligent quality control system and method for community healthcare. It includes: an intelligent data acquisition and adaptation unit; an asynchronous high-performance execution unit; a configurable rule-based quality control unit; and an integrated data display unit. This invention constructs a dependency graph between quality control rules and underlying data fields, as well as a field missing status mapping index. Addressing the scenario where community healthcare data is prone to missing information, it can retrieve missing data points and encode the reasons for the missing information. It calculates a data integrity score through a data incompleteness assessment model, dynamically switches quality control execution strategies based on the score, performs quality control analysis on incomplete data, and generates polymorphic quality control metadata containing quality control judgment results, missing reason codes, and confidence labels, which is then marked onto the original data. This forms a standardized, independently executable quality control system that meets the needs of routine quality control and incomplete data quality control in community healthcare.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of medical information management technology, and more specifically, to a multi-source heterogeneous data integration and intelligent quality control system and method for community healthcare. Background Technology

[0002] In community healthcare settings, patient health data is scattered across multiple heterogeneous platforms, including hospital information systems and public health systems. These systems exhibit significant differences in interface protocols, encryption methods, and security strategies, creating data silos. Healthcare professionals must manually integrate data across systems and rely on experience for quality control, resulting in low data acquisition efficiency and inconsistent quality control standards. This has become a core technological bottleneck in community healthcare management.

[0003] In the prior art, relevant patents regarding the processing and quality control of multi-source heterogeneous medical data have been disclosed. For example, invention patent CN202510963883.4 discloses a method for real-time processing and quality control of medical data sources based on distributed computing. This method includes acquiring and classifying multi-source heterogeneous medical data streams, constructing a distributed parallel processing framework, setting initial constraints, executing distributed streaming computing to generate a preliminary processing strategy, and then using a federated learning algorithm to optimize and generate a globally consistent processing strategy. This invention can efficiently process multi-source heterogeneous medical data, achieving real-time computing through a multi-dimensional processing space and dynamic task allocation, and utilizing a federated learning optimization strategy to ensure data quality and privacy. For example, invention patent CN202511712174.5 discloses a medical multi-source heterogeneous data fusion and knowledge discovery system based on deep learning, including a heterogeneous data management and mapping module, a unified medical data representation module, a medical knowledge mining engine, a knowledge-driven decision support module, and a hypothesis verification and visualization exploration module. This invention effectively solves the technical problems of difficulty in fusion of medical multi-source heterogeneous data, difficulty in mining complex relationships, and insufficient accuracy of knowledge representation, and significantly improves data utilization efficiency, representation quality, and diagnostic accuracy.

[0004] Despite the design advantages of the above technical solutions, they also have the following technical defects: First, the quality control solutions cannot adapt to the practical needs of community healthcare, lacking a flexible quality control rule system and adaptive processing capabilities for incomplete data. For example, the quality control rules in invention patent CN202510963883.4 are fixed in the algorithm logic of distributed computing and federated learning, making it impossible to flexibly adjust according to the specific quality control standards for community healthcare, nor does it design retrieval, evaluation, and strategy adaptation processing logic for scenarios where community healthcare data is prone to loss. Furthermore, invention patent CN202511712174.5 does not construct an independent quality control system; the quality control process is only attached to the data fusion and knowledge mining process, lacking a standardized quality control execution process, and thus failing to meet the core needs of routine quality control and incomplete data quality control in community healthcare. Secondly, existing technologies lack lightweight adaptations for community healthcare and are out of touch with the clinical needs of primary care healthcare workers: The distributed parallel processing framework in invention patent CN202510963883.4 is adapted to the massive data processing of large medical institutions, but lacks a dedicated data acquisition adaptation solution for small and medium-sized heterogeneous systems in community healthcare, making it difficult to meet the real-time requirements of primary care clinical data acquisition; Invention patent CN202511712174.5 focuses on deep learning-driven precision diagnosis, failing to achieve integrated visualization of patient basic health data and quality control results, thus failing to meet the usage needs of community healthcare workers for daily health management, follow-up, and other basic tasks. Therefore, we propose a multi-source heterogeneous data integration and intelligent quality control system and method for community healthcare. Summary of the Invention

[0005] The purpose of this invention is to provide a multi-source heterogeneous data integration and intelligent quality control system and method for community healthcare, in order to solve the problems that the quality control schemes proposed in the background art cannot adapt to the practical needs of community healthcare, lack a flexible quality control rule system and the ability to adaptively process incomplete data, and that the existing technology has not been adapted to community healthcare in a lightweight way, thus being out of touch with the clinical needs of primary healthcare workers.

[0006] To address the aforementioned technical problems, one objective of this invention is to provide a multi-source heterogeneous data integration and intelligent quality control system for community healthcare, comprising: The intelligent data acquisition and adaptation unit is used to connect with hospital information systems, public health systems and heterogeneous medical business systems in community medical scenarios, complete the universal automatic login adaptation of each heterogeneous medical business system, and collect patient medical data through multi-mode data capture methods. An asynchronous high-performance execution unit provides execution support for the patient medical data acquisition process of the intelligent data acquisition adaptation unit and the patient medical data quality control process of the configurable rule quality control unit. It uses session reuse, parallel task scheduling and intelligent fault-tolerant retry technology to perform data processing-related operations. A configurable rule-based quality control unit performs quality control on patient medical data collected by the intelligent data acquisition and adaptation unit. It loads externally configured medical quality control rules, constructs a dependency graph between the quality control rules and underlying data fields, and configures a mapping index between field missing states and rule execution logic. The unit performs standardized preprocessing on the patient medical data collected by the intelligent data acquisition and adaptation unit, matches it with corresponding medical quality control standards for quality control comparison, and when missing target field data causes quality control comparison failure, it traverses the dependency graph to retrieve missing data links, encoding the cause of the missing data as not collected, not synchronized, unparseable, or pending confirmation. It calculates the integrity score of the input patient medical data using a data incompleteness assessment model trained based on a missing sample library, dynamically switches the quality control execution strategy according to a preset integrity score threshold, downgrades the comparison logic to trend analysis logic, and performs quality control analysis. It generates polymorphic quality control metadata containing quality control judgment results, missing cause type codes, and confidence labels, and marks this polymorphic quality control metadata into the original patient medical data. The integrated data display unit provides medical staff with visualization services for patient health data and quality control results. It aggregates the full-dimensional medical data of patients collected by the intelligent data acquisition and adaptation unit and the polymorphic quality control metadata generated by the configurable rule quality control unit to construct a panoramic health view of patients.

[0007] As a further improvement to this technical solution, the intelligent data acquisition and adaptation unit includes a login agent module and a data capture and parsing module, wherein: The login agent module is used to connect with various heterogeneous medical business systems in the community medical scenario, adaptively identify the encryption method of the target system, automatically identify the login verification code and complete fully automatic unattended login. The data capture and parsing module adopts a multi-mode data capture method to locate, extract, and collect patient medical data for heterogeneous medical business systems with different interface forms.

[0008] As a further improvement to this technical solution, the asynchronous high-performance execution unit includes a session cache management module, a concurrent task scheduling module, and an intelligent retry module, wherein: The session cache management module is used to manage valid session information after login and reuse sessions that are within their validity period to avoid the performance overhead caused by repeated logins. The concurrent task scheduling module is used to create a multi-threaded execution environment and schedule multiple data acquisition and processing tasks in parallel to improve data processing efficiency. The intelligent retry module is used to execute intelligent retry strategies when network requests encounter abnormalities, thereby avoiding interruptions in the data processing flow caused by network fluctuations.

[0009] As a further improvement to this technical solution, the configurable rule quality control unit includes a rule configuration loading module, a data preprocessing module, an incomplete adaptive quality control execution module, and a polymorphic metadata generation and tagging module, wherein: The rule configuration loading module loads the externally configured medical quality control rules, constructs a dependency graph between the quality control rules and the underlying data fields, and configures a mapping index between the field missing status and the rule execution logic. The data preprocessing module performs standardized preprocessing operations on the patient medical data collected by the intelligent data acquisition and adaptation unit. The incomplete adaptive quality control execution module relies on preprocessed patient medical data and loaded medical quality control rules to complete quality control comparison, data missing link retrieval, and dynamic switching of quality control execution strategies; The polymorphic metadata generation and tagging module generates polymorphic quality control metadata and associates and tags this polymorphic quality control metadata with the original patient medical data.

[0010] As a further improvement to this technical solution, the rule configuration loading module includes a rule externalization loading submodule, a dependency graph construction submodule, and a missing mapping index configuration submodule, wherein: The rule externalization loading submodule reads and parses the preset externalized medical quality control rules to form a standardized set of quality control rules; The dependency graph construction submodule constructs a directed dependency graph between quality control rules and underlying data fields, establishing a unique association link between quality control rules and data fields; The missing mapping index configuration submodule configures a one-to-one mapping index between the field missing status and the rule execution logic, and explicitly limits the field missing status to types such as not collected, not synchronized, unparseable or pending confirmation, so as to provide accurate matching basis for quality control execution in the case of data missing.

[0011] As a further improvement to this technical solution, the standardized preprocessing operation process of the data preprocessing module includes the following steps: S32.1 Extract the 18-digit ID number from the patient's medical data collected by the intelligent data acquisition and adaptation unit, and parse the corresponding field of the ID number to obtain the patient's date of birth; S32.2 Calculate the patient's age based on the patient's birth date obtained from the analysis. ; S32.3. Standardize the formats of numerical, date, and text data in patient medical data to achieve standardization and uniformity of patient medical data.

[0012] As a further improvement to this technical solution, the quality control comparison and dynamic strategy switching process of the incomplete adaptive quality control execution module includes the following steps: S33.1 Patient age obtained from the data preprocessing module From the standardized quality control rule set of the rule configuration loading module, match the medical quality control standards that are suitable for the patient's age; S33.2 Extract the fields related to the target quality control rules from the preprocessed patient medical data, perform quality control comparison, and if the comparison fails due to missing data in the target field, traverse the directed dependency graph constructed by the rule configuration loading module, retrieve the missing data links, and complete the missing reason coding. S33.3 Calculate the integrity score of patient medical data using a data incompleteness assessment model. ; S33.4. Based on the preset integrity scoring threshold, compare the integrity scores. The quality control execution strategy is dynamically switched according to the threshold value; if the completeness is insufficient, the regular comparison logic is downgraded to trend analysis logic, and the trend prediction value is used to predict the value. Complete the quality control analysis.

[0013] As a further improvement to this technical solution, the polymorphic quality control metadata generation and marking process of the polymorphic metadata generation and marking module includes the following steps: S34.1 Quality control judgment results, missing cause codes, and integrity scores based on the output of the incomplete adaptive quality control execution module. The confidence level of the quality control judgment result is calculated. ; S34.2, Integrate quality control judgment results, missing cause codes, and confidence levels. And generate timestamps to construct polymorphic quality control metadata; S34.3 Associate the generated polymorphic quality control metadata with the tags and labels in the original patient medical data collected by the intelligent data acquisition adapter unit.

[0014] As a further improvement to this technical solution, the integrated data display unit includes a data aggregation module, a view construction module, and a visualization display module, wherein: The data aggregation module connects to the intelligent data acquisition and adaptation unit and the configurable rule quality control unit, aggregating the patient's full-dimensional medical data and polymorphic quality control metadata. The view construction module constructs a panoramic health view of patients based on aggregated full-dimensional medical data and polymorphic quality control metadata. The visualization module provides medical staff with visualization services for patient health data and quality control results based on a panoramic view of the patient's health.

[0015] The second objective of this invention is to provide a method for multi-source heterogeneous data integration and intelligent quality control in community healthcare, based on the aforementioned multi-source heterogeneous data integration and intelligent quality control system for community healthcare, comprising the following steps: S1. Connects with hospital information systems, public health systems, and heterogeneous medical business systems in community healthcare scenarios, and completes universal automatic login adaptation for various heterogeneous medical business systems. It adaptively identifies the encryption method of the target system, automatically identifies the login verification code, and completes fully automatic unattended login. It adopts a multi-mode data capture method to locate, extract, and collect patient medical data for heterogeneous medical business systems with different interface forms. S2 provides execution support for the patient medical data collection process and the patient medical data quality control process, manages valid session information after login, reuses sessions within the validity period, creates a multi-threaded execution environment, schedules multiple data acquisition and processing tasks in parallel, and executes intelligent fault-tolerant retry strategies when network requests are abnormal. S3. Read and parse the preset externalized medical quality control rules to form a standardized set of quality control rules, construct a directed dependency graph between the quality control rules and the underlying data fields, configure a one-to-one mapping index between the field missing status and the rule execution logic, and limit the field missing status to the types of not collected, not synchronized, unparseable or pending confirmation. S4. Perform standardized preprocessing operations on the collected patient medical data, extract the 18-digit ID number from the patient medical data, parse the corresponding field of the ID number to obtain the patient's date of birth, calculate the patient's age based on the parsed date of birth, and format the numerical, date, and text data in the patient medical data respectively. S5. Based on the calculated patient age, match the medical quality control standard suitable for the age from the standardized quality control rule set, extract the fields related to the target quality control rule from the preprocessed patient medical data, perform quality control comparison, if the target field data is missing and the comparison fails, traverse the directed dependency graph to retrieve the missing data link and complete the missing reason encoding. S6. Calculate the integrity score of patient medical data using the data incompleteness assessment model trained based on the incomplete sample library, preset the integrity score threshold, compare the integrity score with the threshold, dynamically switch the quality control execution strategy, and if the data integrity is insufficient, downgrade the routine comparison logic to the trend analysis logic and execute the quality control analysis. S7. Based on the quality control judgment results, missing cause codes, and completeness scores, calculate the confidence level of the quality control judgment results, integrate the quality control judgment results, missing cause codes, confidence levels, and generation timestamps to construct polymorphic quality control metadata, and associate and tag the polymorphic quality control metadata to the original patient medical data; S8. Aggregate the collected full-dimensional medical data of patients and the generated polymorphic quality control metadata, and construct a panoramic health view of patients based on the aggregated full-dimensional medical data of patients and polymorphic quality control metadata; S9. Based on the constructed panoramic health view of patients, it provides medical staff with visualization services for patient health data and quality control results.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention addresses the quality control needs of community healthcare at the grassroots level by constructing a configurable rule-based quality control unit. This unit enables the external loading and configuration of medical quality control rules, allowing for flexible adjustment of these rules based on specific community healthcare quality control standards. It also constructs a dependency graph between quality control rules and underlying data fields, along with a field missing status mapping index. For scenarios where community healthcare data is prone to missing information, it can retrieve missing data points and encode the reasons for the missing information. A data integrity score is calculated using a data incompleteness assessment model, and the quality control execution strategy is dynamically switched based on the score. Quality control analysis is performed on incomplete data, and polymorphic quality control metadata, including quality control judgment results, missing reason codes, and confidence labels, is generated and marked onto the original data. This forms a standardized, independently executable quality control system, meeting the practical needs of routine quality control and incomplete data quality control in community healthcare at the grassroots level. 2. This invention addresses the lightweight adaptation of technical solutions for community healthcare. Through an intelligent data acquisition and adaptation unit, it achieves universal automatic login adaptation and multi-mode data capture for small and medium-sized heterogeneous business systems in community healthcare, adapting to the data collection needs of these systems. Relying on the session cache reuse, concurrent task scheduling, and intelligent retry mechanism of the asynchronous high-performance execution unit, it achieves efficient data acquisition and stable execution in community healthcare scenarios, matching the real-time requirements of primary care clinical data acquisition. Through an integrated data display unit, it aggregates comprehensive patient medical data and multi-morphic quality control metadata, constructing a panoramic view of patient health and enabling visual display. This provides integrated visual data support for the daily health management and follow-up work of community healthcare personnel, aligning with their clinical needs. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the system framework of the present invention; The meanings of the labels in the diagram are as follows: 1. Intelligent data acquisition and adaptation unit; 11. Login agent module; 12. Data capture and parsing module; 2. Asynchronous high-performance execution unit; 21. Session cache management module; 22. Concurrent task scheduling module; 23. Intelligent retry module; 3. Configurable rule quality control unit; 31. Rule configuration loading module; 32. Data preprocessing module; 33. Incomplete adaptive quality control execution module; 34. Polymorphic metadata generation and tagging module; 4. Integrated data display unit; 41. Data aggregation module; 42. View construction module; 43. Visualization display module. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0019] like Figure 1 As shown, this embodiment provides a multi-source heterogeneous data integration and intelligent quality control system for community healthcare, including: The intelligent data acquisition and adaptation unit 1 is used to interface with hospital information systems, public health systems, and heterogeneous medical business systems in community healthcare scenarios. It achieves universal automatic login adaptation for these heterogeneous medical business systems and collects patient medical data through multi-mode data capture. The intelligent data acquisition and adaptation unit 1 includes a login agent module 11 and a data capture and parsing module 12, wherein: In this embodiment, the login proxy module 11 is used to connect with various heterogeneous medical business systems in the community healthcare scenario. It adaptively identifies the encryption method of the target system, automatically recognizes the login verification code, and completes fully automatic unattended login. This solves the access adaptation problem caused by different encryption methods and security verification strategies used by different heterogeneous medical business systems in the community healthcare scenario, eliminating the need for manual login and verification code input. It establishes an effective identity verification and data communication link for the intelligent data collection adaptation unit 1 to carry out subsequent data collection operations. The specific implementation is as follows: The login agent module 11 instantiates the LoginSystem class as the core execution class for login operations, sends an HTTP / HTTPS request to the login page of the target heterogeneous medical business system, obtains the response text content of the login page, and performs feature keyword retrieval on the response text content to complete the adaptive identification of the encryption method of the target system. Furthermore, if the login agent module 11 finds relevant keywords such as sm4Pwd in the response text, it determines that the target system uses the national cryptographic SM3 encryption method and automatically calls the gmssl.sm3.sm3_hash() function to complete the encryption of the login password. If no relevant keywords are found, it determines that the target system uses the conventional MD5 encryption method and calls the hashlib.md5() function to complete the encryption of the login password. In addition, if the login page of the target heterogeneous medical business system has a verification code verification step, the login agent module 11 automatically captures the verification code image resources on the page, integrates the ddddocr library to perform character recognition on the verification code image, extracts the valid verification code recognition results and uses them as key parameters of the login request for backup. Finally, the login agent module 11 combines the encrypted login password, verification code recognition result, and other basic parameters required for login to the target system to construct a complete login request parameter, initiates a login request to the target heterogeneous medical business system, and receives the session cookie returned by the target system after the login verification is successful, thus completing the fully automatic unattended login to the target heterogeneous medical business system.

[0020] In this embodiment, the data capture and parsing module 12 adopts a multi-mode data capture approach to locate, extract, and collect patient medical data for heterogeneous medical business systems with different interface formats. It adapts to the different interface presentation formats of heterogeneous medical business systems in community healthcare scenarios, achieving full coverage of data collection for API interfaces and Web page-type interface systems. This ensures accurate and complete extraction of various types of patient medical data, guaranteeing the integrity and validity of the original patient medical data output by the intelligent data collection and adaptation unit 1. The specific implementation is as follows: The data capture and parsing module 12 establishes a continuous data communication link with the target heterogeneous medical business system based on the valid session cookie obtained by the login agent module 11. It first identifies and determines the interface type of the target system, and then performs the patient medical data collection operation by matching the corresponding capture mode according to the interface type. Furthermore, for heterogeneous medical business systems that provide standardized API interfaces, the data capture and parsing module 12 calls the requests library, adds the session cookie obtained by the login proxy module 11 to the request header, constructs the patient medical data query request parameters according to the protocol specifications of the target system API interface, initiates a patient medical data query request to the specified API address, and after receiving the structured response data returned by the API interface, extracts the core medical data fields such as patient basic information, diagnosis and treatment records, follow-up data, and physical examination indicators according to preset rules. In addition, for heterogeneous medical business systems that only provide web page access and have no standardized API interface, the data crawling and parsing module 12 calls the selenium library to simulate browser operation, loads and navigates to the target system's patient data display web page. After the page elements are fully rendered, the BeautifulSoup library is called to parse the HTML source code of the page. The pre-configured XPath or CSSSelector is used to locate the tag elements that carry patient medical data on the page, extract the corresponding text or attribute values ​​of the elements, and complete the extraction operation of patient medical data. Finally, the data capture and parsing module 12 standardizes the format of the patient medical data extracted under the two capture modes, transforms unstructured data into structured data, forms a standardized set of original patient medical data, and transmits the data set to the intelligent data acquisition and adaptation unit 1 for subsequent centralized processing.

[0021] Asynchronous high-performance execution unit 2 provides execution support for the patient medical data acquisition process of intelligent data acquisition adaptation unit 1 and the patient medical data quality control process of configurable rule quality control unit 3. It employs session reuse, parallel task scheduling, and intelligent fault-tolerant retry techniques to execute data processing-related operations. Asynchronous high-performance execution unit 2 includes a session cache management module 21, a concurrent task scheduling module 22, and an intelligent retry module 23, wherein: In this embodiment, the session cache management module 21 manages valid session information after login, reusing sessions within their validity period to avoid performance overhead caused by repeated logins. This reduces repeated login operations when collecting data from the same system multiple times in a community healthcare scenario, lowers performance consumption in the identity verification process, improves the execution efficiency of the data collection process, and provides a stable session foundation for the parallel task execution of the concurrent task scheduling module 22. The specific implementation is as follows: The session cache management module 21 instantiates the SessionCache class as the core class for session management. It builds a local cache container based on the Python redis library and receives information such as the session cookie, session creation time, and session validity period (determined by the token expiration time returned by the target system) of the target heterogeneous medical business system returned by the login agent module 11. It stores the information in the cache container with "target system identifier-session ID" as the key and the full session information as the value. Furthermore, when the session cache management module 21 receives a data acquisition or quality control task request, it first checks whether there is a valid session for the corresponding target system in the cache. If it exists and the validity period has not expired, the session is reused directly. In addition, if there is no valid session in the cache, the intelligent data acquisition and adaptation unit 1 is triggered to re-execute the login process, generate new session information and update it to the cache; Finally, the session cache management module 21 periodically cleans up expired session information in the cache, releases cache resources, and ensures the effectiveness of cache storage.

[0022] In this embodiment, the concurrent task scheduling module 22 is used to create a multi-threaded execution environment, scheduling multiple data acquisition and processing tasks in parallel to improve data processing efficiency. This adapts to the concurrent needs of multi-patient, multi-system data collection and quality control in community healthcare scenarios. By using multi-threaded parallel execution, the data processing cycle is shortened, the overall system response speed is improved, and the real-time requirements of primary healthcare data acquisition are met. The specific implementation is as follows: The concurrent task scheduling module 22 instantiates the TaskScheduler class as the core class for task scheduling. It builds a thread pool execution environment based on the concurrent.futures.ThreadPoolExecutor multi-threaded library in Python. The initial core number of threads in the thread pool is set to 8 (to match the typical concurrent data processing task volume in the community medical scenario, taking into account both execution efficiency and system resource consumption). Furthermore, the concurrent task scheduling module 22 receives multiple data acquisition or quality control tasks allocated by the asynchronous high-performance execution unit 2, encapsulates the tasks into independent thread tasks, and allocates them to the thread pool for execution. In addition, the concurrent task scheduling module 22 dynamically adjusts the thread pool size according to task priority and system resource load to balance task execution efficiency and system resource consumption. Finally, the concurrent task scheduling module 22 monitors the execution status of each thread task through the add_done_callback function mechanism, captures status information such as "task completed", "network error" and "data parsing failure" in real time, and synchronizes them to the intelligent retry module 23 and the asynchronous high-performance execution unit 2.

[0023] In this embodiment, the intelligent retry module 23 is used to execute an intelligent retry strategy when a network request encounters an anomaly, avoiding interruptions in the data processing flow caused by network fluctuations. This addresses the issues of unstable network environments and easily interrupted requests in community healthcare scenarios. The intelligent retry strategy ensures the continuity of data collection and quality control processes, preventing task failures due to single network anomalies and improving the stability and reliability of system data processing. The specific implementation is as follows: The intelligent retry module 23 instantiates the RetryHandler class as the core class for retry execution. This class integrates exception listening and retry strategy execution logic. By binding an exception-catching decorator (retry_decorator) to each network request task submitted to the thread pool by the concurrent task scheduling module 22, the network request status of each data processing task in the concurrent task scheduling module 22 is monitored in real time. Furthermore, when the exception capture decorator detects network request exceptions such as ConnectionError (network connection exception) and TimeoutError (request timeout) in the concurrent task scheduling module 22, the intelligent retry module 23 triggers a preset exponential backoff retry strategy: the initial retry interval is set to 1 second, and the interval time increases exponentially by a power of 2 after each failed retry (1 second → 2 seconds → 4 seconds), which ensures retry efficiency and avoids high-frequency retries from causing access pressure on the target heterogeneous medical business system; In addition, the intelligent retry module 23 presets a maximum retry threshold (3 times) in the RetryHandler class. If the network request is still not successfully executed after exceeding the maximum retry count, the retry will stop, the task will be marked as "execution failed", and information such as exception type, retry count, and target system identifier will be recorded to the log module of the asynchronous high-performance execution unit 2. Finally, the intelligent retry module 23 feeds back the retry result or exception information to the asynchronous high-performance execution unit 2, which then determines the subsequent processing logic.

[0024] The configurable rule-based quality control unit 3 performs quality control on the patient medical data collected by the intelligent data acquisition and adaptation unit 1. It loads externally configured medical quality control rules, constructs a dependency graph between the quality control rules and the underlying data fields, and configures a mapping index between field missing states and rule execution logic. It performs standardized preprocessing on the patient medical data collected by the intelligent data acquisition and adaptation unit 1, matches it with corresponding medical quality control standards for quality control comparison, and when the missing data in the target field causes the quality control comparison to fail, it traverses the dependency graph to retrieve the missing data link, encoding the cause of the missing data as not collected, not synchronized, unresolved, or pending confirmation. It calculates the integrity score of the input patient medical data using a data incompleteness assessment model trained based on a missing sample library, dynamically switches the quality control execution strategy according to a preset integrity score threshold, downgrades the comparison logic to trend analysis logic, and performs quality control analysis. It generates polymorphic quality control metadata containing quality control judgment results, missing cause type codes, and confidence labels, and marks this polymorphic quality control metadata into the original patient medical data. It should be added that the configurable rule quality control unit 3 establishes a data interaction link with the intelligent data acquisition and adaptation unit 1, the asynchronous high-performance execution unit 2, and the integrated data display unit 4. It receives the structured raw patient medical data transmitted by the intelligent data acquisition and adaptation unit 1, and completes the parallel execution and fault tolerance of the quality control task by relying on the concurrent task scheduling module 22 and the intelligent retry module 23 of the asynchronous high-performance execution unit 2. It pushes the patient medical data marked with polymorphic quality control metadata to the integrated data display unit 4. Meanwhile, the configurable rule quality control unit 3 can be deployed in the community medical primary server hardware environment, adapted to x86 or ARM architecture processors, with a memory configuration of no less than 8GB and a storage configuration of no less than 500GB. It supports local storage and real-time loading of externalized quality control rule files to meet the lightweight deployment requirements in the community medical scenario. In addition, the configurable rule quality control unit 3 sets the rule configuration interface, which allows medical staff to edit, add or delete medical quality control rules through a visual interface. The rules are stored in the local rule base in JSON or YAML format. The rules can be updated without modifying the core code, adapting to the changes in quality control standards in different community medical scenarios. Finally, the configurable rule quality control unit 3 synchronizes abnormal information and rule execution logs during the quality control process to the system log module, which facilitates maintenance personnel in troubleshooting problems and ensures the traceability of the quality control process.

[0025] The configurable rule quality control unit 3 includes a rule configuration loading module 31, a data preprocessing module 32, an incomplete adaptive quality control execution module 33, and a polymorphic metadata generation and tagging module 34, wherein: In this embodiment, the rule configuration loading module 31 loads the externally configured medical quality control rules, constructs a dependency graph between the quality control rules and the underlying data fields, and configures a mapping index between the field missing status and the rule execution logic. The rule configuration loading module 31 receives the rule loading instruction from the configurable rule quality control unit 3 and, following the order of "first loading the parsed rule set, then constructing the dependency graph, and finally configuring the missing mapping index," sequentially drives the rule externalization loading submodule, the dependency graph construction submodule, and the missing mapping index configuration submodule to execute operations. Simultaneously, the rule configuration loading module 31 configures a unified context environment for each submodule, passing core parameters such as patient identifier, target system identifier, and quality control rule version number to ensure the traceability of the execution results of each submodule. Furthermore, the rule configuration loading module 31 will... The output results of each submodule (standardized quality control rule set, directed dependency graph, missing mapping index) are cached in a memory cache container with a 24-hour validity period. Expired caches are cleaned up periodically to improve the execution efficiency of rule matching and missing data retrieval in the quality control process. Finally, the rule configuration loading module 31 sets up a rule change monitoring mechanism, which monitors the modification, addition, or deletion of externalized quality control rule files in real time through a file system monitor. Once a rule file change is detected, the new rule is first loaded into a temporary cache and its legality is verified. After the verification is passed, it is switched to the effective rule. Finally, the old rule cache is cleaned up, and each submodule is immediately triggered to re-execute the loading and building operations to ensure the real-time performance and accuracy of the rules. The rule update log is synchronized to the system log module to facilitate the operation and maintenance personnel to trace the rule change history. The rule configuration loading module 31 includes a rule externalization loading submodule, a dependency graph construction submodule, and a missing mapping index configuration submodule, wherein: The rule externalization loading submodule reads and parses preset externalized medical quality control rules, forming a standardized set of quality control rules. This enables the externalized storage and structured parsing of medical quality control rules, decoupling them from core business code. This allows healthcare professionals in community healthcare scenarios to flexibly adjust rules according to the needs of grassroots quality control, updating rules without modifying the core system code. It also provides standardized rule input for dependency graph construction and missing mapping index configuration. The specific implementation is as follows: The rule externalization loading submodule instantiates the RuleFileParser class as the core class for rule parsing. During initialization, it loads the externalized rule storage directory path and rule file extension (.json) specified in the configuration file, creates a rule parsing task queue, and initializes the number of parsing threads to 4 to avoid performance bottlenecks caused by single-threaded parsing. Furthermore, the rule externalization loading submodule traverses all externalized medical quality control rule files in .json format under the specified local directory, performs file existence and readability checks on each rule file, and records an error log and skips the file if the file is corrupted or cannot be read. In addition, the rule externalization loading submodule reads the validated rule file line by line, parses the file content using UTF-8 encoding, and uses Python's built-in json library to parse the file content into Python dictionary objects. It then extracts the core fields of each rule: rule ID (rule_id), quality control item name (qc_item), threshold range (threshold), applicable department (dept_scope), effective time (effective_time), expire time (expire_time), data field dependency list (dependent_fields), and applicable age range (age_scope). The value of each core field is then encapsulated into a rule object with a unified format, containing id, name, threshold, and other fields. The system has eight attributes: eshold, dept, start_time, end_time, dependencies, and age_scope. The attribute names are: rule_id (corresponding to id), qc_item (corresponding to name), threshold range (corresponding to threshold), applicable departments (corresponding to dept), effective time (corresponding to start_time), expire time (corresponding to end_time), dependent fields (corresponding to dependencies), and applicable age range (corresponding to age_scope). Finally, the rule externalization loading submodule performs validity checks on the parsed rule objects: it checks the uniqueness of the rule ID to avoid duplicate rules; it checks the rationality of the threshold range to ensure that the threshold is a numeric type and the upper and lower limits are logically correct (lower limit ≤ upper limit); it checks the validity of the applicable departments to ensure that the department number exists in the preset list of community medical departments; it checks the logic of the effective time and the expiration time to ensure that the effective time is earlier than the expiration time; after removing all abnormal rules that fail the checks, the remaining valid rules are sorted in ascending order by rule ID to form a complete set of standardized quality control rules, which is stored in list form and passed to the dependency graph construction submodule. At the same time, the total number of parsed rules, the number of valid rules, and the number of abnormal rules are recorded in the statistics log.

[0026] The dependency graph construction submodule constructs a directed dependency graph between quality control rules and underlying data fields, establishing a unique association link between quality control rules and data fields. This clarifies the dependency logic of quality control rules on underlying data fields, providing a visual association basis for subsequent missing link retrieval in data missing scenarios. Simultaneously, it provides the foundation for field-rule association relationships for the missing mapping index configuration submodule. The specific implementation is as follows: The dependency graph construction submodule instantiates the DependencyGraphBuilder class as the core class for dependency graph construction. It receives the standardized quality control rule set passed by the rule externalization loading submodule, and loads the underlying medical data field dictionary in the community medical scenario. This dictionary contains the field ID, field name and field type of all collected fields such as patient basic information, medical records, and follow-up data. The dependency graph construction submodule initializes a directed acyclic graph structure, using both adjacency matrix and adjacency list for storage. The adjacency matrix is ​​used for fast retrieval of rules and field dependencies, while the adjacency list is used for efficient traversal of upstream dependent nodes after data loss. The formula for calculating the adjacency matrix is: ; in: Represents the adjacency matrix of the nth element. Line number The element values ​​in the column are 1 if there is a dependency, and 0 if there is no dependency. Represents the first in the set of standardized quality control rules. The index of a quality control rule is determined by its sorting position in the set; This indicates the first [field] in the underlying data field dictionary. The index of each data field is determined by the field's sort position in the dictionary; In addition, the dependency graph construction submodule traverses each rule in the standardized quality control rule set, parses its data field dependency list, matches the corresponding field index in the underlying data field dictionary, assigns values ​​to the adjacency matrix according to the above formula, and establishes the association relationship between "rule-dependent field" in the adjacency table; and adds weight values ​​to the directed edges of each rule-field, with weight values ​​ranging from 1 to 5, assigned according to the coreness and threshold strictness of the field in the quality control rule, where core quality control fields correspond to 4-5 weights, auxiliary fields correspond to 1-2 weights, and strict standards with no threshold fluctuations are increased by 1 level based on the corresponding weight. The higher the value, the stronger the dependency. Finally, the dependency graph construction submodule passes the completed directed dependency graph (adjacency matrix + adjacency list) and field-rule mapping table to the missing mapping index configuration submodule.

[0027] The missing data mapping index configuration submodule configures a one-to-one mapping index between field missing status and rule execution logic. It explicitly defines field missing status as uncollected, unsynchronized, unparseable, or pending confirmation, providing accurate matching basis for quality control execution in data missing scenarios. This achieves the binding of missing status with quality control strategies and supports dynamic switching of quality control strategies in configurable rule-based quality control unit 3. The specific implementation is as follows: The MissingIndexConfigurer class is instantiated as the core class for index configuration in the MissingMappingIndexConfigurer submodule. It receives the directed dependency graph and field-rule mapping table passed by the dependency graph construction submodule and loads the preset field missing status enumeration set, which only contains four fixed states: not collected, not synchronized, unparseable, and pending confirmation. Furthermore, the missing mapping index configuration submodule initializes a hash table as the storage structure for the missing mapping index. The key of the hash table is a concatenated string of "field ID + missing status", and the value is the corresponding rule execution logic identifier. The execution logic identifier includes three categories: complete comparison, trend analysis, and skip quality control. In addition, the missing mapping index configuration submodule traverses all fields in the underlying data field dictionary, divides them into core quality control fields and auxiliary fields according to their attributes in community medical quality control, and configures matching execution logic for the four missing states of the two types of fields: the uncollected state of the core quality control field corresponds to trend analysis, the unsynchronized / pending confirmation state corresponds to trend analysis, and the unresolvable state corresponds to skipping quality control; the four missing states of the auxiliary fields all correspond to skipping quality control; and forms a triple of "field ID-missing state-execution logic" according to this configuration, which is then encapsulated as a key-value pair in a hash table; Finally, the missing mapping index configuration submodule completes the integrity verification of the hash table, ensuring that the four missing states of all fields are configured with corresponding execution logic, and synchronizes the configured missing mapping index to the quality control execution module of the configurable rule quality control unit 3, while caching it in memory for subsequent fast calls.

[0028] In this embodiment, the data preprocessing module 32 performs standardized preprocessing operations on the patient medical data collected by the intelligent data acquisition and adaptation unit 1. The standardized preprocessing operation process of the data preprocessing module 32 includes the following steps: S32.1 Extract the 18-digit ID number from the patient's medical data collected by the intelligent data acquisition and adaptation unit 1, and parse the corresponding field of the ID number to obtain the patient's date of birth, providing basic data support for subsequent age calculation and quality control rule matching based on age stratification. The specific implementation is as follows: The data preprocessing module 32 instantiates the IDCardParser class as the core class for ID card parsing, traverses the structured patient medical data transmitted by the intelligent data acquisition and adaptation unit 1, and if the target field named "ID card number" is not located, the patient data is marked as "no ID card number field" and recorded in the exception log, skipping the subsequent operations of this step; if the target field is located, the subsequent verification operation is performed. Furthermore, the data preprocessing module 32 checks whether the character length of the field is 18 characters. If the length is 18 characters, the lowercase 'x' at the end of the ID number is converted to uppercase 'X' before performing subsequent parsing operations. If the length does not match, the patient data is marked as "ID number format abnormal" and recorded in the abnormal log. In addition, the data preprocessing module 32 extracts the 7th to 14th consecutive characters from the ID number string and parses them into the patient's date of birth in a fixed format of "YYYYMMDD". For example, the extracted characters "19941117" are parsed as November 17, 1994. Finally, the data preprocessing module 32 stores the parsed patient's date of birth in the "Date of Birth" field of the patient's medical data, providing input data for the age calculation in step S32.2.

[0029] S32.2 Calculate the patient's age based on the patient's birth date obtained from the analysis. This method converts patients' birth dates into numerical age data that can be directly used for quality control rule matching, providing a precise calculation basis for subsequent age-stratified medical quality control standards (such as quality control rules for children, adults, and elderly chronic diseases). The specific implementation is as follows: The data preprocessing module 32 instantiates the AgeCalculator class as the core class for age calculation, and obtains the local date on the server (containing only year, month and day, excluding hour, minute and second) and the patient's birth date obtained from step S32.1; Furthermore, the data preprocessing module 32 uses a calculation method that combines the year difference with whether the birthday has passed, to determine the patient's age. The calculation formula is: ; ; In the formula: This indicates the patient's actual age, in years; The year value representing the current system date; The numerical value representing the year of the patient's birth; A correction factor indicating whether the birthday has passed, with a value of 0 or 1; The month value representing the current system date; The date value representing the current system date; The numerical value representing the month of the patient's birth date; A numerical value representing the patient's date of birth; In addition, the data preprocessing module 32 processes the calculated data. Perform range validation to ensure that the age value is within a reasonable range of 0 to 120 years old; if it exceeds the range, mark it as "age calculation abnormal". Finally, the data preprocessing module 32 will calculate the patient age. The "age" field stored in the patient's medical data provides standardized numerical input for subsequent quality control rule matching.

[0030] S32.3 Standardize the formats of numerical, date, and text data in patient medical data to achieve uniformity and eliminate format differences in data collected from multiple heterogeneous medical business systems. This transforms all types of data into a unified format, providing a consistent and standardized data foundation for subsequent quality control comparisons and data visualization. The specific implementation is as follows: Meanwhile, the data preprocessing module 32 instantiates the DataFormatter class as the core class for format regularization, traverses all fields of the patient's medical data, and divides the fields into three categories: numeric, date, and text based on the field metadata (preset field type identifiers); Furthermore, for numerical data (such as systolic blood pressure and fasting blood glucose values), the data preprocessing module 32 uniformly retains two decimal places, removes thousands separators and non-numeric characters, and converts string-formatted numerical values ​​into floating-point numerical values. In addition, for date-type data (such as consultation date and follow-up date), the data preprocessing module 32 unifies heterogeneous formats such as "YYYY / MM / DD" and "MM-DD-YYYY" into the standard date format "YYYY-MM-DD". Finally, for text-based data (such as patient complaints and diagnostic conclusions), the data preprocessing module 32 removes leading and trailing whitespace characters, encodes them uniformly into UTF-8 format, converts full-width punctuation marks to half-width punctuation marks, and after completing the format standardization of all fields, the data preprocessing module 32 transmits the standardized patient medical data to the quality control execution module of the configurable rule quality control unit 3 to provide input for subsequent quality control processes.

[0031] In this embodiment, the incomplete adaptive quality control execution module 33 relies on preprocessed patient medical data and loaded medical quality control rules to complete quality control comparison, data missing link retrieval, and dynamic switching of quality control execution strategies. The quality control comparison and dynamic strategy switching process of the incomplete adaptive quality control execution module 33 includes the following steps: S33.1, Patient age obtained based on data preprocessing module 32 From the standardized quality control rule set of the rule configuration loading module 31, medical quality control standards suitable for the patient's age are matched to achieve accurate matching between medical quality control standards and patient age stratification. This avoids the participation of quality control rules that are not applicable to the age in the comparison, ensuring the clinical rationality and pertinence of the quality control standards, and providing a rule basis that conforms to the patient's age characteristics for subsequent quality control comparisons. The specific implementation is as follows: Meanwhile, the incomplete adaptive quality control execution module 33 instantiates the AgeRuleMatcher class as the core class for age rule matching and obtains the patient age calculated by the data preprocessing module 32. The set of standardized quality control rules is transmitted by the rule configuration loading module 31. This set of rules includes metadata such as the rule ID, quality control items, threshold range, applicable age range, and applicable department for each rule. Furthermore, the incomplete adaptive quality control execution module 33 traverses each rule in the standardized quality control rule set and extracts the applicable age range field of the rule. This field defines the age range in which the rule takes effect; for example, the applicable age range for the "systolic blood pressure quality control rule" is 18-120 years old. In addition, the incomplete adaptive quality control execution module 33 verifies the patient's age through numerical range comparison logic. Does it meet the requirements? ;in, Indicates the minimum applicable age; This indicates the maximum applicable age range; this field defines the age range in which the rule takes effect, for example, the applicable age range for the "systolic blood pressure quality control rule" is 18-120 years old; Finally, the incomplete adaptive quality control execution module 33 filters out all rules that meet the age matching conditions, forms a set of target medical quality control standard rules, and passes them to the quality control comparison step S33.2. If no rule is matched, the patient data is marked as "no matching quality control rule" and recorded in the abnormal log.

[0032] S33.2 Extract fields related to the target quality control rules from the preprocessed patient medical data, perform quality control comparison. If the comparison fails due to missing data in the target field, traverse the directed dependency graph constructed by the rule configuration loading module 31, retrieve the missing data points, and encode the reasons for the missing data. Complete the basic quality control verification, accurately locate and encode the source of the missing data, and provide a basis for subsequent integrity assessment and strategy switching. This avoids the quality control process from being interrupted due to missing data, ensuring the continuity of the quality control process. The specific implementation is as follows: The incomplete adaptive quality control execution module 33 instantiates the QcComparisonHandler class as the core class for quality control comparison, and obtains the target medical quality control standard rule set matched in step S33.1, as well as the preprocessed patient medical data, which includes standardized numerical, date, and text fields; Furthermore, the incomplete adaptive quality control execution module 33 traverses each rule in the target quality control rule set and extracts the list of target quality control fields associated with the rule. For example, the target field associated with "blood glucose quality control rules" is "fasting blood glucose level"; In addition, the incomplete adaptive quality control execution module 33 extracts from the patient's medical data For the corresponding field values, the preset quality control comparison logic is executed: for numerical fields, numerical range comparison is performed (e.g., blood glucose value 3.9-6.1mmol / L); for date fields, time logic verification is performed (e.g., follow-up date is later than the date of consultation); for text fields, content standardization verification is performed (e.g., the diagnosis conclusion contains standard ICD code); and during the comparison process, the target field is checked in real time for whether there is missing data. If the field value is empty, an empty string, or an anomaly marker, the comparison is judged to have failed. Finally, if the comparison fails and the target field data is detected to be missing, the incomplete adaptive quality control execution module 33 calls the directed dependency graph constructed by the rule configuration loading module 31, traverses the upstream dependency nodes of the target field through the adjacency list, retrieves the source link of the missing data, and encodes the missing reason into one of four types according to the preset missing reason classification standard: uncollected, unsynchronized, unparsable, or unconfirmed. The missing reason is then encoded and stored in the missing reason field of the patient's medical data.

[0033] S33.3 Calculate the integrity score of patient medical data using a data incompleteness assessment model. This method quantitatively assesses the completeness of patient medical data, providing objective numerical data for the dynamic switching of quality control strategies. It enables tiered quality control based on data integrity, avoiding biases in strategy switching caused by subjective judgment. The specific implementation is as follows: The incompleteness adaptive quality control execution module 33 instantiates the CompletenessEvaluator class as the core class for completeness assessment. It obtains preprocessed patient medical data, the missing cause coding information completed in step S33.2, and a preset medical data field weight configuration table. This weight configuration table assigns different weights to fields according to their importance in medical quality control. The core quality control field has a weight of 0.8, the auxiliary field has a weight of 0.2, and the sum of all weights is 1. The data incompleteness assessment model is a lightweight gradient boosting decision tree (GBDT) model customized for community medical scenarios. The model is first built and trained, and then the completeness score is calculated based on the model. The specific process is as follows: First, construct and train the data incompleteness assessment model (model preparation): Construction of the Incomplete Sample Library: An incomplete sample library was constructed by collecting over 100,000 patient medical data entries from community healthcare institutions over the past three years. Each sample entry includes a feature dimension and a label dimension. The feature dimension includes the missing status (0 = complete, 1 = missing) of 80 routinely collected fields from community healthcare institutions, the field type (core / auxiliary), and the missing reason code (not collected = 0 / not synchronized = 1 / unresolved = 2 / pending confirmation = 3, no missing entries are marked as 4). The label dimension consists of completeness labels annotated by clinical experts. (Values ​​[0,1]), the sample library is divided into training set (70%), validation set (20%) and test set (10%) in a ratio of 7:2:1.

[0034] Model structure design: The Gradient Boosting Decision Tree (GBDT) structure is used, with 100 base learners and a maximum depth of 5 for each tree. The learning rate is... The feature sampling ratio is 0.8; the model input is the sample feature vector. The output is the completeness estimate. The prediction formula is: ; in: This represents the estimated value of patient medical data integrity output by the model, with a value range of [0,1]. The closer the value is to 1, the higher the data integrity. The index represents the decision tree, with a value ranging from 1 to 100, corresponding to the m-th decision tree; 0.1 represents the model learning rate. The fixed value is used to control the contribution weight of each decision tree to the final prediction result; Indicates the first Each decision tree is used to process the input feature vector. The predicted value ranges from [0,1]. The feature vector representing the model input contains 82 feature values ​​(missing status of 80 fields + field type + missing reason encoding).

[0035] Model training: Step 1: Feature normalization.

[0036] The feature vectors of the training set samples are normalized to map all feature values ​​to the interval [0,1], eliminating differences in feature dimensions. The normalization formula is as follows: ; in: Indicates the first The normalized values ​​of each feature range from [0,1]. Indicates the first The original values ​​of each feature (e.g., field missing status is 0 / 1, field type is core=1 / auxiliary=0). Indicates the first training set The minimum value of each feature; Indicates the first training set The maximum value of each feature; like Then Set the value to 0.5.

[0037] Step 2: Define the loss function.

[0038] Mean squared error (MSE) is used as the loss function to measure the deviation between the model's predicted values ​​and the manually labeled values. The loss function formula is as follows: ; in: This represents the mean squared error loss value during model training; the smaller the value, the better the model's prediction performance. This indicates the total number of samples in the training set (more than 70,000 in this example). This represents the index of a sample in the training set, with a value ranging from 1 to N; Indicates the first The manual annotation integrity labels of each training set sample, with values ​​ranging from [0,1]; The model represents the first The completeness estimate of each training set sample, with a value range of [0,1].

[0039] Step 3: Training termination and verification.

[0040] Minimize the loss function using gradient descent. The splitting node and leaf node values ​​of each decision tree are iteratively updated. Training stops when the mean squared error (MSE) of the validation set no longer decreases for five consecutive rounds. After training, the model's performance is validated on the test set, and the model's decision coefficient is required to be... ( (The closer to 1, the better the model fits.) If the metric is met, save the model parameters to local storage; otherwise, adjust the number / depth of decision trees and retrain.

[0041] Then, an integrity score is calculated based on the trained model. : Furthermore, the incomplete adaptive quality control execution module 33 loads the trained model parameters and counts the total number of fields in the patient's medical data. With the number of valid complete fields The number of valid complete fields is defined as the number of fields with no missing reason codes and whose field values ​​conform to the format specifications; In addition, the incomplete adaptive quality control execution module 33 calculates a weighted integrity score based on field weights, and the integrity score... The calculation formula is: ; in: This represents the integrity score of the patient's medical data, with a value range of [0,1]. The closer the value is to 1, the higher the data integrity. This indicates the total number of fields in the patient's medical data, which is the preset total number of all collectable medical data fields. This indicates the number of valid complete fields, specifically the number of fields without missing reason codes. Indicates the first The weight value of each field is determined by the field weight configuration table, and the sum of the weights of all fields is 1. And the calculated Perform range validation, if Then correct it to 1, if Then it is corrected to 0 to ensure that the score is strictly within the range of [0,1]. Finally, the incomplete adaptive quality control execution module 33 will calculate the integrity score. The integrity score field stored in the patient's medical data is passed to the strategy dynamic switching step in step S33.4.

[0042] S33.4. Based on the preset integrity scoring threshold, compare the integrity scores. The quality control execution strategy is dynamically switched according to the threshold value; if the completeness is insufficient, the regular comparison logic is downgraded to trend analysis logic, and the trend prediction value is used to predict the value. The system completes quality control analysis and can still output valid quality control conclusions even when data integrity is insufficient, preventing a complete interruption of the quality control process due to incomplete data and ensuring the continuity and availability of quality control services in community healthcare scenarios. The specific implementation is as follows: Meanwhile, the incomplete adaptive quality control execution module 33 instantiates the StrategySwitcher class as the core class for strategy switching and obtains the integrity score calculated in step S33.3. and the system's preset integrity scoring threshold. threshold The value range is [0,1], and it is set to 0.7 according to the needs of community medical quality control; Furthermore, the incomplete adaptive quality control execution module 33 performs numerical comparison to determine... and Size relationship: If If the data integrity is sufficient, then the routine quality control comparison logic in step S33.2 is executed, and the routine quality control conclusion is output; if If the data integrity is insufficient, the quality control execution strategy downgrade process will be triggered. Furthermore, under the trend analysis logic, the incomplete adaptive quality control execution module 33 calls a pre-trained time series prediction model (such as an ARIMA model or an LSTM neural network model), inputs historical sequence data of similar medical data of patients, and calculates the trend prediction value. Trend forecast value The calculation formula is: ; in: This represents the trend forecast value, which is the medical data indicator value at the predicted time point. This represents the time series prediction model function, which is a pre-set model trained based on a community healthcare incomplete sample database; This represents the historical sequence values ​​of similar medical data for patients. At the current time point, The length of the historical data sequence; And through trend forecast values The data is compared with the preset quality control threshold to complete the trend quality control analysis; Finally, the incomplete adaptive quality control execution module 33 summarizes the conclusions of routine quality control or trend quality control analysis, transmits the quality control results to the polymorphic quality control metadata generation module, and records the strategy switching log to the system log module.

[0043] In this embodiment, the polymorphic metadata generation and labeling module 34 generates polymorphic quality control metadata and associates and labels this polymorphic quality control metadata with the original patient medical data. The polymorphic quality control metadata generation and labeling process of the polymorphic metadata generation and labeling module 34 includes the following steps: S34.1 Quality control judgment results, missing cause codes, and integrity scores based on the output of the incomplete adaptive quality control execution module 33 The confidence level of the quality control judgment result is calculated. This system quantifies and assesses the reliability of quality control judgments, providing a credibility dimension identifier for polymorphic quality control metadata. This helps medical staff intuitively judge the credibility level of quality control conclusions and avoid misinterpretations due to incomplete data. The specific implementation is as follows: Meanwhile, the polymorphic metadata generation and tagging module 34 instantiates the ConfidenceCalculator class as the core class for confidence calculation, and obtains the quality control judgment results, missing cause codes, and integrity scores output by the incomplete adaptive quality control execution module 33. ; Furthermore, the polymorphic metadata generation tagging module 34 defines missing factors. Assign a value based on the reason for the missing information: No corresponding data was collected. Not synchronized Unresolvable correspondence Pending confirmation When multiple fields are missing simultaneously, calculate the weighted average of the missing factors for all missing fields, with a weight of 0.8 for the core quality control field and 0.2 for the auxiliary fields; when no data is missing... ; In addition, the polymorphic metadata generation tagging module 34 uses a weighted summation formula to calculate the confidence level. The calculation formula is: ; in: This indicates the confidence level of the quality control judgment result, with a value range of [0,1]. The closer the value is to 1, the more reliable the quality control judgment result is. This represents the weighting coefficient for the integrity score, with a fixed value of 0.6, indicating the degree to which the integrity score contributes to the confidence level. This represents the missing factor weighting coefficient, with a fixed value of 0.4, indicating the contribution of missing data status to the confidence level. ; The completeness score of the patient's medical data comes from step S33.3 of the incomplete adaptive quality control execution module 33, and the value range is [0,1]. This represents the missing factor, which is assigned a value based on the reason for the missing data. The value range is [0, 0.9]. The larger the value, the more significant the impact of missing data on the quality control results. Finally, the polymorphic metadata generation tagging module 34 calculates the... Perform range validation, if Then correct it to 1, if Then correct it to 0 to ensure that the confidence level is strictly within the interval [0,1]. The calculated confidence level will then be... Proceed to step S34.2.

[0044] S34.2, Integrate quality control judgment results, missing cause codes, and confidence levels. This involves generating timestamps, constructing polymorphic quality control metadata, and structurally integrating key information from the entire quality control process to form a complete metadata set containing results, causes, credibility, and timestamps. This achieves standardized encapsulation of quality control information, providing a unified input format for subsequent data labeling and visualization. The specific implementation is as follows: Simultaneously, the polymorphic metadata generation and marking module 34 instantiates the MetadataBuilder class as the core class for metadata construction, and obtains the confidence level calculated in step S34.1 and the quality control judgment result output by the incomplete adaptive quality control execution module 33. ), missing reason code ( ), and the system's current timestamp ( ); Furthermore, the polymorphic metadata generation and tagging module 34 defines the structured format of polymorphic quality control metadata, encapsulating core information in key-value pair form. The metadata includes the following fields: The quality control judgment result, with values ​​of "normally qualified", "normally unqualified", "trend qualified", and "trend unqualified", comes from the incomplete adaptive quality control execution module 33; : Missing reason code, with values ​​of "not collected", "not synchronized", "unresolved", "pending confirmation" or "no missing", from the incomplete adaptive quality control execution module 33; The confidence level of the quality control judgment result comes from step S34.1 and has a value range of [0,1]. The patient's medical data integrity score comes from step S33.3 of the incomplete adaptive quality control execution module 33, and the value range is [0,1]. The timestamp for the generation of polymorphic quality control metadata is in the format "YYYY-MM-DDHH:MM:SS" and is generated by the current system time. In addition, the polymorphic metadata generation tag module 34 encapsulates the above fields into a structured metadata object in JSON format.

[0045] Finally, the polymorphic metadata generation tagging module 34 passes the completed polymorphic quality control metadata object to step S34.3.

[0046] S34.3 The generated polymorphic quality control metadata is associated with the original patient medical data collected by the intelligent data acquisition and adaptation unit 1, achieving a one-to-one binding between the quality control metadata and the original medical data. This ensures that quality control information is traceable and associative, providing complete patient data with quality control tags for the subsequent integrated data display unit 4, facilitating medical staff to simultaneously obtain quality control status information when viewing the original data. The specific implementation is as follows: The polymorphic metadata generation and tagging module 34 instantiates the MetadataTagger class as the core class for metadata tagging, obtains the polymorphic quality control metadata object constructed in step S34.2, and the original patient medical data collected by the intelligent data acquisition and adaptation unit 1. The original patient medical data uses a 16-digit globally unique identifier patient ID assigned by the community medical system. The last two bits are check bits, which serve as a unique identifier; Furthermore, the polymorphic metadata generation tagging module 34... As the association key, the polymorphic quality control metadata is added to the original patient medical data as an additional field. The additional field is named "qc_metadata" and the field value is structured polymorphic quality control metadata (JSON string format). In addition, the polymorphic metadata generation and marking module 34 verifies the validity of the association marking operation, checks whether each original patient medical data is successfully bound to the corresponding polymorphic quality control metadata, and marks any unbound cases as abnormal and records them in the log. Finally, the polymorphic metadata generation and tagging module 34 transmits the patient medical data with associated tags to the integrated data display unit 4, providing complete data with quality control tags for subsequent visualization.

[0047] The integrated data display unit 4 provides medical staff with visualization services for patient health data and quality control results. It aggregates comprehensive patient medical data collected by the intelligent data acquisition and adaptation unit 1 with polymorphic quality control metadata generated by the configurable rule-based quality control unit 3 to construct a panoramic view of patient health. The integrated data display unit 4 includes a data aggregation module 41, a view construction module 42, and a visualization module 43, wherein: In this embodiment, the data aggregation module 41 interfaces with the intelligent data acquisition and adaptation unit 1 and the configurable rule-based quality control unit 3, aggregating comprehensive patient medical data and polymorphic quality control metadata. This achieves unified collection of patient medical data and quality control information, breaking down information barriers between multiple data sources. It provides a complete and consistent dataset for the subsequent view construction module 42, ensuring that the patient data obtained by medical staff is standardized data containing comprehensive medical information and precise quality control status, avoiding omissions of diagnostic and treatment information due to data dispersion. The specific implementation is as follows: The data aggregation module 41 instantiates the DataAggregationHandler class as the core class for data aggregation. During initialization, it loads the preset interface configuration, including the data interface address of the intelligent data acquisition adaptation unit 1 and the metadata interface address of the configurable rule quality control unit 3. It uses the HTTP / HTTPS long connection protocol to complete the network communication with the two units and ensure the stability of data retrieval. Furthermore, the data aggregation module 41 uses the patient ID as the core associated index and initiates data retrieval requests respectively: it retrieves full-dimensional medical data of the patient from the intelligent data collection and adaptation unit 1, including structured fields such as basic patient information (name, gender, ID number), medical records (visit time, diagnosis conclusion, prescription information), follow-up data (follow-up time, follow-up results), and physical examination indicators (blood pressure, blood sugar, blood lipids); and it retrieves polymorphic quality control metadata corresponding to the patient ID from the configurable rule quality control unit 3, including core metadata such as quality control judgment results, missing reason code, completeness score, confidence level, and generation timestamp. In addition, the data aggregation module 41 performs data association matching operations, using the patient ID as the key, and associates the polymorphic quality control metadata as an additional field with the corresponding patient medical data record to form a joint dataset containing "medical data + quality control metadata", ensuring that in the same patient data, medical information and quality control conclusions are bound one by one. Finally, the data aggregation module 41 performs a full validation of the federated dataset: it verifies the uniqueness of patient IDs to avoid duplicate data; it verifies the integrity of core fields to ensure that no critical medical data or quality control metadata is missing; it verifies the standardization of data formats to ensure that numeric fields are valid values ​​and timestamp fields are in standard format; if the validation fails, it records an anomaly log and removes abnormal data, and only the validated federated dataset is passed to the view building module 42 to ensure the accuracy of input data in subsequent processes.

[0048] In this embodiment, the view construction module 42 constructs a panoramic health view of the patient based on the aggregated full-dimensional medical data and polymorphic quality control metadata. It structurally integrates and hierarchically encapsulates the scattered multi-dimensional data and quality control information to form a view carrier that conforms to the reading habits of medical staff. This provides a unified and clear display input for the visualization module 43, avoiding difficulties in information identification for medical staff due to data disorder and improving the readability and logic of the view information. The specific implementation is as follows: The view building module 42 instantiates the ViewBuilder class as the core class for view building, obtains the joint dataset output by the data aggregation module 41, parses the field dimensions and data types in the dataset, and presets the layout of the three core areas of the patient panoramic health view, namely the patient basic information area, the core medical data area, and the quality control status panoramic area. Furthermore, the view construction module 42 encapsulates basic identity information such as patient ID, name, age, gender, contact information, and department of visit in the patient basic information area, and organizes it into text display units in the form of key-value pairs to ensure that the basic information is clear and searchable. In the core medical data area, the medical data is layered according to its clinical importance: core diagnostic and treatment indicators such as blood pressure, blood sugar, and blood lipids are classified as primary display items, and auxiliary information such as follow-up records and physical examination notes are classified as secondary display items. At the same time, the same type of indicators are sorted in time sequence to construct time-series data display units. In the quality control status panorama area, the module integrates information such as quality control judgment results, missing reason codes, integrity scores, confidence levels, and generation timestamps from polymorphic quality control metadata, and encapsulates them into structured quality control display units to clearly mark the data quality status and credibility. In addition, the view construction module 42 defines the hierarchical display rules of the view: basic patient information and core medical data are displayed first, while quality control information is bound to the corresponding medical data fields in the form of associated tags to avoid view information overload; Finally, the view building module 42 encapsulates the completed patient panoramic health view into a structured view object in JSON format, which includes meta-information such as region layout definition, field mapping relationship, display priority, and interaction trigger rules, ensuring that the visualization display module 43 can directly parse and render the view object and pass it to the visualization display module 43.

[0049] In this embodiment, the visualization module 43, based on a panoramic view of the patient's health, provides medical staff with visualization services for patient health data and quality control results. It transforms the structured view into an intuitive interactive interface, enabling the visual presentation of medical data and quality control information. This helps medical staff quickly identify patient health risks, data quality issues, and the credibility of quality control conclusions, improving the efficiency and accuracy of clinical diagnosis and treatment decisions. Simultaneously, it supports interactive exploration and in-depth analysis of the data by medical staff. The specific implementation is as follows: The visualization module 43 instantiates the VisualizationRenderer class as the core visualization class. During initialization, it loads a lightweight front-end visualization component library adapted for the community medical scenario, loads the structured view object output by the view construction module 42, and parses the view's area layout, field mapping, and display rules. Furthermore, the visualization module 43 uses a plain text component to render the patient's basic information area, setting the font size, color, and layout to ensure that the basic identity information is clear and easy to read. The specific settings are as follows: For the core medical data area, differentiated visualization components are used according to the data type: numerical core indicators (such as systolic blood pressure and fasting blood glucose) are displayed using line charts and dashboard components to show the indicator values ​​and trends, time-series follow-up data are displayed using time axis components, and text-based diagnostic conclusions are displayed using collapsible text box components. For the overall quality control status, a multi-dimensional status component is used for rendering: the quality control judgment results are displayed with color labels (green = qualified, yellow = trend analysis, red = unqualified), the completeness score is displayed with a progress bar, the confidence level is displayed with a star rating, and the missing reason code and generation timestamp are displayed with text labels. In addition, the visualization module 43 is equipped with interactive operation functions, supporting multi-dimensional interaction by medical staff: clicking the quality control status label will bring up a details box displaying the missing reason code, , Complete metadata; clicking on core medical indicators expands historical data trajectories, allowing you to view the trend of indicator changes over time; long-pressing the displayed area allows you to copy the corresponding data to the clipboard, meeting the needs of medical staff for diagnosis and treatment records and data statistics; Finally, the visualization module 43 pushes the rendered visualization interface to the terminal devices of medical staff (such as community medical workstations, tablets, and computers). At the same time, it sets up an automatic interface refresh mechanism. When the data aggregation module 41 adds patient data or updates quality control metadata, the interface will synchronously display the latest patient health data and quality control results in real time, ensuring the timeliness and effectiveness of the information.

[0050] This embodiment also provides a method for multi-source heterogeneous data integration and intelligent quality control in community healthcare. Based on the above-mentioned multi-source heterogeneous data integration and intelligent quality control system for community healthcare, it includes the following steps: S1. Connects with hospital information systems, public health systems, and heterogeneous medical business systems in community healthcare scenarios, and completes universal automatic login adaptation for various heterogeneous medical business systems. It adaptively identifies the encryption method of the target system, automatically identifies the login verification code, and completes fully automatic unattended login. It adopts a multi-mode data capture method to locate, extract, and collect patient medical data for heterogeneous medical business systems with different interface forms. S2 provides execution support for the patient medical data collection process and the patient medical data quality control process, manages valid session information after login, reuses sessions within the validity period, creates a multi-threaded execution environment, schedules multiple data acquisition and processing tasks in parallel, and executes intelligent fault-tolerant retry strategies when network requests are abnormal. S3. Read and parse the preset externalized medical quality control rules to form a standardized set of quality control rules, construct a directed dependency graph between the quality control rules and the underlying data fields, configure a one-to-one mapping index between the field missing status and the rule execution logic, and limit the field missing status to the types of not collected, not synchronized, unparseable or pending confirmation. S4. Perform standardized preprocessing operations on the collected patient medical data, extract the 18-digit ID number from the patient medical data, parse the corresponding field of the ID number to obtain the patient's date of birth, calculate the patient's age based on the parsed date of birth, and format the numerical, date, and text data in the patient medical data respectively. S5. Based on the calculated patient age, match the medical quality control standard suitable for the age from the standardized quality control rule set, extract the fields related to the target quality control rule from the preprocessed patient medical data, perform quality control comparison, if the target field data is missing and the comparison fails, traverse the directed dependency graph to retrieve the missing data link and complete the missing reason encoding. S6. Calculate the integrity score of patient medical data using the data incompleteness assessment model trained based on the incomplete sample library, preset the integrity score threshold, compare the integrity score with the threshold, dynamically switch the quality control execution strategy, and if the data integrity is insufficient, downgrade the routine comparison logic to the trend analysis logic and execute the quality control analysis. S7. Based on the quality control judgment results, missing cause codes, and completeness scores, calculate the confidence level of the quality control judgment results, integrate the quality control judgment results, missing cause codes, confidence levels, and generation timestamps to construct polymorphic quality control metadata, and associate and tag the polymorphic quality control metadata to the original patient medical data; S8. Aggregate the collected full-dimensional medical data of patients and the generated polymorphic quality control metadata, and construct a panoramic health view of patients based on the aggregated full-dimensional medical data of patients and polymorphic quality control metadata; S9. Based on the constructed panoramic health view of patients, it provides medical staff with visualization services for patient health data and quality control results.

[0051] Those skilled in the art will understand that the process of implementing all or part of the steps of the above embodiments can be carried out by hardware or by a program instructing the relevant hardware.

[0052] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.

Claims

1. A multi-source heterogeneous data integration and intelligent quality control system for community healthcare, characterized in that, include: Intelligent data acquisition and adaptation unit (1) is used to connect with hospital information system, public health system and heterogeneous medical business system in community medical scenario, complete the generalized automatic login adaptation of each heterogeneous medical business system, and collect patient medical data through multi-mode data capture method; Asynchronous high-performance execution unit (2), the asynchronous high-performance execution unit (2) provides execution support for the patient medical data acquisition process of intelligent data acquisition adaptation unit (1) and the patient medical data quality control process of configurable rule quality control unit (3), and uses session reuse, parallel task scheduling and intelligent fault tolerance retry technology to perform data processing related operations; A configurable rule quality control unit (3) performs quality control on the patient medical data collected by the intelligent data acquisition and adaptation unit (1), loads the externally configured medical quality control rules, constructs a dependency graph between the quality control rules and the underlying data fields, and configures the mapping index between the field missing status and the rule execution logic; performs standardized preprocessing on the patient medical data collected by the intelligent data acquisition and adaptation unit (1), matches the corresponding medical quality control standards to perform quality control comparison, and when the missing data of the target field causes the quality control comparison to fail, it traverses the dependency graph to retrieve the missing data link and encodes the missing reason as not collected, not synchronized, unparseable or pending confirmation type; calculates the integrity score of the input patient medical data through the data incompleteness assessment model trained based on the incomplete sample library, dynamically switches the quality control execution strategy according to the preset integrity score threshold, downgrades the comparison logic to trend analysis logic and performs quality control analysis; generates polymorphic quality control metadata containing quality control judgment results, missing reason type encoding and confidence label, and marks the polymorphic quality control metadata into the original patient medical data; The integrated data display unit (4) provides medical staff with visualization services for patient health data and quality control results. It aggregates the patient's full-dimensional medical data collected by the intelligent data acquisition and adaptation unit (1) and the polymorphic quality control metadata generated by the configurable rule quality control unit (3) to construct a panoramic health view of the patient.

2. The multi-source heterogeneous data integration and intelligent quality control system for community healthcare according to claim 1, characterized in that, The intelligent data acquisition and adaptation unit (1) includes a login agent module (11) and a data capture and parsing module (12), wherein: The login agent module (11) is used to connect with various heterogeneous medical business systems in the community medical scenario, adaptively identify the encryption method of the target system, automatically identify the login verification code and complete fully automatic unattended login. The data capture and parsing module (12) adopts a multi-mode data capture method to complete the location extraction and collection of patient medical data for heterogeneous medical business systems with different interface forms.

3. The multi-source heterogeneous data integration and intelligent quality control system for community healthcare according to claim 1, characterized in that, The asynchronous high-performance execution unit (2) includes a session cache management module (21), a concurrent task scheduling module (22), and an intelligent retry module (23), wherein: The session cache management module (21) is used to manage valid session information after login and reuse sessions that are still valid. The concurrent task scheduling module (22) is used to create a multi-threaded execution environment and schedule multiple data acquisition and processing tasks in parallel. The intelligent retry module (23) is used to execute the intelligent retry strategy when a network request is abnormal.

4. The multi-source heterogeneous data integration and intelligent quality control system for community healthcare according to claim 1, characterized in that, The configurable rule quality control unit (3) includes a rule configuration loading module (31), a data preprocessing module (32), an incomplete adaptive quality control execution module (33), and a polymorphic metadata generation and tagging module (34), wherein: The rule configuration loading module (31) loads the externalized medical quality control rules, constructs a dependency graph between the quality control rules and the underlying data fields, and configures the mapping index between the field missing status and the rule execution logic; The data preprocessing module (32) performs standardized preprocessing operations on the patient medical data collected by the intelligent data acquisition and adaptation unit (1); The incomplete adaptive quality control execution module (33) relies on the preprocessed patient medical data and the loaded medical quality control rules to complete the quality control comparison, data missing link retrieval and dynamic switching of quality control execution strategy; The polymorphic metadata generation and tagging module (34) generates polymorphic quality control metadata and associates the polymorphic quality control metadata with the original patient medical data.

5. The multi-source heterogeneous data integration and intelligent quality control system for community healthcare according to claim 4, characterized in that, The rule configuration loading module (31) includes a rule externalization loading submodule, a dependency graph construction submodule, and a missing mapping index configuration submodule, wherein: The rule externalization loading submodule reads and parses the preset externalized medical quality control rules to form a standardized set of quality control rules; The dependency graph construction submodule constructs a directed dependency graph between quality control rules and underlying data fields, establishing a unique association link between quality control rules and data fields; The missing mapping index configuration submodule configures a one-to-one mapping index between the field missing status and the rule execution logic, and explicitly limits the field missing status to types such as not collected, not synchronized, unparseable or pending confirmation, so as to provide accurate matching basis for quality control execution in the case of data missing.

6. The multi-source heterogeneous data integration and intelligent quality control system for community healthcare according to claim 5, characterized in that, The standardized preprocessing operation of the data preprocessing module (32) includes the following steps: S32.1 Extract the 18-digit ID number from the patient's medical data collected by the intelligent data acquisition and adaptation unit (1), and parse the corresponding field of the ID number to obtain the patient's date of birth; S32.2 Calculate the patient's age based on the patient's birth date obtained from the analysis. ; S32.3 Format the numerical, date, and text data in the patient's medical data respectively.

7. The multi-source heterogeneous data integration and intelligent quality control system for community healthcare according to claim 6, characterized in that, The quality control comparison and strategy dynamic switching process of the incomplete adaptive quality control execution module (33) includes the following steps: S33.1, Patient age obtained from data preprocessing module (32) From the standardized quality control rule set of the rule configuration loading module (31), a medical quality control standard suitable for the patient's age is matched; S33.2 Extract the fields related to the target quality control rules from the preprocessed patient medical data, perform quality control comparison, and if the comparison fails due to missing data in the target field, traverse the directed dependency graph constructed by the rule configuration loading module (31), retrieve the missing data links, and complete the missing reason encoding. S33.3 Calculate the integrity score of patient medical data using a data incompleteness assessment model. ; S33.

4. Based on the preset integrity scoring threshold, compare the integrity scores. The quality control execution strategy is dynamically switched according to the threshold value; if the completeness is insufficient, the regular comparison logic is downgraded to trend analysis logic, and the trend prediction value is used to predict the value. Complete the quality control analysis.

8. The multi-source heterogeneous data integration and intelligent quality control system for community healthcare according to claim 7, characterized in that, The polymorphic metadata generation and marking process of the polymorphic quality control metadata generation module (34) includes the following steps: S34.1 Quality control judgment results, missing cause codes, and integrity scores output by the incomplete adaptive quality control execution module (33). The confidence level of the quality control judgment result is calculated. ; S34.2, Integrate quality control judgment results, missing cause codes, and confidence levels. And generate timestamps to construct polymorphic quality control metadata; S34.

3. Associate the generated polymorphic quality control metadata with the original patient medical data collected by the intelligent data acquisition adapter unit (1).

9. The multi-source heterogeneous data integration and intelligent quality control system for community healthcare according to claim 1, characterized in that, The integrated data display unit (4) includes a data aggregation module (41), a view construction module (42), and a visualization display module (43), wherein: The data aggregation module (41) connects to the intelligent data acquisition adaptation unit (1) and the configurable rule quality control unit (3) to aggregate the patient's full-dimensional medical data and polymorphic quality control metadata; The view construction module (42) constructs a panoramic health view of the patient based on the aggregated full-dimensional medical data and polymorphic quality control metadata. The visualization module (43) provides visualization services of patient health data and quality control results to medical staff based on the panoramic health view of the patient.

10. A method for multi-source heterogeneous data integration and intelligent quality control for community healthcare, based on the multi-source heterogeneous data integration and intelligent quality control system for community healthcare as described in any one of claims 1-9, characterized in that, Includes the following steps: S1. Connects with hospital information systems, public health systems, and heterogeneous medical business systems in community healthcare scenarios, and completes universal automatic login adaptation for various heterogeneous medical business systems. It adaptively identifies the encryption method of the target system, automatically identifies the login verification code, and completes fully automatic unattended login. It adopts a multi-mode data capture method to locate, extract, and collect patient medical data for heterogeneous medical business systems with different interface forms. S2 provides execution support for the patient medical data collection process and the patient medical data quality control process, manages valid session information after login, reuses sessions within the validity period, creates a multi-threaded execution environment, schedules multiple data acquisition and processing tasks in parallel, and executes intelligent fault-tolerant retry strategies when network requests are abnormal. S3. Read and parse the preset externalized medical quality control rules to form a standardized set of quality control rules, construct a directed dependency graph between the quality control rules and the underlying data fields, configure a one-to-one mapping index between the field missing status and the rule execution logic, and limit the field missing status to the types of not collected, not synchronized, unparseable or pending confirmation. S4. Perform standardized preprocessing operations on the collected patient medical data, extract the 18-digit ID number from the patient medical data, parse the corresponding field of the ID number to obtain the patient's date of birth, calculate the patient's age based on the parsed date of birth, and format the numerical, date, and text data in the patient medical data respectively. S5. Based on the calculated patient age, match the medical quality control standard suitable for the age from the standardized quality control rule set, extract the fields related to the target quality control rule from the preprocessed patient medical data, perform quality control comparison, if the target field data is missing and the comparison fails, traverse the directed dependency graph to retrieve the missing data link and complete the missing reason encoding. S6. Calculate the integrity score of patient medical data using the data incompleteness assessment model trained based on the incomplete sample library, preset the integrity score threshold, compare the integrity score with the threshold, dynamically switch the quality control execution strategy, and if the data integrity is insufficient, downgrade the routine comparison logic to the trend analysis logic and execute the quality control analysis. S7. Based on the quality control judgment results, missing cause codes, and completeness scores, calculate the confidence level of the quality control judgment results, integrate the quality control judgment results, missing cause codes, confidence levels, and generation timestamps to construct polymorphic quality control metadata, and associate and tag the polymorphic quality control metadata to the original patient medical data; S8. Aggregate the collected full-dimensional medical data of patients and the generated polymorphic quality control metadata, and construct a panoramic health view of patients based on the aggregated full-dimensional medical data of patients and polymorphic quality control metadata; S9. Based on the constructed panoramic health view of patients, it provides medical staff with visualization services for patient health data and quality control results.