A primary public health multi-system data intercommunication and privacy computing collaborative management system and method

Abstract

The present application is suitable for data intercommunication and privacy calculation of at least two heterogeneous primary public health systems such as resident health records, chronic disease follow-up, maternal and child health care, planned immunization and the like in low-resource scenarios. The system comprises a data standardization layer, an event-driven routing layer and a privacy calculation layer. The data standardization layer converts heterogeneous raw data into unified FHIR data sets, forms a unified data base for cross-system routing and local federated learning training, and generates a routing display pseudonym and a stable alignment pseudonym. The event-driven routing layer routes the standardized FHIR data exchange package on demand when a preset business event is triggered, without periodic full data synchronization. The privacy calculation layer coordinates multi-node training based on a longitudinal federated learning framework, and the node agent is deployed in a lightweight manner; each node aligns the common samples through lightweight PSI based on a Bloom filter, only interacts with encrypted model parameters, and the original business data does not leave the local security domain.

Description

Technical Field

[0001] This invention relates to the field of medical informatics and data security technology, specifically to a collaborative management system and method that is adapted to multi-heterogeneous systems, low-bandwidth private networks, and low-configuration hardware scenarios in primary public health, and integrates HL7 FHIR standard mapping, event-driven routing, lightweight PSI, and vertical federated learning. Background Technology

[0002] In primary public health services, resident health record systems, chronic disease follow-up management systems, maternal and child health systems, and planned immunization systems are typically built by different vendors, resulting in significant differences in technical architecture, database structure, and data standards, leading to data silos between systems. Existing data interoperability solutions mainly include ETL centralized synchronization, point-to-point customized interfaces, FHIR data conversion, event-driven data sharing, and medical federated learning.

[0003] ETL centralized synchronization solutions periodically extract data from various systems to a regional platform, resulting in poor real-time performance. Furthermore, centralized storage of raw business data introduces significant privacy risks and storage costs. Point-to-point customized interface solutions allow for the development of dedicated interfaces between two systems, but the interface size rapidly expands with the number of systems, leading to high coupling and maintenance difficulties. FHIR data conversion solutions primarily address data format standardization, but typically do not further integrate the standardized results as a unified input for federated learning training, nor do they resolve sample alignment and privacy-preserving computation loop issues under low-bandwidth conditions at the grassroots level. Event-driven data sharing solutions can achieve data access based on business changes, improving collaborative real-time performance, but most solutions do not form a closed loop with privacy-preserving computation training. Medical federated learning solutions can protect raw data from leaving the domain, but existing solutions do not adequately consider heterogeneous public health data alignment, low-bandwidth sample alignment, and low-configuration deployments at the grassroots level.

[0004] Therefore, a solution is needed for low-resource scenarios at the grassroots level, which uses the FHIR unified data foundation to simultaneously support on-demand routing and privacy-preserving computation training, and de-identifies the relationship between cross-institutional sample alignment by using stable alignment of pseudonyms and lightweight PSI processing. Summary of the Invention

[0005] The technical problem this invention aims to solve is that existing interoperability solutions for primary public health systems cannot simultaneously meet the requirements of low-resource deployment, interoperability of heterogeneous systems, event-driven sharing, original data not leaving the domain, and stable alignment of cross-institutional samples. In particular, when the same patient participates in follow-up, testing, and joint modeling across dates and institutions, the de-identification method of simply adding salt on a daily basis will lead to unstable alignment of federated learning samples, while plaintext alignment will bring privacy compliance risks.

[0006] To achieve the above objectives, this invention provides a collaborative management system for data interoperability and privacy computing across multiple public health systems at the grassroots level. This system is applicable to at least two heterogeneous systems in low-resource scenarios at the grassroots level, including resident health record systems, chronic disease follow-up management systems, maternal and child health systems, and planned immunization systems. The low-resource scenarios at the grassroots level include: the systems are deployed on a grassroots health private network with a bandwidth of no more than 100Mbps, and each participating node server has a configuration of no more than 4 cores and 8GB of RAM; and each of the heterogeneous systems has a different manufacturer, technical architecture, and data standards.

[0007] The system includes:

[0008] The data standardization layer is configured to read raw data from multiple heterogeneous primary public health systems and convert it into a unified FHIR format dataset according to the HL7 FHIRR4 standard, forming a unified data foundation for cross-system routing and local federated learning training. During the conversion process, the data standardization layer generates two types of de-identified identifiers and replaces the plaintext of direct identifiers with corresponding pseudonyms when outputting the FHIR format dataset. One type is a routing display pseudonym used for event routing and cross-system display, and the other is a stable alignment pseudonym used for longitudinal federated learning sample alignment. This stable alignment pseudonym ensures that the same patient remains consistent across dates within the same institution, and that different institutions cannot infer the original identity from the stable alignment pseudonym.

[0009] An event-driven routing layer, connected to the data standardization layer, is configured to monitor preset business events in the grassroots public health business flow. When the preset business event meets the routing conditions defined by the Subscription resource based on HL7 FHIR R4, the corresponding FHIR format dataset is encapsulated into a data exchange packet, and the FHIRRESTful API of the target system is called to send the encapsulated data exchange packet to the target system. The cross-system sharing process does not perform periodic full data synchronization and does not require the target system to parse custom extended fields.

