A multi-source heterogeneous clinical data integration platform

Abstract

The application provides a multi-source heterogeneous clinical data integration platform, relates to the technical field of medical data management systems, and is applied to a smart hospital data management system. The platform performs data collection on demand on a plurality of databases with different business purposes in the business system layer of the smart hospital data management system through a data collection component, and publishes the collected clinical data to a Kafka integration engine. According to data application requirements, the clinical data is processed, cleaned and managed through a data management component, the managed clinical data is compared and repaired, and finally the processed clinical data is subscribed to one or more data centers through a subscription component, for data statistical analysis or complex query, to provide data support for upper-layer services and big data applications of the smart hospital, so that the performance problems caused by direct cross-source database access are eliminated, and the data value is fully utilized.

Description

Technical Field

[0001] This invention relates to the field of medical data management system technology, and in particular to a multi-source heterogeneous clinical data integration platform. Background Technology

[0002] Currently, most medical institutions' information systems have only addressed the issues of digitizing, electronicating, and structuring medical records. Hospitals have large volumes of clinical data, which are growing rapidly, but their utilization rate is low. The fundamental problem of integrating and effectively utilizing clinical data has not been solved. Each clinical application system is a data generator, using different database systems and devices to collect and generate data during medical activities. Different data sources use different operating systems and database management systems, have different data storage models and logical structures, and differ in data generation time, data purpose, and code protocols. There is no unified standard in the generation process for different types of data, resulting in data heterogeneity. The coexistence of multiple heterogeneous systems presents numerous management and technical challenges for maintenance personnel. With the continuous addition of new application systems, patient medical records are scattered across different application systems, making them unusable. The high importance and complex relationships of this data, the high requirements for timely fault response, and the large workload of data protection and management have become major challenges facing hospital information management departments. Summary of the Invention

[0003] The purpose of this invention is to provide a multi-source heterogeneous clinical data integration platform that, based on unified rules and metadata, a unified architecture, and unified tools for visual configuration, completes various data services such as the collection, transformation, and processing of source data, thereby meeting the needs of data exchange and data management.

[0004] To achieve the above-mentioned objectives, the specific technical solution provided by this invention is as follows:

[0005] A multi-source heterogeneous clinical data integration platform, the platform being applied to a smart hospital data management system, the platform comprising:

[0006] The data acquisition component is used to collect clinical data from databases of multiple heterogeneous hospital business systems and publish the clinical data to the Kafka integration engine.

[0007] Data governance components are used to process clinical data within the Kafka integration engine;

[0008] The data comparison and repair component is used to compare and repair processed clinical data.

[0009] The data subscription component is used to synthesize the target clinical data in the Kafka integration engine into the data required by the target environment according to the data subscription instructions of the target end, and deliver it to the target end;

[0010] An integrated engine management component is used to uniformly manage all databases within the system and to visualize data service management.

[0011] Furthermore, the data acquisition component specifically includes:

[0012] The full data acquisition module is used to continuously read clinical data from the source database when initially acquiring clinical data, until all clinical data from the source database is obtained. The source database is the database responsible for producing clinical data.

[0013] The capture module is used to continuously monitor the log changes in the databases of various hospital business systems and trigger the incremental collection module based on the log changes.

[0014] The incremental acquisition module is used to acquire incremental clinical data from the source database when the capture module is triggered.

[0015] Furthermore, the data governance component specifically includes:

[0016] The filtering module is used to filter clinical data according to specified conditions;

[0017] The processing module is used to configure the clinical data in the data table by column;

[0018] The event triggering module is used to trigger preset actions through triggers when clinical data produced by the source database changes, thereby enabling the derivation of business actions.

[0019] Furthermore, the data comparison and repair component specifically includes:

[0020] The data comparison module is used to compare the clinical data recorded in the source database and the target database, wherein the target database is the database that the target end is responsible for receiving and storing clinical data.