[0010] The privacy computing layer is configured to respond to cross-system data analysis requests by distributing a global model to each participating node through a regional central coordinator. Each node performs local training of longitudinal federated learning based on locally stored FHIR format datasets through a lightweight node agent, and only exchanges model update parameters or encrypted gradients protected by homomorphic encryption or differential privacy through the coordinator or secure inter-node channels.

[0011] Each node determines a common training sample set based on the stable aligned pseudonyms through the intersection of lightweight privacy sets (PSI).

[0012] The original business data is kept in the local security domain of each node. The FHIR format dataset serves as a unified input for both event-driven routing and vertical federated learning training. The data flowing across systems includes standardized FHIR intermediate data and encrypted model update parameters.

[0013] In the system described in this invention, the route display pseudonym is generated by salting a direct identifier using a salt value containing the organization code, current date, and local key material;

[0014] The stable alignment pseudonym uses a pseudonym identifier generated based on the institution code, fixed local key material, and the patient's local number within the institution, ensuring that the same patient remains consistent across dates within the same institution.

[0015] The system described in this invention includes a unified data foundation comprising an FHIR resource repository or an FHIR data object cache deployed in the local security domain of each organization.

[0016] The event-driven routing layer directly reads the FHIR format dataset to generate routing data exchange packets, and the privacy computing layer directly reads the FHIR format dataset for feature extraction and local training, without repeatedly extracting and transforming the original data from the source system.

[0017] The system of the present invention, wherein the data standardization layer includes an adapter sublayer, a mapping engine, and a terminology standardization unit;

[0018] The adapter sublayer adapts to the database interface, service interface, or file interface of heterogeneous systems; the mapping engine loads a dynamically updatable YAML format mapping configuration file to map source system fields to FHIR resource fields;

[0019] The terminology standardization unit standardizes non-standard medical terms into standard terms such as SNOMED CT, LOINC, ICD-10, or CVX.

[0020] In the system described in this invention, the terminology standardization unit uses a pre-trained BiLSTM-CRF model to parse unstructured text such as chief complaint and present medical history, extracts medical entities, and maps the extracted medical entities to SNOMEDCT, LOINC, or ICD-10 standard terminology sets before filling them into the corresponding FHIR resource fields.

[0021] The BiLSTM-CRF model is pre-trained on a Chinese medical entity recognition dataset and fine-tuned for primary healthcare texts.

[0022] The system of the present invention, wherein the event-driven routing layer includes an event capture unit, a routing policy library, and a service invocation unit;

[0023] The routing policy library defines routing rules based on the standard fields of criteria, status, channel.endpoint, channel.payload, and channel.type of the Subscription resource in HL7 FHIR R4.

[0024] The event capture unit captures business events using at least one of the following methods: database binlog monitoring and business system API interception, and identifies business action types including creation, update, and deletion.

[0025] In the system described in this invention, the privacy computing layer includes a coordinator, a node proxy, and a security aggregation module;

[0026] The coordinator is deployed at the central node of the regional health network and is used for global model initialization, model distribution, and encrypted parameter aggregation.

[0027] The node agent is deployed on the side of each grassroots public health system. It is a lightweight containerized deployment with a CPU usage of no more than 1 core and a memory usage of no more than 1GB. The security aggregation module supports homomorphic encrypted aggregation of model update parameters exchanged by each node, or adds differential privacy noise before the parameters are uploaded.

[0028] Lightweight PSI between nodes is implemented based on Bloom filters. The size of the Bloom filter is dynamically configured from 1MB to 10MB according to the number of patients in primary care institutions. The data volume of a single round of alignment is less than 10MB, and the peak bandwidth usage is no more than 1Mbps.

[0029] In the system described in this invention, the vertical federated learning framework is configured to handle scenarios where the feature spaces of each node are different, with community nodes holding demographic features and follow-up features, and hospital nodes holding laboratory features and examination features.

[0030] Each node exchanges encrypted identifiers generated based on stable aligned pseudonyms through lightweight PSI to determine a common training sample set, and then exchanges encrypted gradients to complete training;

[0031] When the features of community nodes and hospital nodes have low overlap, common patient samples are aligned through PSI, and the expressive power of single-node models is enhanced by combining local samples. Then, joint training is completed by using encrypted model parameter interaction.

[0032] The system described in this invention further includes a privacy de-identification module configured to de-identify direct identifiers during the data mapping and conversion process;

[0033] The route display pseudonyms are used for event routing, cross-system display, and daily auditing. The stable alignment pseudonyms are used for vertical federated learning sample alignment and do not participate in the calculation of the daily changing route display salt value, thereby ensuring the stability of PSI alignment.

[0034] This invention also provides a collaborative management method for data interoperability and privacy computing among multiple systems in primary public health, applicable to at least two heterogeneous systems in low-resource scenarios such as resident health record systems, chronic disease follow-up management systems, maternal and child health systems, and planned immunization systems. The low-resource scenarios include: the method is deployed on a primary health dedicated network with a bandwidth of no more than 100 Mbps, and each participating node server has a configuration of no more than 4 cores and 8GB of RAM; the method includes:

[0035] Standardized procedures: Read raw data from multiple heterogeneous primary public health systems, and reorganize the raw data into a unified FHIR data object according to the HL7 FHIR R4 standard to form a unified data foundation for event routing and federated learning training; during the transformation process, generate route display pseudonyms and stable alignment pseudonyms, and replace the plaintext of direct identifiers with the corresponding pseudonyms when outputting FHIR data objects. The route display pseudonyms change with the date, and the stable alignment pseudonyms ensure that the same patient remains consistent across dates within the same institution.

[0036] Event routing steps: Monitor the grassroots public health business process. When a business event that meets the preset trigger conditions is detected, according to the routing strategy defined based on the FHIR Subscription standard, the FHIR data object is encapsulated into a data exchange packet and sent to the preset target address through the FHIR RESTful API. The cross-system sharing process does not perform periodic full data synchronization and does not require the target system to parse custom extended fields.

[0037] Privacy computation steps: Receive data analysis tasks, the central coordinator distributes the global model, each node performs local training using local FHIR data objects through a lightweight node agent, and only exchanges model update parameters or encrypted gradients protected by homomorphic encryption or differential privacy through the coordinator or secure inter-node channels; each node aligns common samples through a lightweight PSI based on Bloom filters.

[0038] The original business data is retained in the local security domain of each node, and the FHIR data object serves as the unified data foundation for event routing and federated learning training.

[0039] Compared with the prior art, the present invention has the following beneficial effects:

[0040] First, a unified data foundation supports both event routing and federated learning training. This invention uses the FHIR standardized results as a unified input for event routing and model training, avoiding the repetitive ETL processes of route extraction, training extraction, and report extraction in traditional solutions, thus reducing the pressure on the source system and improving data consistency.

[0041] Second, the raw data does not leave the domain, resulting in low privacy risks. The raw business data is only read and standardized within the organization's local security domain. What flows across systems is standardized FHIR intermediate data that has undergone direct identifier de-identification and encrypted model update parameters, which complies with the privacy protection and compliance requirements of primary public health data.

[0042] Third, the two types of pseudonyms are decoupled, balancing the display of de-identification and sample alignment. The routed display pseudonyms support daily auditing, cross-system display, and event routing; the stably aligned pseudonyms support cross-date sample alignment and cannot be reversed to reveal the original identity. This design avoids the problems caused by using only "institution code + date + local key" salted hash, which leads to changes in the identity of the same patient across dates and the inability to stably align federated learning samples.

[0043] Fourth, lightweight PSI is adapted to low-bandwidth private networks. Based on Bloom filters, lightweight PSI keeps the amount of data per round of alignment within a small range, with low peak bandwidth consumption, allowing it to run in parallel with business routing and routine public health reporting traffic in grassroots healthcare private networks.

[0044] Fifth, low-configuration nodes can be deployed. The node agent adopts a containerized, lightweight deployment with limited resource consumption, and can coexist with traditional business systems on a 4-core, 8GB edge server or an institutional server;

[0045] Sixth, it supports low-overlap vertical federated learning. For scenarios where the feature dimensions of community nodes and hospital nodes have low overlap, this invention uses stable pseudonym alignment and lightweight PSI to align common patient samples, and combines local sample enhancement to improve the expressive power of single-node models. Then, it uses encrypted model parameter interaction to complete joint training, thereby improving the overall model performance. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be further described below in conjunction with the accompanying drawings and embodiments. The drawings described below are only some 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 system architecture of the present invention;

[0048] Figure 2 This is a flowchart of the data standardization layer processing of the present invention;

[0049] Figure 3 This is a schematic diagram of the event-driven routing layer logic of the present invention;

[0050] Figure 4 This is a sequence diagram of the vertical federated learning interaction in this invention.

[0051] Figure labeling: 100 - Data standardization layer; 101 - Adapter sublayer; 102 - Mapping engine; 103 - Terminology standardization unit; 200 - Event-driven routing layer; 201 - Event capture unit; 202 - Routing policy library; 203 - Service invocation unit; 300 - Privacy computing layer; 301 - Coordinator; 302 - Node proxy; 303 - Security aggregation module; 400 - Privacy de-identification module. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, a clear and complete description will be provided below in conjunction with the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the protection scope of the present invention.

[0053] like Figure 1-4 As shown, the system includes: a data standardization layer, an event-driven routing layer, and a privacy computing layer. Overall deployment and security boundaries: The system is deployed on a primary healthcare network with a bandwidth not exceeding 100Mbps. The latency from each node to the central server can be less than 10ms, with specific values ​​varying depending on network equipment and physical distance. The test environment can access the business systems of multiple community health service centers, secondary hospitals, district CDC, and district maternal and child health hospitals.

[0054] The data standardization layer 100, event capture unit 201, and node agent 302 are deployed on the side of each organization or on edge servers in the same security domain as their business databases. The server configuration can be 4 cores and 8GB RAM. The regional center coordinator 301 is deployed on the dedicated network center node. Raw business data is read and standardized only within the organization's security domain. The data transferred across systems is standardized FHIR intermediate data and encryption model parameters that have undergone direct identifier de-identification.