[0021] The data repair module is used to repair clinical data within a specified range, or to repair clinical data in a target database based on changes in clinical data in the source database within a specified time period.

[0022] Furthermore, the data subscription component specifically includes:

[0023] The data offloading module is used to offload clinical data to different target databases;

[0024] The data combination module is used to combine any data table in the Kafka integration engine according to the data subscription instructions from the target end.

[0025] Furthermore, the data subscription component specifically includes:

[0026] Microservice containers are used to manage microservice modules adapted to different database or non-database environments.

[0027] The deployment module is used to identify whether the microservice module has been deployed in the target environment when the data subscription component sends clinical data to the target environment according to the subscription instruction. If it has not been deployed, the module will retrieve the corresponding microservice module from the microservice container according to the target environment type and architecture, and send the microservice module and clinical data to the target environment to deploy the microservice module locally in the target environment.

[0028] The flow management module is used to receive flow monitoring data reported by the microservice module, generate a data flow diagram through a graph database based on the source database of the clinical data targeted by the subscription instruction, the content of the subscription instruction, and the flow monitoring data, and perform source traceability management of the clinical data based on the data flow diagram;

[0029] The flow monitoring data is used to characterize the flow information of clinical data after it is sent to the target database.

[0030] Furthermore, the data subscription component specifically includes:

[0031] The graph parsing module is used to parse the data flow graph and obtain user information for accessing clinical data from the target environment;

[0032] The access assessment module is used to obtain user information from the graph analysis module, query user access control resource values ​​based on user information, assess the rationality of user access to clinical data, and control user access control resource values ​​based on the assessment results.

[0033] Furthermore, an assessment of the legitimacy of users accessing clinical data is conducted, specifically including the following steps:

[0034] S1. Query the user's job position and job content based on the user information, and at the same time construct a dual-tower DNN model;

[0035] S2. Input the user’s job position, job content and accessed clinical data into the dual-tower DNN model, calculate the probability of the user accessing the clinical data and obtain the user access probability value.

[0036] S3. Query other users who have the same job position and job content as the user, calculate the probability that other users access the same clinical data, and obtain the group access probability value;

[0037] S4. Calculate the user-group deviation value based on the user access probability value and the group access probability value, and determine whether the user-group deviation value is less than the preset deviation threshold. If it is not less than the preset deviation threshold, reduce the user access resource control value based on the user-group deviation value.

[0038] Furthermore, the microservice module is specifically used to: generate a unique digital watermark based on the information of the clinical data acquisition party when transmitting clinical data to the target environment, and add the digital watermark to the clinical data;

[0039] The access assessment module is also used to parse the digital watermark of abnormally leaked clinical data, obtain information about the clinical data acquisition party, and adjust the access control resource values ​​of the clinical data acquisition party.

[0040] Furthermore, the integrated engine management component specifically includes:

[0041] The database management module is used to assign a unified number to all databases in the smart hospital data management system, and to synchronize and manage the databases based on the number.

[0042] The visualization management module is used to visualize and implement data node management, data exchange service modeling, data processing modeling, shared service modeling, data quality management, service catalog management, resource catalog management, system operation and monitoring management.

[0043] Compared with the prior art, the beneficial effects of the present invention are:

[0044] 1. This invention provides a multi-source heterogeneous clinical data integration platform. Through a data acquisition component, it collects data on demand from multiple databases with different business applications within the business system layer of a smart hospital data management system. The collected clinical data is then published to a Kafka integration engine. Based on data application needs, a data governance component processes and cleans the clinical data. The processed clinical data is then compared and repaired. Finally, the processed clinical data is subscribed to one or more data centers through a data subscription component for data statistical analysis or complex queries. This provides data support for upper-layer services and big data applications in smart hospitals, thereby eliminating performance issues caused by direct cross-source database access and fully utilizing data value.