[0055] The system also includes a privacy desensitization module 400, which is configured to de-identify direct identifiers during the data mapping and transformation process; route display pseudonyms are used for event routing, cross-system display and daily auditing, and stable alignment pseudonyms are used for vertical federated learning sample alignment, and do not participate in the calculation of daily changing route display salt values, thereby ensuring PSI alignment stability.

[0056] The local security domain defined in this system refers to the trusted network area where the organization's internal business databases, edge standardized services, and node agents are located, distinct from the regional center, the public network, or other areas directly accessible by the organization. Original tables, plaintext direct identifiers, and unmasked text do not leave this security domain.

[0057] A unified data foundation is implemented by having each organization maintain its own local FHIR resource repository or FHIR data object cache. This repository is not a centralized regional database, but rather a local, standardized data view. When the event-driven routing layer needs to push resources such as Observation, Patient, Encounter, Condition, or Immunization, it directly reads the corresponding resources from the local FHIR resource repository. When the privacy-preserving computation layer needs to train a model, it also directly extracts features from the same FHIR resource repository, without having to look up the original tables in the source system.

[0058] This structure reduces redundant ETL and improves the consistency of routing and training data. For example, after a community doctor enters hypertension follow-up records, the data normalization layer 100 converts the records into FHIR Observation resources and writes them to the local FHIR resource library; the event-driven routing layer 200 can generate routing packets based on these resources, and the privacy computing layer 300 can extract features such as systolic blood pressure, diastolic blood pressure, and follow-up time based on these resources for model training.

[0059] Data standardization layer 100 implementation: Data standardization layer 100 includes adapter sublayer 101, mapping engine 102 and terminology standardization unit 103.

[0060] The adapter sublayer 101 supports JDBC adapters, WebService adapters, and file adapters. The JDBC adapter can adapt to databases such as MySQL, Oracle, SQL Server, and PostgreSQL; the WebService adapter can adapt to SOAP 1.1 or SOAP 1.2 services; and the file adapter can adapt to files such as CSV, Excel, XML, and JSON, and automatically recognizes encodings such as UTF-8, GBK, and GB2312.

[0061] The mapping engine 102 loads YAML configurations and supports hot updates. The YAML configurations describe the mapping relationship between source system fields and FHIR resource fields. For example, the systolic blood pressure field in the source system can be mapped to the systolic blood pressure component of the FHIR Observation and bound to LOINC code 8480-6; the diastolic blood pressure field can be mapped to the diastolic blood pressure component and bound to LOINC code 8462-4; LOINC 85354-9 can also be used to represent the blood pressure panel, with further subdivision of systolic and diastolic blood pressure in the component layer.

[0062] The terminology standardization unit 103 includes built-in terminology sets such as SNOMED CT, LOINC, and ICD-10. For vaccination scenarios, CVX vaccine coding can also be introduced, and the coding system http: / / hl7.org / fhir / sid / cvx can be used in FHIR. The terminology mapping table can be stored in Redis, with a query latency of less than 1ms. For unstructured text such as chief complaints and present medical history, the terminology standardization unit 103 can use a pre-trained BiLSTM-CRF model to perform Chinese medical entity recognition, mapping the identified symptoms, diseases, anatomical locations, etc., to the standard terminology set and then filling them into the corresponding FHIR resource fields. Low-confidence entities can retain the original text summary or be marked for manual review, without affecting the routing and training of already structured fields.

[0063] Stable alignment of pseudonyms and privacy desensitization: For direct identifiers such as ID card numbers and mobile phone numbers in Patient resources, two types of identifiers are generated.

[0064] The routing presentation pseudonym is used for event routing, cross-system presentation, and daily auditing. It is generated by salting the direct identifier with SHA-256 hash using the institution code, current date, and local key material as salt, thus allowing it to change daily. The stable alignment pseudonym is used for longitudinal federated learning sample alignment. It is generated using the institution code, fixed local key material, and the patient's local ID within the institution, for example, calculated via HMAC-SHA256 or fixed-salt SHA-256. This ensures that the same patient remains consistent across dates within the same institution, and that different institutions cannot deduce the original identity from this stable alignment pseudonym.

[0065] For example, a patient's local patient ID in the community node is P000123, the institution code is ORG-COMM-01, the fixed local key is K_fixed, and the fixed salt value is S_fixed. The stable alignment pseudonym can then be calculated as HMAC_SHA256, using K_fixed as the key and "ORG-COMM-01|P000123|S_fixed" as the message content. This value remains consistent daily and can be used for cross-day follow-up records, test records, and joint training sample alignment. The route presentation pseudonym can be calculated as SHA256, using "institution code|current date|local key|direct identifier" as input. It changes with the date and is suitable for presentation, auditing, and short-term route tracing, but not as a primary key for cross-date federated learning sample alignment.

[0066] The event-driven routing layer 200 is implemented and includes: an event capture unit 201, a routing policy library 202, and a service invocation unit 203. The event capture unit 201 can capture business events by listening to the MySQL binlog via Canal or by intercepting API calls, and identify the types of business actions, including creation, update, and deletion. The routing policy library 202 matches FHIR resource types and field conditions based on the FHIR Subscription criteria, and combines status, channel.endpoint, channel.payload, and channel.type to determine whether a route is valid and the target address. The event capture unit 201 captures business events using at least one method: database binlog listening or business system API interception, and identifies business action types including creation, update, and deletion.

[0067] Example routing rules are as follows:

[0068] json

[0069] copy

[0070] 1{

[0071] 2 "resourceType": "Subscription",

[0072] 3 "id": "sub-001",

[0073] 4 "status": "active",

[0074] 5 "criteria": "Observation?code=8480-6&value-quantity=gt140|mmHg",

[0075] 6 "channel": {

[0076] 7 "type": "rest-hook",

[0077] 8 "endpoint": "http: / / hospital-lis / fhir / Observation",

[0078] 9 "payload": "application / fhir+json"

[0079] 10}

[0080] 11}

[0081] The above rule states that when a systolic blood pressure observation appears in the local FHIR resource library, and the systolic blood pressure is greater than 140 mmHg, the event-driven routing layer 200 pushes the observation resource to the FHIR RESTful API address specified by the hospital LIS system. If blood pressure panel encoding is used, the criteria can also be written as Observation?code=85354-9, and further determination of whether the systolic blood pressure is greater than 140 mmHg can be made in the component layer or subsequent filtering logic.

[0082] If a push fails, the data can be written to a retry queue and retried once per hour, up to a maximum of 24 times. The retry data packets are still generated based on standardized resources in the local FHIR resource library, without re-extracting the original tables from the source system.

[0083] The event-driven routing layer 200 supports resource types including, but not limited to, Patient, Observation, Encounter, Condition, and Immunization; supported action types include creation, update, and deletion. For deletion events, FHIR resources with logical deletion or state change flags can be pushed, as determined by the target system's routing policy. Cross-system exchange packets preferentially include standard FHIR fields; source system custom extensions can be stripped, dumped, or carried as optional extensions, but the target system is not required to parse custom extension fields.

[0084] Privacy Computation Layer 300 and Lightweight PSI Implementation: The privacy computation layer 300 includes a coordinator 301, a node agent 302, and a secure aggregation module. The coordinator is deployed at the central node of the regional health network and is used for global model initialization, model distribution, and encrypted parameter aggregation. The node agent is deployed at each primary public health system side, and is a lightweight containerized deployment with a CPU usage of no more than 1 core and a memory usage of no more than 1GB. The secure aggregation module 303 supports homomorphic encrypted aggregation of model update parameters exchanged between nodes, or adds differential privacy noise before parameter uploading. The lightweight PSI between nodes is implemented based on a Bloom filter. The size of the Bloom filter is dynamically configured from 1MB to 10MB according to the number of patients in the primary institutions. The data volume of a single round of alignment is less than 10MB, and the peak bandwidth usage is no more than 1Mbps.

[0085] Node agent 302 is a lightweight container that can be implemented based on federated learning frameworks such as FATE, with CPU usage not exceeding 1 core and memory usage not exceeding 1GB. Vertical federated learning training can employ logistic regression, XGBoost, or LSTM. Taking logistic regression as an example, the learning rate can be 0.01, with 10 iterations, the Adam optimizer, and a batch size of 32.

[0086] The secure aggregation module 303 can employ Paillier homomorphic encryption with a key length of 2048 bits; or differential privacy Laplace noise with a configurable scale of 0.1. Model update parameters or encrypted gradients undergo homomorphic encryption or differential privacy processing before transmission, ensuring that the original gradients or original sample features do not leave the institution's local security domain. Cross-node communication can be further encrypted using TLS.

[0087] PSI is implemented using Bloom filters. For institutions with fewer than 10,000 patients, the Bloom filter size can be 1MB; for institutions with 10,000 to 100,000 patients, the Bloom filter size can be 5MB; and for institutions with more than 100,000 patients, the Bloom filter size can be 10MB. The data size for a single round of alignment is less than 10MB, and the peak bandwidth is no greater than 1Mbps. Each node encodes its local stable aligned pseudonym set into a Bloom filter and sends the filter to coordinator 301 or other participating nodes; the receiver queries the filter using its local stable aligned pseudonyms to obtain the intersection candidate set, and then determines the common training sample set through a lightweight confirmation process.

[0088] This method avoids directly transmitting patient identifiers in plaintext and also avoids excessive transmission overhead caused by the generic encrypted ID list PSI in high-patient scenarios.

[0089] Method steps implementation:

[0090] The standardized process sequentially executes adapter reading, mapping engine transformation, terminology standardization, and privacy anonymization, outputting an FHIR data object. Mapping configuration supports hot updates, eliminating the need to restart services when a new system is integrated.

[0091] During the event routing process, if a push fails, the data can be written to a local retry queue and retried according to a preset strategy. Cross-system sharing does not involve full data synchronization; it only pushes standardized FHIR data based on event triggers.