[0045] 2. In this invention, the data subscription component uses a dual-tower DNN model to evaluate the rationality of user access to clinical data, adjusts the user access control resource value, and manages user access permissions based on the user access control resource value. This ensures medical efficiency while preventing unreasonable access to clinical data and reducing the possibility of clinical data leakage. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only preferred embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 This is a schematic diagram of the overall structure of a multi-source heterogeneous clinical data integration platform provided in an embodiment of the present invention.

[0048] Figure 2 This is a schematic diagram of the overall architecture of the smart hospital data management system provided in an embodiment of the present invention.

[0049] Figure 3 This is a schematic diagram of the clinical data access rationality assessment process provided in the embodiments of the present invention. Detailed Implementation

[0050] The principles and features of the present invention are described below with reference to the accompanying drawings. The listed embodiments are only used to explain the present invention and are not intended to limit the scope of the present invention.

[0051] Reference Figure 1 This embodiment provides a multi-source heterogeneous clinical data integration platform, which is applied to a smart hospital data management system. The smart hospital data management system includes, from bottom to top, a business system layer, an integration layer, a data center layer, and a referencing layer. The platform is located in the integration layer and specifically includes:

[0052] The data acquisition component is used to collect clinical data from databases of multiple heterogeneous hospital business systems and publish the clinical data to the Kafka integration engine.

[0053] Data governance components are used to process clinical data within the Kafka integration engine;

[0054] The data comparison and repair component is used to compare and repair processed clinical data.

[0055] The data subscription component is used to synthesize the target clinical data in the Kafka integration engine into the data required by the target environment according to the data subscription instructions of the target end, and deliver it to the target end;

[0056] An integrated engine management component is used to uniformly manage all databases within the system and to visualize data service management.

[0057] This embodiment integrates database data from various heterogeneous hospital business systems within the smart hospital data management system using the aforementioned platform, adhering to a unified data management mechanism. This ensures data accuracy, consistency, and integrity, achieving "data from the same source and data used according to the same standard," and meeting the data application needs of "cross-departmental and cross-system" collaboration. The platform is compatible with three commonly used databases in hospital business systems: Oracle, SQL Server, and MySQL, as well as mainstream commercial and open-source database products, including but not limited to: domestic databases such as DM, Kingbase, Nanda General, OceanBase, and GaussDB; and international databases such as DB2, PostgreSQL, and Sybase.

[0058] Specifically, the data acquisition component can publish the collected clinical data to the KAFKA cluster engine for unified management as needed, implement its business logic according to requirements, and support the capture, acquisition, and publishing of multiple databases such as ORACLE, SQL Server, and MySQL. In this embodiment, the data acquisition component includes a full acquisition module, an incremental acquisition module, and a capture module.

[0059] The full data acquisition module continuously reads clinical data from the source database during the initial acquisition, until all clinical data is obtained from the source database (the database responsible for producing clinical data). The capture module continuously monitors log changes in the databases of various hospital business systems and triggers the incremental acquisition module based on these changes. In other words, when clinical data in a hospital business system changes—for example, through additions or modifications—the capture module triggers the incremental acquisition module. After being triggered by the capture module, the incremental acquisition module collects incremental clinical data from the source database.

[0060] The data acquisition component operates in relation to the database. Data acquisition can be achieved as long as the database software can be deployed on the corresponding server, operating system, and network environment. While it places certain demands on server performance and network transmission, these requirements are not strongly correlated. First, the performance overhead on the server and network is related to the amount of data being acquired. Full data acquisition incurs continuous performance overhead on server CPU, memory, disk reads, and network transmission, while incremental acquisition incurs only minor and temporary performance overhead. Second, the data acquisition process reads data from the source database on demand, based on the data requirements of the target end. This might involve acquiring the entire table or only rows or columns that meet certain conditions. Therefore, in practical use, the number of acquisition processes is planned based on the data acquisition requirements, the scale of data acquisition, and server resource usage. The data acquisition speed and task execution time are directly related to the server's disk read / write performance.

[0061] The data governance component provides various data processing actions such as filtering, transformation, sorting, and event triggering for the data streams collected by the data acquisition component. It is a component in the platform that provides data processing services and is completed within the Kafka integration engine.