[0092] After the privacy computation step is completed, the global model is distributed to each participating node for local inference or risk assessment. Raw business data remains within the domain throughout the process; nodes only exchange encrypted model parameters or gradients.

[0093] Example A: Comparison Experiment of Stable Aligned Kana

[0094] In a test environment of a certain district, one community node and one hospital node were selected, with a total of 100,000 patients in each node, of which approximately 85,000 were patients shared across institutions. Comparative Example A1 used direct identifier plaintext alignment, achieving a 100% common sample identification rate, but with high privacy risks. Comparative Example A2 only used "institution code + date + local key" salted SHA-256 identification. Due to the different hash values ​​generated for the same patient on different dates, cross-day follow-up records, test records, and joint training samples could not be stably aligned, resulting in a PSI common sample identification rate of approximately 61.2%. This invention A3 adopts a decoupling scheme between route-displaying pseudonyms and stable-aligned pseudonyms. Route-displaying pseudonyms meet the requirements of daily auditing and display de-identification, while stable-aligned pseudonyms ensure consistency for the same patient across dates within the same institution, achieving a common training sample identification rate of approximately 85.0%, and preventing the inference of original identities from stable-aligned pseudonyms between different institutions. The remaining unidentified portion mainly stems from inconsistent local patient IDs across institutions, missing follow-up records, or missing unilateral samples, which can be further improved by supplementing business primary key mapping and cleaning strategies.

[0095] Example B: Lightweight PSI Bandwidth Comparison Experiment

[0096] Three sample alignment schemes were compared within the same 100Mbps primary healthcare private network. Comparative example B1 used plaintext alignment of original patient identifiers, resulting in high data volume and non-compliance, and high peak bandwidth. Comparative example B2 used a general encrypted ID list PSI, with approximately 45MB of data per round of alignment and a peak bandwidth of approximately 6.8Mbps, which was excessively resource-intensive. This invention, B3, uses a lightweight PSI with a Bloom filter, with less than 10MB of data per round of alignment and a peak bandwidth of no more than 1Mbps. This invention, B3, dynamically configures the Bloom filter size based on the number of patients in primary care institutions: 1MB for fewer than 10,000 patients, 5MB for 10,000 to 100,000 patients, and 10MB for more than 100,000 patients. Tests show that in a vertical federated learning scenario involving multiple nodes and requiring sample alignment in each round, the PSI traffic of this invention, B3, can run in parallel with business routing and routine public health reporting traffic within the 100Mbps private network.

[0097] Example C: Comparative Experiment on Reducing Duplicate ETL with a Unified Data Foundation

[0098] Multiple community health service centers and one secondary hospital within the same district were selected, and two different solutions were used to complete quarterly data collaboration. Comparative example C1 uses traditional ETL with centralized training, extracting full or incremental data to the regional platform weekly. The quarterly cross-system data extraction volume is approximately 3.2GB / node, with an average business collaboration latency of hours to days, and the original data leaves the domain. This invention, C2, uses a unified FHIR data base, event routing, and local training. Event-triggered pushes are used, and training utilizes local FHIR data. The quarterly cross-system data extraction volume is approximately 120MB / node / month, with an average business collaboration latency of approximately 1.2 seconds, and the original data does not leave the domain. Comparative example C1 requires data to be extracted, cleaned, and transformed from the source system for each model training or shared analysis; in this invention, after the unified FHIR data base is generated, event routing and federated learning training directly consume this local FHIR data, eliminating the need for repeated extraction of the original tables.

[0099] Example D: Low-overlap longitudinal federated learning enhancement experiment

[0100] Community nodes possess features such as age, gender, blood pressure, and follow-up records, while hospital nodes possess features such as blood glucose, blood lipids, and laboratory test results. The feature dimension overlap rate is approximately 28%, classifying it as a low-overlap vertical federation scenario. This means that the feature dimensions held by each node have limited overlap, and common patient samples aligned using stable-aligned pseudonyms are used for joint training. Comparative example D1 was trained only locally by hospital nodes, without using cross-institutional data, and its global model AUC was approximately 0.76. Comparative example D2 is a standard vertical federation but without stable pseudonym optimization, using plaintext or date salt value alignment, and its global model AUC was approximately 0.81. This invention's D3 uses stable-aligned pseudonyms plus lightweight PSI to align common patient samples, and performs SMOTE enhancement on local minority class or boundary samples, resulting in a global model AUC of approximately 0.87.

[0101] Specific Implementation Example 1: Collaborative Scenario for Risk Warning of Hypertension Complications

[0102] In the community system, the patient "Zhang San, male, 65 years old, follow-up blood pressure 150 / 90, chief complaint of dizziness for 3 days" is converted into FHIR resources through a standardization layer. After the community doctor enters the follow-up record, the event capture unit captures the Observation creation event, and the service call unit 203 pushes the Observation resource to the hospital LIS system via the FHIR API. In this embodiment, the push delay is approximately 1.2 seconds, with a success rate of 100%. At the end of the quarter, training of the hypertension complication prediction model is initiated. Community nodes and hospital nodes align common patient samples through PSI and use homomorphic encrypted gradient interaction. In this embodiment, the common training sample rate is approximately 85%, and the global model AUC reaches approximately 0.87.