[0062] In this embodiment, the data governance component specifically includes a filtering module, a processing module, and an event triggering module.

[0063] The filtering module is used to filter clinical data according to specified conditions. For example, the filtering module supports operations including but not limited to Insert, Update, and Delete, and the filtering conditions support combinations of WHERE conditions and SQL statement integration.

[0064] The processing module is used to configure clinical data in the data table column by column. It supports adding ADD, deleting DROP, modifying MODIFY, and renaming; it supports string processing using data processing functions (such as LTRIM, RTRIM, TRIM, UPPER, LOWER, SUBSTR, CONCAT, REPLACE, etc.), and processing of numerical and time-formatted data using numeric functions (NUMBER, NUMBIN, NUMHEX, COMPUTE, MOD, ROUND, etc.) and time functions (DATE, DATENOW, DATEDIFF, DATEADD, etc.); it also supports binary and hash functions.

[0065] The event-triggered module is used to trigger preset actions when clinical data generated from the source database changes, thereby enabling business actions to derive from these actions. The core function of the event-triggered module is to achieve real-time ETL data transformation with zero impact on production. Supported trigger actions include, but are not limited to: SQL statements, stored procedures (database is not limited), and BAT / SHELL processing.

[0066] In this embodiment, the data governance component can also implement various data transformation methods, including string conversion, field assignment, time-based conversion, mathematical operations, ID card format conversion, etc.; and perform quality checks on clinical data according to data logic judgment rules, sending data with normal quality to the target end, and routing data with quality problems to a specified database table or data file.

[0067] The data logic judgment rules include, but are not limited to: format matching checks (such as date format, data format, ID card format, custom format, etc.), string logic checks (contains, ends with, starts with, in list, equals, etc.), check for empty content, duplicate record check, range check (such as within a list, within a dictionary or code table, contains, equals), foreign key association check between tables, logic checks (=, >, >=, <, <=, is empty, is not empty, <And<, <=And<, <And<=, <=And<=, is true, is false, etc.), composite logic checks (combinations of and, or, &&, || of the above logics), custom logic checks, etc. At the same time, the data governance component can visually configure the data logic judgment rules.

[0068] On the other hand, the data governance component supports multiple routing strategies. The routing conditions can be logical judgments, or can be methods such as equals, not equals, less than, less than or equal to, greater than, greater than or equal to, greater than and less than, greater than or equal to and less than, greater than and less than or equal to, greater than or equal to and less than or equal to, rule expression, is empty, is not empty, in list, contains, starts with, ends with, is true, is false, etc. Data routing can also be a combination of conditions, which can be and or Or, &&, ||, etc. While meeting the above conditions, it supports operations of where conditions such as IN / NOT IN, making the business writing more flexible and ensuring the business development efficiency. The data governance component also supports the execution of SQL statements in any database and any node, ensuring that the business can be extended as much as possible to support various applicable business logics and more effectively ensure the normal operation of the business. For some SQLs, there may be relationships such as data mapping matching. The data governance component can support the results after SQL queries to be cached in memory, reducing the pressure on the verification library and effectively improving the data verification efficiency.

[0069] In this embodiment, the data comparison and repair component includes a data comparison module and a data repair module.

[0070] Among them, the data comparison module is used to compare the clinical data of the source database and the target database records. The target database is the database responsible for receiving and storing clinical data at the target end. The data comparison module supports data comparison at the number level. After data shunting, the data comparison module can perform statistics and comparison on the shunted full-volume and real-time data. The data comparison module also supports row-level data comparison with composite conditions and supports data comparison using methods such as DBLINK. The data comparison module can also perform data comparison on actions such as insert, update, and delete. Data comparison includes two modes: comparing primary keys and comparing contents.

[0071] The data repair module is used to repair clinical data within a specified range. It can perform full data repair at the table level or row level; or repair clinical data in the target database based on changes in clinical data in the source database within a specified time period.