[0103] Specific Implementation Example 2: Cross-Institutional Data Sharing Scenario in Maternal and Child Health Care

[0104] The community maternal and child health care system is connected to the district maternal and child health hospital's prenatal examination system. In the prenatal examination results, fundal height can be mapped to the obstetric physical examination or fundal height related LOINC code. If the standard vocabulary does not cover the specific institution's field, the institution's local extended code can be used; abdominal circumference can be mapped to LOINC 8280-0 or other abdominal circumference related LOINC or local extended codes.

[0105] After a community doctor completes a prenatal checkup, an Encounter creation event is triggered, and the system pushes the FHIR data packet to the maternal and child health hospital system. At the end of the year, a maternal anemia risk model is jointly trained, with only encrypted parameters uploaded. In this example, the screening accuracy is improved by approximately 20% relative to the baseline, and the recall rate is improved by approximately 18%.

[0106] Specific Implementation Example 3: Regional Infectious Disease Monitoring and Early Warning Scenario

[0107] In outpatient records, "fever and cough" are converted to FHIR Observation and Condition resources. Body temperature is mapped to LOINC 8310-5, and cough is mapped to SNOMED CT 49727002.

[0108] After a doctor enters a suspected case of infectious disease, a Condition creation event is triggered, and the system pushes the FHIR data to the district CDC in real time. In this example, the early warning response time has been reduced from approximately 24 hours to minutes, and the early warning accuracy rate is approximately 98%.

[0109] Specific Implementation Example 4: Cross-Institutional Data Sharing Scenario for Planned Immunization

[0110] Vaccination records are converted into FHIR resources such as Patient, Immunization, and Observation, and vaccine codes can be mapped to the CVX coding system. Taking the novel coronavirus vaccine registration scenario as an example, CVX 207 can be used as an exemplary vaccine code, identified in the FHIR through the system http: / / hl7.org / fhir / sid / cvx; the actual system supports dynamic mapping of the corresponding CVX code according to the type of vaccine administered.

[0111] After the community doctor completes the vaccination, the Immunization creation event is triggered. The system pushes the FHIR data packet to the CDC system, and the CDC updates the regional vaccination rate statistics in real time.

[0112] It should be understood that those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A collaborative management system for multi-system data interoperability and privacy computing in primary public health, characterized in that, The system is applicable to at least two heterogeneous systems in the following scenarios: resident health record system, chronic disease follow-up management system, maternal and child health care system, and planned immunization system. The low-resource scenario includes: the system is deployed on a grassroots health private network with a bandwidth of no more than 100Mbps, and the server configuration of each participating node is no more than 4 cores and 8G; the construction manufacturers, technical architectures, and data standards of each of the heterogeneous systems are different. The system includes: The data normalization layer is configured to read raw data from multiple heterogeneous primary public health systems and convert it into a unified FHIR format dataset according to the HL7 FHIR R4 standard, forming a unified data foundation for cross-system routing and local federated learning training. During the conversion process, the data normalization layer generates two types of de-identified identifiers and replaces the plaintext of direct identifiers with corresponding pseudonyms when outputting the FHIR format dataset. One type is a routing display pseudonym used for event routing and cross-system display, and the other is a stable alignment pseudonym used for longitudinal federated learning sample alignment. This stable alignment pseudonym ensures that the same patient remains consistent across dates within the same institution, and that different institutions cannot infer the original identity from the stable alignment pseudonym. An event-driven routing layer, connected to the data standardization layer, is configured to monitor preset business events in the grassroots public health business flow. When the preset business event meets the routing conditions defined by the Subscription resource based on HL7 FHIR R4, the corresponding FHIR format dataset is encapsulated into a data exchange packet, and the FHIR RESTful API of the target system is called to send the encapsulated data exchange packet to the target system. The cross-system sharing process does not perform periodic full data synchronization and does not require the target system to parse custom extended fields. The privacy computing layer is configured to respond to cross-system data analysis requests by distributing a global model to each participating node through a regional central coordinator. Each node performs local training of longitudinal federated learning based on locally stored FHIR format datasets through a lightweight node agent, and only exchanges model update parameters or encrypted gradients protected by homomorphic encryption or differential privacy through the coordinator or secure inter-node channels. Each node determines a common training sample set based on the stable aligned pseudonyms through the intersection of lightweight privacy sets (PSI). The original business data is kept in the local security domain of each node. The FHIR format dataset serves as a unified input for both event-driven routing and vertical federated learning training. The data flowing across systems includes standardized FHIR intermediate data and encrypted model update parameters.

2. The system according to claim 1, characterized in that, The route display pseudonym is generated by salting the direct identifier using a SHA-256 hash that includes the organization code, current date, and local key material; The stable alignment pseudonym uses a pseudonym identifier generated based on the institution code, fixed local key material, and the patient's local number within the institution, ensuring that the same patient remains consistent across dates within the same institution.

3. The system according to claim 1, characterized in that, The unified data foundation includes FHIR resource repositories or FHIR data object caches deployed in the local security domains of each organization; The event-driven routing layer directly reads the FHIR format dataset to generate routing data exchange packets, and the privacy computing layer directly reads the FHIR format dataset for feature extraction and local training, without repeatedly extracting and transforming the original data from the source system.

4. The system according to claim 1, characterized in that, The data standardization layer includes an adapter sublayer, a mapping engine, and a terminology standardization unit; The adapter sublayer adapts to the database interface, service interface, or file interface of heterogeneous systems; the mapping engine loads a dynamically updatable YAML format mapping configuration file to map source system fields to FHIR resource fields; The terminology standardization unit standardizes non-standard medical terms into standard terms such as SNOMED CT, LOINC, ICD-10, or CVX.

5. The system according to claim 4, characterized in that, The terminology standardization unit uses a pre-trained BiLSTM-CRF model to parse unstructured text such as chief complaint and present medical history, extracts medical entities, and maps the extracted medical entities to the SNOMED CT, LOINC, or ICD-10 standard terminology sets before filling them into the corresponding FHIR resource fields. The BiLSTM-CRF model is pre-trained on a Chinese medical entity recognition dataset and fine-tuned for primary healthcare texts.

6. The system according to claim 1, characterized in that, The event-driven routing layer includes an event capture unit, a routing policy library, and a service invocation unit. The routing policy library defines routing rules based on the standard fields of criteria, status, channel.endpoint, channel.payload, and channel.type of the Subscription resource in HL7 FHIR R4. The event capture unit captures business events using at least one of the following methods: database binlog monitoring and business system API interception, and identifies business action types including creation, update, and deletion.

7. The system according to claim 1, characterized in that, The privacy computing layer includes a coordinator, node agents, and a security aggregation module; The coordinator is deployed at the central node of the regional health network and is used for global model initialization, model distribution, and encrypted parameter aggregation. The node agent is deployed on the side of each grassroots public health system. It is a lightweight containerized deployment with a CPU usage of no more than 1 core and a memory usage of no more than 1GB. The security aggregation module supports homomorphic encrypted aggregation of model update parameters exchanged by each node, or adds differential privacy noise before the parameters are uploaded. Lightweight PSI between nodes is implemented based on Bloom filters. The size of the Bloom filter is dynamically configured from 1MB to 10MB according to the number of patients in primary care institutions. The data volume of a single round of alignment is less than 10MB, and the peak bandwidth usage is no more than 1Mbps.

8. The system according to claim 1, characterized in that, The vertical federated learning framework is configured to handle scenarios where the feature spaces of each node are different. Community nodes hold demographic and follow-up features, while hospital nodes hold laboratory and examination features. Each node exchanges encrypted identifiers generated based on stable aligned pseudonyms through lightweight PSI to determine a common training sample set, and then exchanges encrypted gradients to complete training; When the features of community nodes and hospital nodes have low overlap, common patient samples are aligned through PSI, and the expressive power of single-node models is enhanced by combining local samples. Then, joint training is completed by using encrypted model parameter interaction.

9. The system according to claim 1, characterized in that, It also includes a privacy desensitization module, configured to de-identify direct identifiers during the data mapping and transformation process; The route display pseudonyms are used for event routing, cross-system display, and daily auditing. The stable alignment pseudonyms are used for vertical federated learning sample alignment and do not participate in the calculation of the daily changing route display salt value, thereby ensuring the stability of PSI alignment.

10. A collaborative management method for multi-system data interoperability and privacy computing in primary public health, characterized in that, This method is applicable to at least two heterogeneous systems among resident health record systems, chronic disease follow-up management systems, maternal and child health care systems, and planned immunization systems in low-resource-rich grassroots settings. The low-resource-rich grassroots settings include: the method is deployed on a grassroots health private network with a bandwidth of no more than 100Mbps, and each participating node server has a configuration of no more than 4 cores and 8GB of RAM; the method includes: Standardized procedures: Read raw data from multiple heterogeneous primary public health systems, and reorganize the raw data into a unified FHIR data object according to the HL7 FHIR R4 standard to form a unified data foundation for event routing and federated learning training; during the transformation process, generate route display pseudonyms and stable alignment pseudonyms, and replace the plaintext of direct identifiers with the corresponding pseudonyms when outputting FHIR data objects. The route display pseudonyms change with the date, and the stable alignment pseudonyms ensure that the same patient remains consistent across dates within the same institution. Event routing steps: Monitor the grassroots public health business process. When a business event that meets the preset trigger conditions is detected, according to the routing strategy defined based on the FHIR Subscription standard, the FHIR data object is encapsulated into a data exchange packet and sent to the preset target address through the FHIR RESTful API. The cross-system sharing process does not perform periodic full data synchronization and does not require the target system to parse custom extended fields. Privacy computation steps: Receive data analysis tasks, the central coordinator distributes the global model, each node performs local training using local FHIR data objects through a lightweight node agent, and only exchanges model update parameters or encrypted gradients protected by homomorphic encryption or differential privacy through the coordinator or secure inter-node channels; each node aligns common samples through a lightweight PSI based on Bloom filters. The original business data is retained in the local security domain of each node, and the FHIR data object serves as the unified data foundation for event routing and federated learning training.

Images