[0072] In this embodiment, the data subscription component includes a data splitting module and a data combining module. The data splitting module is used to distribute clinical data to different target databases. The data combining module is used to combine any data tables in the Kafka integration engine according to the data subscription instructions from the target end.

[0073] The data subscription component uses a data combination module to combine clinical data into the data required by the target environment, and then delivers the combined data to the designated target through a subscription method. The data subscription component supports both database and non-database environments as the target. For example, in practical applications, through the data subscription component, real-time information such as medical examination appointments, queue times, and critical values ​​can be displayed in real-time at designated locations or pushed to relevant stakeholders.

[0074] As one possible implementation, the data subscription component also includes a microservice container, a deployment module, and a flow management module.

[0075] The microservice container is used to manage microservice modules adapted to different database or non-database environments. This implementation pre-develops various compatible microservice modules for different architectures and types of database or non-database environments at the application layer and stores them in the microservice container.

[0076] The deployment module is used to identify whether the microservice module has been deployed in the target environment when the data subscription component sends clinical data to the target environment according to the subscription instruction. If it has not been deployed, the module retrieves the corresponding microservice module from the microservice container according to the target environment type and architecture, and sends the microservice module and clinical data to the target environment to deploy the microservice module locally in the target environment.

[0077] The flow management module receives flow monitoring data reported by the microservice module. Based on the source database of the clinical data targeted by the subscription instruction, the content of the subscription instruction, and the flow monitoring data, it generates a data flow graph using a graph database. The flow graph is then used to manage the source of the clinical data. The flow monitoring data characterizes the flow information of clinical data after it is sent to the target database.

[0078] In this embodiment, the data flow graph includes nodes and edges. Nodes represent entities, which can be data itself, or systems, databases, users, etc. Edges represent the relationship between two nodes. In the data flow graph, edges are mainly responsible for representing the flow direction of clinical data; that is, edges are directed edges.

[0079] Clinical data records a large amount of personal information about individuals, inevitably including private information—personal details that patients often do not wish to disclose when receiving medical services. In the integration of multi-source, heterogeneous clinical data, the extensive use and analysis of this data makes privacy protection difficult and increases the possibility of leakage. This implementation deploys microservice modules adapted to various environments to the target environment, monitoring the flow of clinical data within that environment. This allows for tracing the data's next step in the application layer even after it leaves the integration layer, thereby monitoring for potential leakage risks.

[0080] As a further possible implementation, the data subscription component also includes a graph parsing module and an access evaluation module.

[0081] The graph parsing module is used to parse the data flow graph and obtain user information for accessing clinical data from the target environment. In this embodiment, the graph parsing module identifies the next node connected to the node corresponding to the target environment to determine the next entity information to which the clinical data flows from the target environment.

[0082] The access assessment module is used to obtain user information from the graph analysis module, query user access control resource values ​​based on user information, assess the rationality of user access to clinical data, and control user access control resource values ​​based on the assessment results.

[0083] For example, the platform can periodically allocate a certain amount of access control resource value to each user and control the user's access to clinical data based on the access control resource value. If a user accesses clinical data with reasonable work intent or purpose, the access can be considered reasonable. If a user accesses clinical data without reasonable work intent or purpose, their access control resource value can be reduced. When the access control resource value falls below a preset resource value threshold, the user's access permissions can be restricted. To ensure that users can obtain clinical data in a timely manner for decision-making and avoid affecting medical efficiency, the assessment of the reasonableness of a user's access to clinical data can be conducted after the user has accessed the clinical data.

[0084] For example, refer to Figure 2 The assessment of the legitimacy of user access to clinical data includes the following steps:

[0085] S1. Query the user's job position and job content based on the user information, and at the same time construct a dual-tower DNN model.

[0086] S2. Input the user's job position, job content, and accessed clinical data into the dual-tower DNN model, calculate the probability of the user accessing the clinical data, and obtain the user access probability value.

[0087] In this implementation, the dual-tower DNN model includes a first-tower network and a second-tower network. The user's job title and job content are input into the first-tower network for processing, outputting a job intent vector. Simultaneously, the clinical data content accessed by the user is input into the second-tower network, outputting a clinical data feature vector. After the job intent vector and clinical data feature vector are input into a fusion layer, they undergo dimensionality reduction through one or more fully connected layers. Finally, a sigmoid activation function is used to process the dimensionality-reduced features, outputting a user access probability value between 0 and 1.

[0088] S3. Query other users who have the same job position and job content as the user, calculate the probability of other users accessing the same clinical data, and obtain the group access probability value.

[0089] S4. Calculate the user-group deviation value based on the user access probability value and the group access probability value, and determine whether the user-group deviation value is less than the preset deviation threshold. If it is not less than the preset deviation threshold, reduce the user access resource control value based on the user-group deviation value.

[0090] This implementation uses a dual-tower DNN model to estimate the probability of a designated user with the same job position and content, as well as other users, accessing target clinical data (the clinical data accessed by the user). Based on the difference in access probabilities, it determines whether the user's choice to access the target clinical data deviates significantly from the group's objective; that is, whether the user-group deviation value exceeds a preset deviation threshold. If so, it indicates that the user's purpose in accessing the target clinical data is likely not for work purposes, and the user's access resource control value is reduced. If it is less than the threshold, the user's access resource control value can be maintained.

[0091] As a further possible implementation, after the microservice module is deployed to the target environment, when clinical data is transmitted externally from the target environment, it generates a unique digital watermark based on the information of the clinical data recipient—such as account and IP address—and adds the digital watermark to the clinical data. The access assessment module is also used to parse the digital watermark carried by the clinical data to read information from it. In the event of a clinical data breach, the digital watermark carried by the leaked clinical data is parsed to obtain information about the data recipient, thereby tracing the source of the leak. If it is a system user, their access control resource values ​​are reduced or adjusted.

[0092] In this embodiment, the integrated engine management component specifically includes a database management module and a visualization management module.

[0093] The database management module is used to assign a unified number to all databases in the smart hospital data management system, enabling synchronization and management between databases based on these numbers. This module can rearrange and encode all databases within the system, establishing a unified database numbering system. Synchronization and management between databases rely entirely on these numbers.

[0094] The visualization management module is used to visualize and implement data node management, data exchange service modeling, data processing modeling, shared service modeling, data quality management, service catalog management, resource catalog management, system operation and monitoring management.

[0095] In this embodiment, the management platform is presented via a web interface, enabling all platform management tasks to be completed within a single interface. It provides visualized management of data nodes, exchange service modeling, data processing modeling, shared service modeling, data quality management, service catalog management, resource catalog management, and operation and monitoring management. Service models of corresponding types are generated through the visual operation interface of each service. Various services such as file transfer, ETL (Extract-Transform-Load), data exchange and processing, data quality, secure sharing, and workflow can be created according to business needs. These services can be categorized and coded as needed to form a service catalog, facilitating reuse, editing, and secure authorization. The platform also provides functions such as service creation, editing, deletion, deployment, and viewing.

[0096] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A multi-source heterogeneous clinical data integration platform, characterized in that, The platform is used in a smart hospital data management system, and the platform includes: The data acquisition component is used to collect clinical data from databases of multiple heterogeneous hospital business systems and publish the clinical data to the Kafka integration engine. Data governance components are used to process clinical data within the Kafka integration engine; The data comparison and repair component is used to compare and repair processed clinical data. The data subscription component is used to synthesize target clinical data from the Kafka integration engine into the data required by the target environment according to the data subscription instructions from the target end, and deliver it to the target end. It also evaluates the reasonableness of user access to clinical data and controls user access control resource values ​​based on the evaluation results. Specifically, it includes the following operations: S1. Query the user's job position and job content based on the user information, and at the same time construct a dual-tower DNN model; S2. Input the user’s job position, job content and accessed clinical data into the dual-tower DNN model, calculate the probability of the user accessing the clinical data and obtain the user access probability value. S3. Query other users who have the same job position and job content as the user, calculate the probability that other users access the same clinical data, and obtain the group access probability value; S4. Calculate the user-group deviation value based on the user access probability value and the group access probability value, and determine whether the user-group deviation value is less than the preset deviation threshold. If it is not less than the preset deviation threshold, reduce the user access resource control value based on the user-group deviation value. An integrated engine management component is used to uniformly manage all databases within the system and to visualize data service management. The data subscription component specifically includes: The data offloading module is used to offload clinical data to different target databases; The data combination module is used to combine any data table in the Kafka integration engine according to the data subscription instructions from the target end; Microservice containers are used to manage microservice modules adapted to different database or non-database environments. The deployment module is used to identify whether the microservice module has been deployed in the target environment when the data subscription component sends clinical data to the target environment according to the subscription instruction. If it has not been deployed, the module will retrieve the corresponding microservice module from the microservice container according to the target environment type and architecture, and send the microservice module and clinical data to the target environment to deploy the microservice module locally in the target environment. The flow management module is used to receive flow monitoring data reported by the microservice module, generate a data flow diagram through a graph database based on the source database of the clinical data targeted by the subscription instruction, the content of the subscription instruction, and the flow monitoring data, and perform source traceability management of the clinical data based on the data flow diagram; The flow monitoring data is used to characterize the flow information of clinical data after it is sent to the target database; The graph parsing module is used to parse the data flow graph and obtain user information for accessing clinical data from the target environment; The access assessment module is used to obtain user information from the graph analysis module, query user access control resource values ​​based on user information, assess the rationality of user access to clinical data, and control user access control resource values ​​based on the assessment results.

2. The multi-source heterogeneous clinical data integration platform according to claim 1, characterized in that, The data acquisition component specifically includes: The full data acquisition module is used to continuously read clinical data from the source database when initially acquiring clinical data, until all clinical data from the source database is obtained. The source database is the database responsible for producing clinical data. The capture module is used to continuously monitor the log changes in the databases of various hospital business systems and trigger the incremental collection module based on the log changes. The incremental acquisition module is used to acquire incremental clinical data from the source database when the capture module is triggered.

3. The multi-source heterogeneous clinical data integration platform according to claim 1, characterized in that, The data governance components specifically include: The filtering module is used to filter clinical data according to specified conditions; The processing module is used to configure the clinical data in the data table by column; The event triggering module is used to trigger preset actions through triggers when clinical data produced by the source database changes, thereby enabling the derivation of business actions.

4. The multi-source heterogeneous clinical data integration platform according to claim 1, characterized in that, The data comparison and repair component specifically includes: The data comparison module is used to compare the clinical data recorded in the source database and the target database, wherein the target database is the database that the target end is responsible for receiving and storing clinical data. The data repair module is used to repair clinical data within a specified range, or to repair clinical data in a target database based on changes in clinical data in the source database within a specified time period.

5. The multi-source heterogeneous clinical data integration platform according to claim 1, characterized in that, The microservice module is specifically used to: generate a unique digital watermark based on the information of the clinical data acquisition party when transmitting clinical data to the target environment, and add the digital watermark to the clinical data; The access assessment module is also used to parse the digital watermark of abnormally leaked clinical data, obtain information about the clinical data acquisition party, and adjust the access control resource values ​​of the clinical data acquisition party.

6. The multi-source heterogeneous clinical data integration platform according to claim 1, characterized in that, The integrated engine management component specifically includes: The database management module is used to assign a unified number to all databases in the smart hospital data management system, and to synchronize and manage the databases based on the number. The visualization management module is used to visualize and implement data node management, data exchange service modeling, data processing modeling, shared service modeling, data quality management, service catalog management, resource catalog management, system operation and monitoring management.

Images