File synchronization method and platform for multiple HIS systems

Abstract

The invention discloses a file synchronization method and platform for multiple HIS systems, and relates to the field of medical communication, and the method comprises the steps: responding to a file establishment request of a patient, determining a target HIS system, and generating a unique main index identifier; sending the unique main index identifier to a target HIS system, wherein the target HIS system is used for generating filing information; based on the filing information, a filing service message is issued to a message queue service, the message queue service is used for sending the filing service message to a corresponding non-target HIS system, and each non-target HIS system is used for determining archive information and writing the archive information back to the unified identity platform; acquiring multiple pieces of archive information, and determining patient archive data in each piece of archive information; and merging all the patient file data, and generating a patient main index based on the merged patient file data. The method can effectively solve the problem of dispersion of multi-system patient files, realizes real-time synchronization of patient data, and improves the medical service efficiency.

Description

Technical Field

[0001] This application relates to the field of medical communication, and more particularly to a method and platform for synchronizing files in multiple HIS systems. Background Technology

[0002] With the deepening development of medical informatization, modern hospitals have generally established multiple information systems to support different business needs. These systems include hospital information systems, electronic medical record systems, medical imaging systems, laboratory information systems, and radiology information systems. Each system plays an important role in its respective professional field, but due to differences in technical standards and the diversification of suppliers, data silos generally exist between these systems, seriously affecting the continuity and integrity of medical services.

[0003] Currently, each HIS system uses an independent patient identification system, meaning the same patient may have different patient IDs in different systems. When a patient visits multiple departments or hospitals, the system cannot automatically identify the same person, leading to duplicate records and data fragmentation, resulting in scattered patient files across multiple systems. For example, if a patient updates their contact information in the HIS system, this change may not be synchronized to other systems in a timely manner, causing data version inconsistencies, severely reducing the efficiency of medical services, and potentially posing a threat to patient safety.

[0004] Therefore, there is an urgent need for a method that can effectively solve the problem of scattered patient records across multiple systems, achieve real-time synchronization of patient data, and improve the efficiency of medical services. Summary of the Invention

[0005] This application provides a method and platform for synchronizing patient records across multiple HIS systems, which effectively solves the problem of scattered patient records across multiple systems, enables real-time synchronization of patient data, and improves the efficiency of medical services.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: Firstly, a method for file synchronization across multiple HIS systems is provided, applied to a unified identity platform. The unified identity platform connects to multiple HIS systems through a preset interface. The method includes: In response to a patient's request to establish a medical record, the target HIS system is determined based on a preset routing table, and a unique master index identifier is generated. Send a unique master index identifier to the target HIS system, whereby the target HIS system uses the unique master index identifier to generate filing information and send the filing information to the unified identity platform; Based on the filing information, a filing service message is published to the message queue service. The message queue service is used to receive and save the filing service message and send the filing service message to the corresponding non-target HIS system. Each non-target HIS system is used to determine the file information based on the filing service message and write the file information back to the unified identity platform. Acquire archive information written back from multiple non-target HIS systems and identify patient archive data in each archive information; Merge all patient profile data and generate a master patient index based on the merged patient profile data.

[0007] In one possible implementation of the first aspect, all patient record data are merged, and a patient master index is generated based on the merged patient record data, including: Merge all patient record data using an Oracle temporary table; The weighting strategy is dynamically loaded into the memory cache, and the priority order of the weight fields in the merged patient profile data is determined based on the weighting strategy. The primary index for patients is created by prioritizing the weight field.

[0008] In another possible implementation of the first aspect, the weighting strategy is dynamically loaded into a memory cache, and the priority order of the weight fields in the merged patient profile data is determined based on the weighting strategy, including: Read the weight strategy configuration information from the preset configuration file; Load the weight strategy configuration information into the Redis memory cache to improve the access efficiency of the weight strategy; Parse patient record data, extract patient personal data, and use patient personal data as candidate weight fields; According to the weighting strategy, assign a corresponding weight value to each candidate weight field; The priority order of weight fields in patient record data is determined based on the order of their weight values.

[0009] In another possible implementation of the first aspect, a primary index for patients is established by prioritizing the weight field, including: The distribution characteristics of patient record data in the Oracle temporary table were analyzed, and the weight field combination for high-frequency queries was determined based on the distribution characteristics. Create a composite index based on the combination of weighted fields and the priority sorting of weighted fields; Configure the storage parameters for the composite index, including the index tablespace, fill factor, and parallelism configuration. Use the configured composite index as the patient's primary index.

[0010] In another possible implementation of the first aspect, in response to a patient registration request, a unique master index identifier is generated, including: The system parses the patient's file creation request to obtain the patient's basic information and then checks in the preset patient file database to see if there is a patient record with the same basic information. If no identical patient records exist, create a patient profile in the local database and generate a unique primary index identifier for the patient profile.

[0011] In another possible implementation of the first aspect, the target HIS system generates filing information based on a unique master index identifier and sends the filing information to a unified identity platform, including: The target HIS system determines the patient's basic information based on the unique primary index identifier, creates patient file records in the internal patient database, and uses the unique primary index identifier as a foreign key for association; The target HIS system generates local patient IDs and establishes a mapping relationship between local patient IDs and unique master index identifiers; The target HIS system encapsulates the patient registration information, which includes the local patient ID, registration status, and registration timestamp. The target HIS system will send the registration information to the unified identity platform.

[0012] In another possible implementation of the first aspect, a filing service message is published to the message queue service based on the filing information, including: Parse the registration information to obtain the local patient ID and registration status; When the registration status is successful, a registration service message is constructed based on the local patient ID. The registration service message includes a unique master index identifier, basic patient information, and target HIS system identifier. Identify the list of non-target HIS systems whose information needs to be synchronized and generate a corresponding message topic for each non-target HIS system; The document creation service message is published to the message queue service via the message queue interface.

[0013] In another possible implementation of the first aspect, each non-target HIS system determines the archive information based on the archiving service message, including: For any non-target HIS system, subscribe to and receive filing service messages from the message queue service; The non-target HIS system parses the registration service message to obtain a unique master index identifier and basic patient information; Non-target HIS systems perform patient record creation operations in the internal database based on a unique master index identifier and basic patient information, generating local patient record records. Non-targeted HIS systems create patient profile information based on local patient records. This information includes the local patient ID, profile creation time, and system identifier.

[0014] In another possible implementation of the first aspect, the method further includes: In response to receiving a patient information query request, the system parses the patient information query request and obtains the patient identification information; Based on the patient identification information, query the corresponding unique primary index identifier in the primary index data table; Based on the unique master index identifier, send patient record query requests to multiple HIS systems associated with it; It aggregates patient profile information from multiple HIS systems and returns the aggregated complete patient profile information to the query request initiator.

[0015] Secondly, this application provides a unified identity platform, which includes a cloud server and a client. The client is used to send a request to the cloud server, and the cloud server is used to execute the above-described operation steps of the file synchronization method for multiple HIS systems according to the request.

[0016] Through the aforementioned technical solution, a globally unique identity is generated for each patient using a unique master index identification mechanism, replacing the independent patient ID systems of each HIS system and fundamentally eliminating the problem of identity confusion for the same patient across different systems. Secondly, by connecting the unified identity platform with preset interfaces of each HIS system, standardized data interaction between systems is achieved, breaking down data silos caused by differences in technical standards. When a patient registers in any system, the unified identity platform automatically pushes the registration information to all relevant systems via message queue services, ensuring real-time consistency of patient information and avoiding duplicate registrations and data version inconsistencies. Through a mechanism for writing back patient information and merging patient data, patient information scattered across various systems is integrated into a unified patient master index, achieving centralized management and real-time synchronization of patient data. Thus, when patient information changes in any system, it can be promptly synchronized to other systems through the unified identity platform, ensuring the continuity and integrity of medical services, significantly improving the efficiency of medical services, and reducing patient safety risks.

[0017] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0018] Figure 1 A flowchart illustrating a file synchronization method for multiple HIS systems provided in this application embodiment; Figure 2 This is a diagram of a unified identity platform architecture provided for an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0020] It should be noted that if the embodiments of this application involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of each component in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0021] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0022] Figure 1 The illustration schematically shows a flowchart of a file synchronization method for multiple HIS systems according to an embodiment of this application. Figure 1 As shown in the figure, this application provides a method for synchronizing files across multiple HIS systems, applied to a unified identity platform. The unified identity platform is connected to multiple HIS systems through a preset interface. The method may include the following steps.

[0023] S110. In response to a patient’s record-keeping request, determine the target HIS system based on the preset routing table and generate a unique master index identifier. S120. Send a unique master index identifier to the target HIS system, wherein the target HIS system uses the unique master index identifier to generate filing information and send the filing information to the unified identity platform. S130. Based on the filing information, publish the filing service message to the message queue service. The message queue service is used to receive and save the filing service message and send the filing service message to the corresponding non-target HIS system. Each non-target HIS system is used to determine the file information based on the filing service message and write the file information back to the unified identity platform. S140. Obtain the archive information written back from multiple non-target HIS systems and determine the patient archive data in each archive information; S150. Merge all patient record data and generate a patient master index based on the merged patient record data.

[0024] In this embodiment, the unified identity platform acts as a central coordination hub, establishing standardized connections with multiple HIS systems. Figure 2 A diagram illustrating the unified identity platform architecture provided in an embodiment of this application is shown. (Refer to...) Figure 2 The unified identity platform includes a request processing module, an identifier generator, a message queue interface, a data merging engine, and a master index manager. The request processing module is used to process step S110, the identifier generator is used to generate unique master index identifiers, the message queue interface is used to process step S130, the data merging engine is used to process steps S140 and S150, and the master index manager is used to maintain patient master index data.

[0025] When a patient registration request is received, the unified identity platform first performs in-depth parsing and verification. Registration requests typically contain basic patient information, such as name, date of birth, gender, and contact information. The platform first performs format verification and integrity checks on this information to ensure the accuracy and standardization of the data.

[0026] After successful verification, the most suitable target HIS system is determined to handle the registration request. The selection of the target HIS system is based on various factors, including the patient's department, medical institution affiliation, and business type. For example, if the patient is registering as an outpatient, the platform will select the outpatient management system as the target HIS system; if the patient is an inpatient, the inpatient management system will be selected. The platform maintains an intelligent routing table that records the mapping relationship between different business scenarios and corresponding HIS systems. After determining the target HIS system, the platform calls its built-in unique identifier generator to create a globally unique master index identifier. This identifier uses a composite generation strategy combining the UUID algorithm with timestamps and institution codes to ensure global uniqueness in a distributed environment. The generated unique master index identifier format is HIS_ + institution code + _ + timestamp + _ + random sequence number, for example, HIS_001_20241127151254_ABC123. This identifier not only guarantees uniqueness but also includes time and institution information, facilitating subsequent data tracking and management.

[0027] The unified identity platform sends a unique master index identifier and related patient information to the target HIS system through a pre-defined standardized interface. This interface adopts a RESTful API design, supports data transmission in JSON format, and ensures standardized access for HIS systems from different vendors. The sent data packet includes fields such as the unique master index identifier, basic patient information, record type, and priority. Upon receiving the request, the target HIS system first verifies the validity and correctness of the unique master index identifier, and then checks its internal database to see if a patient record corresponding to that identifier already exists. If it does not exist, the target HIS system creates a new patient record locally based on the received patient information, and simultaneously generates a local patient ID conforming to its own system specifications.

[0028] During the creation process, the target HIS system establishes a unique mapping between a primary index identifier and the local patient ID. This mapping is stored in an associated table and includes fields such as the primary index identifier, local patient ID, creation time, update time, and status identifier. After the record is created, the target HIS system generates detailed record creation information and sends it back to the unified identity platform. This information includes the record creation result status (success / failure), local patient ID, record creation timestamp, error messages (if any), and data integrity checksum. This information is transmitted back to the unified identity platform via secure HTTPS, ensuring the security and integrity of data transmission. This step achieves standardized data interaction between the unified identity platform and the target HIS system, ensuring the correct creation and identification association of patient records in the target system.

[0029] Based on the registration information returned from the target HIS system, the unified identity platform constructs a standardized registration service message and publishes it to the message queue service. The platform first parses the registration information, extracting key fields such as registration status, local patient ID, and registration time, and performs data verification to ensure the accuracy of the information. If the registration status is successful, the platform constructs a registration service message containing complete patient information. This message uses JSON format and includes fields such as a unique master index identifier, basic patient information, target HIS system identifier, registration timestamp, message version number, and checksum. The message queue service uses message middleware technology.

[0030] The platform creates a corresponding message topic for each non-target HIS system to ensure accurate message delivery. When publishing a message, the platform sets parameters such as message priority, expiration time, and retry strategy to ensure reliable message transmission. After receiving the filing service message, the message queue service persists it and distributes it to the corresponding non-target HIS systems according to preset routing rules. Each non-target HIS system subscribes to its own corresponding message topic, and automatically triggers consumption processing logic when a new message arrives. The message queue also provides a message acknowledgment mechanism to ensure that each message is processed correctly, and automatically retries messages that fail to process, maximizing the reliability of data synchronization. Through this process, asynchronous and reliable propagation of filing information is achieved among multiple HIS systems, laying the foundation for subsequent archival information collection.

[0031] Following step S130, the following steps can be used to determine the documentation status. Specifically: Establish a two-way communication handshake mechanism, determine the filing status of the target HIS system through heartbeat detection, and retry when the filing status is in a failed state.

[0032] In other words, after the unified identity platform sends a unique master index identifier to the target HIS system and receives the filing information, it needs to further confirm whether the filing operation has been successfully completed and establish a continuous status monitoring mechanism to ensure the reliability and integrity of the filing process. Specifically, after sending the filing request, the unified identity platform requires the target HIS system to return a filing confirmation response, using a request-response-confirmation three-way handshake mode to ensure that both parties have a consistent understanding of the filing status. A unique session ID is assigned to each filing request to track the status changes throughout the filing process. The unified identity platform periodically sends heartbeat packets to the target HIS system to detect the system connection status and service availability. A heartbeat interval is set; if no response is received within the specified time, it is considered a connection anomaly. The target HIS system carries the current filing operation status information in the heartbeat response, including: filing progress (e.g., initialization, data verification, data writing, index update, completion) and processing timestamp. Based on the heartbeat detection results, the filing status is divided into the following categories: Success status: The data creation operation was completely successful, and the data has been correctly written to the database; In progress: The file creation operation is being performed, and the system is responding normally; Failure status: Failure to create a file, including data validation errors, database write failures, etc. Timeout status: The file creation operation has not been completed within the preset time; Abnormal status: The system is unresponsive or returns abnormal information.

[0033] Finally, the registration status information is synchronized in real time to the status management module of the unified identity platform to update the registration status field in the patient's master index table, and status change notifications are sent to relevant business systems. A system alarm is triggered when multiple consecutive heartbeat detection failures occur.

[0034] Each non-target HIS system receives patient record creation service messages through a message queue subscription mechanism and creates corresponding patient record entries locally based on the message content. Each non-target HIS system is configured with a message consumer program to listen for new messages in the message queue in real time.

[0035] Upon receiving a patient registration service message, the consumer program first verifies the message's integrity, including message format checks, checksum verification, and timestamp validity checks. After successful verification, the non-target HIS system parses the message content and extracts key data such as the unique master index identifier and basic patient information. Next, each HIS system executes the patient registration operation in its internal database. This process includes data format conversion, business rule verification, and duplicate checks. Since different HIS systems may have different data structures and business rules, each system adapts the patient information according to its own specifications. After registration is complete, each non-target HIS system generates a local patient ID and establishes a mapping relationship with the unique master index identifier. Subsequently, each system creates registration information feedback data, including fields such as local patient ID, registration time, system identifier, registration status, and data version number. This registration information is sent back to the unified identity platform through a pre-defined write-back interface. Upon receiving the returned registration information from each system, the unified identity platform summarizes, organizes, and verifies the data. The platform checks the integrity and consistency of the written-back data and records the response time and processing status of each system.

[0036] For systems that fail to write back or time out, the platform will initiate a retry mechanism or send an alarm notification. This step enables the synchronous creation of patient file information across all relevant HIS systems, providing a complete data foundation for subsequent data merging.

[0037] Following S140, the following steps may also be taken: A distributed transaction coordinator manages data consistency among multiple HIS systems, and a two-phase commit strategy is adopted to ensure the atomicity of all HIS system filing operations.

[0038] In other words, when the unified identity platform publishes the filing service message to the message queue service, it needs to ensure that all HIS systems participating in the filing process either successfully file or roll back the filing operation to avoid data inconsistency where some systems file successfully while others fail.

[0039] The specific implementation includes: initiating a distributed transaction, with the unified identity platform acting as the transaction coordinator, initiating a global transaction when publishing the filing service message, and assigning a unique transaction ID to the transaction.

[0040] The first phase is as follows: a transaction preparation request is sent to all non-target HIS systems to inquire whether the filing operation can be performed; each HIS system checks its own resource status, data integrity, and business rules; if the filing can be performed, the relevant resources are locked and a ready response is returned; if the filing cannot be performed, a preparation failure response is returned.

[0041] The second phase is as follows: If all HIS systems return ready, the coordinator sends a commit command, and each system officially executes the documentation operation and releases locked resources; if any HIS system returns a failure to be ready, the coordinator sends a rollback command, and all systems undo the executed operations and release resources.

[0042] This distributed transaction management mechanism can effectively solve the data consistency problem in a multi-HIS system environment, ensure that patient records remain synchronized across all systems, and improve the reliability and data integrity of the entire medical information system.

[0043] After collecting all patient record information written back from non-target HIS systems, the unified identity platform executes a data merging process. First, all collected patient record data needs to be preprocessed, including data cleaning, format standardization, and duplicate detection. Because different HIS systems may have different data formats, the platform needs to convert all data to a unified standard format. The data merging process employs a conflict resolution strategy. When discrepancies are found between different systems for the same patient, the platform determines the final merging result based on preset priority rules and data quality assessment algorithms. For example, for patient contact information, the platform prioritizes data with the most recent update time; for medical record information, it comprehensively considers the authority and completeness of the data source.

[0044] After data merging, the platform generates a comprehensive patient master index record. The patient master index contains key fields such as complete patient identity information, local ID mapping relationships across systems, data version control information, and last update time. The master index employs a hierarchical storage structure, with core identity information stored in a high-performance database to support fast queries, while detailed profile data is stored in a distributed storage system. The platform also establishes a multi-dimensional index structure for the patient master index, supporting fast retrieval based on various methods such as name and phone number. The generated patient master index is synchronized to all HIS systems in real time, ensuring that all systems can access the latest unified patient identity information. Through this step, the unified integration of patient profile data scattered across multiple systems is successfully achieved, establishing a complete patient master index system.

[0045] This embodiment eliminates the problem of inconsistent patient identification across different systems by introducing a globally unique master index identifier mechanism, achieving unified management of patient identities across systems. The application of message queue services ensures the real-time and reliable nature of data synchronization, guaranteeing consistent data transmission even in high-concurrency scenarios. Data merging effectively handles data conflicts and format differences between different systems, generating a high-quality patient master index. Furthermore, this solution possesses excellent scalability and compatibility, adapting to the access needs of HIS systems from different vendors and with different technical architectures. After implementing this solution, medical institutions can achieve real-time synchronous updates of patient information, avoiding duplicate record creation and data version inconsistencies, significantly improving the efficiency of medical services.

[0046] In one embodiment of this example, all patient record data are merged, and a patient master index is generated based on the merged patient record data, including the following steps: S210. Merge all patient record data using an Oracle temporary table; S220: Dynamically load the weighting strategy into the memory cache, and determine the priority order of the weight fields in the merged patient record data based on the weighting strategy; S230. Establish the patient master index by prioritizing the weight field.

[0047] Oracle temporary tables serve as the core storage medium for data merging and processing, storing all patient record data collected from multiple HIS systems. The creation of temporary tables utilizes Oracle database's global temporary table technology, providing session-level data isolation and an automatic cleanup mechanism.

[0048] When creating a temporary table, the first step is to define a complete table structure, including basic patient information fields such as patient name, date of birth, gender, contact number, and home address, as well as system-related fields such as source system identifier, local patient ID, data version number, creation time, and update time. The table structure is designed using a wide table model, which can accommodate various data formats and field types from different HIS systems.

[0049] The data insertion process employs batch insertion technology. Patient record data collected from various HIS systems is standardized according to predefined format conversion rules and then inserted into a temporary table in batches. Each batch contains 500-1000 records, ensuring insertion efficiency while avoiding excessive transaction overhead. During the data insertion process, data quality checks are performed, including verification of the integrity of required fields, data format standardization, and logical consistency. Any data quality issues discovered are logged in an anomaly log table for subsequent data cleanup and repair. The temporary table is also configured with parallelism parameters to support multi-threaded concurrent insertion operations, significantly improving the processing efficiency of large batches of data. The use of Oracle temporary tables enables centralized storage and efficient management of patient record data.

[0050] After merging all patient record data through an Oracle temporary table, a real-time data synchronization channel can be established to listen for data change events in each HIS system via a WebSocket long connection and update the patient record data in the temporary table in real time.

[0051] The weighting strategy configuration information is stored in an XML or JSON format configuration file, containing the importance assessment rules and calculation formulas for various patient profile fields. The configuration file adopts a hierarchical structure, divided into multiple dimensions such as basic weight configuration, business rule weight, data quality weight, and timeliness weight. The basic weight configuration defines the basic importance of different fields; for example, the name weight is set to 0.8, and the contact number weight is 0.6. Business rule weights consider the specific needs of medical operations; for example, patient information in the emergency department has a higher weight than that in general outpatient clinics. Data quality weights are evaluated based on the completeness and accuracy of the data; data with higher completeness receives a higher weight. Timeliness weights are dynamically adjusted according to the data's update time; the most recently updated data receives a time decay coefficient.

[0052] The weight strategy loading process first reads the configuration file, and then loads the weight strategy information into high-speed memory using Redis memory caching technology. The Redis cache uses a hash table structure to store the weight strategy, with key-value pairs formatted as field names corresponding to their respective weight values.

[0053] When determining the priority of weighted fields, all patient personal data fields are first extracted from a temporary table as candidate weighted fields. Then, a corresponding weight value is assigned to each field according to the loaded weighting strategy. The weight value calculation formula is: Final Weight = Base Weight × Business Rule Coefficient × Data Quality Coefficient × Timeliness Coefficient. After calculation, the fields are sorted from high to low weight values ​​to generate a priority list. This sorted list will serve as an important basis for subsequent index building and data merging, ensuring that important fields are processed first and queries are efficient.

[0054] Building a primary index for patients based on priority sorting of weighted fields can optimize query performance and improve data merging efficiency. The index building process first requires in-depth analysis of the distribution characteristics of patient record data in the Oracle temporary table, including key indicators such as data volume, field value distribution, and query access patterns. Data distribution characteristic analysis utilizes Oracle's statistical information collection function, using the DBMS_STATS package to collect detailed statistical information for tables and columns, including the number of rows, the number of unique values, the proportion of null values, and data skewness.

[0055] Based on the above statistical information, we can identify the weighted field combinations of high-frequency queries, such as queries combining phone numbers and birth dates.

[0056] After determining the combination of frequently queried fields, a composite index is created by prioritizing the weighted fields. The fields in the composite index are strictly ordered according to their weight priority from highest to lowest, with the field with the highest weight serving as the leading column. This maximizes the index's query efficiency. The composite index uses a B-tree structure and supports various query modes, including range queries, equality queries, and prefix queries. Key parameters for index storage configuration include the selection of the index tablespace, the setting of the fill factor, and the configuration of parallelism. The parallelism configuration is optimized based on the number of CPU cores on the server, supporting parallel index scanning and parallel index maintenance operations. In summary, this significantly improves the query performance of temporary tables, providing efficient data access support for the subsequent generation of the primary patient index.

[0057] The application of Oracle temporary tables in this implementation provides an efficient and stable storage platform for large-scale patient record data. Its session-level isolation ensures data processing security and consistency, while batch insertion and parallel processing mechanisms significantly improve data loading efficiency. The dynamic weighting strategy loading mechanism utilizes Redis memory caching technology to achieve fast access and real-time updates of weighting rules, and the multi-dimensional weighting calculation model ensures the scientific validity and accuracy of the data merging results. The creation of composite indexes, based on data distribution characteristic analysis and high-frequency query pattern recognition, maximizes query performance optimization, and storage parameter configuration and parallelism settings further improve index access efficiency. The entire data merging process significantly shortens the processing time for large-scale patient record data while ensuring data quality. It not only solves the performance bottleneck problem in traditional data merging processing but also ensures the business rationality of the merging results, achieving rapid integration of patient record data.

[0058] In one embodiment of this example, dynamically loading the weighting strategy into the memory cache and determining the priority order of the weight fields in the merged patient record data based on the weighting strategy includes the following steps: S310. Read the weight strategy configuration information from the preset configuration file; S320. Load the weight strategy configuration information into the Redis memory cache to improve the access efficiency of the weight strategy. S330. Parse patient record data, extract patient personal data, and use patient personal data as candidate weight fields; S340. According to the weighting strategy, assign corresponding weight values ​​to each candidate weight field; S350. Based on the order of weight values, determine the priority sorting of weight fields in patient record data.

[0059] The default configuration file stores weighting strategy configuration information, including weighting rules and calculation logic, in XML or JSON format. The configuration file also includes the definition of the weight calculation formula, using a weighted average algorithm. Furthermore, the configuration file reading process employs streaming parsing technology to avoid memory overflow issues when loading large files, and supports a hot-update mechanism, allowing new weighting strategies to take effect without restarting the application. This step enables flexible configuration and dynamic management of weighting strategies, providing a complete rule foundation for subsequent weight calculations.

[0060] When weight strategy configuration information is loaded into Redis, it is organized using a hierarchical storage structure. Basic weight information is stored in a hash data structure with keys in the format weight:basic:fieldname and values ​​representing the corresponding weight values. Business scenario weight coefficients are stored in an ordered set, with the scenario name as a member and the weight coefficient as a score, supporting fast sorting and range queries by weight. Data quality weights and timeliness weights are stored in separate hash structures. Redis is also configured with connection pool management to support high-concurrency weight strategy query requests; the connection pool size is dynamically adjusted based on the expected concurrency. A cache preheating mechanism automatically loads commonly used weight strategy information when the application starts, avoiding latency on first access.

[0061] The parsing process for patient record data first involves performing structured analysis on the patient record data stored in an Oracle temporary table. This analysis uses a data dictionary and metadata to identify the data type, length, constraints, and other attributes of each field. The parsing engine then uses reflection to dynamically retrieve the table's structural information, including column names, data types, nullability, default values, and other detailed attributes.

[0062] The extraction of patient personal data is based on predefined field classification rules, dividing the fields in the patient's file into multiple categories, including basic personal information, contact information, medical information, and system information. Basic personal information includes fields such as name, date of birth, gender, ethnicity, and occupation; contact information includes fields such as phone number, home address, emergency contact, and email address; medical information includes fields such as blood type, allergy history, past medical history, and medication records; and system information includes fields such as patient ID, creation time, update time, and data source. The field extraction process uses regular expressions and keyword matching technology, which can correctly identify field names with different naming conventions, such as patient_name, patientName, and other formats of patient name fields.

[0063] The weight allocation process based on the weight strategy first iterates through all candidate weight fields extracted in step S330, performing a detailed weight calculation process for each field. The weight calculation employs a four-dimensional comprehensive evaluation model, including basic weight, business scenario weight, data quality weight, and timeliness weight. Basic weights are obtained by querying the `weight:basic` hash table in the Redis cache, retrieving the corresponding basic weight value based on the standardized name of the field. If a field does not exist in the basic weight configuration, a default weight value of 0.5 is used and recorded in the weight calculation log for subsequent optimization reference. The calculation of business scenario weights needs to consider the current business context. For example, in an emergency scenario, the contact number field will receive an additional scenario bonus coefficient. Business scenario identification is based on identifier fields such as department information, visit type, and urgency level in the patient's file data, determining the current business scenario type through a preset business rule mapping table. The calculation of data quality weights is based on the integrity of the field data. Integrity is quantified by the proportion of non-null values ​​in the statistical field, calculated as: Integrity Score = Number of Non-Null Values ​​ / Total Number of Records.

[0064] The timeliness weight is calculated based on the last update time of the data, using an exponential decay function: Timeliness coefficient = e (-λ×t) Where λ is the decay coefficient and t is the number of days since the current time. The final weight value is calculated using a weighted product model. This step assigns a scientifically reasonable weight value to each candidate weight field, ensuring the accuracy and business applicability of the weight allocation.

[0065] The priority ranking of fields is determined based on weight values. The ranking process first collects all candidate weight fields and their corresponding weight values ​​calculated in step S340, constructing a complete data structure containing information such as field name, weight value, field type, and business importance. The ranking algorithm sorts the fields according to their numerical values. After ranking, a priority ranking list of weight fields is generated, containing detailed information such as field name, weight value, ranking position, and field type. The ranking list also generates output in various formats, including JSON for program calls, XML for configuration management, and CSV for data analysis. To improve subsequent efficiency, the ranking results are cached in Redis with appropriate expiration times and update strategies.

[0066] The configuration file-driven weight strategy management mechanism provided in this implementation offers flexible weight rule configuration capabilities, supports multi-dimensional weight calculation and dynamic strategy adjustment, and meets the differentiated weight requirements in complex medical business scenarios. The application of Redis memory caching can effectively improve the access efficiency of weight strategies.

[0067] In one embodiment of this invention, the patient master index is established by prioritizing the weight field, including the following steps: S410. Analyze the distribution characteristics of patient record data in the Oracle temporary table, and determine the weight field combination for high-frequency queries based on the distribution characteristics; S420. Create a composite index based on the combination of weighted fields and the priority sorting of weighted fields; S430. Set the storage parameters for the composite index. The storage parameters include the index tablespace, fill factor, and parallelism configuration. S440. Use the configured composite index as the patient's primary index.

[0068] In the analysis of the distribution characteristics of patient record data in Oracle temporary tables, Oracle database statistical information collection and data mining techniques were used for in-depth analysis. The data distribution characteristic analysis first collected detailed statistical information of the temporary tables using the DBMS_STATS package, including macro-level indicators such as the total number of rows, average row length, number of data blocks, and space usage. For each field, the collected statistical information included detailed indicators such as the number of unique values ​​(NDV), the proportion of null values, data skewness, maximum value, minimum value, and average value.

[0069] Quantitative analysis of data distribution characteristics identifies valuable field combinations for querying. Data distribution characteristic analysis includes field selectivity analysis, the aforementioned data skewness analysis, and field correlation analysis. Field selectivity is measured by the proportion of unique values ​​in a field; the formula is: Selectivity = Number of unique values ​​ / Total number of records. Fields with higher selectivity are more suitable as query conditions because they can filter data more effectively. Data skewness analysis assesses query efficiency by calculating the evenness of field value distribution; fields with lower skewness are more suitable for indexing. Skewness is calculated as the ratio of standard deviation to mean: Skewness = Standard deviation / Mean. Field correlation analysis identifies frequently used field combinations; field pairs with a correlation coefficient greater than 0.7 are considered strongly correlated and suitable for creating composite indexes.

[0070] Within valuable field combinations, high-frequency queries are identified. Specifically, query pattern identification involves analyzing Oracle's AWR reports and SQL execution plans to statistically analyze the query frequency and performance of different field combinations. High-frequency query identification employs a sliding window algorithm, counting the frequency of various query patterns over the past 30 days. Query patterns with frequencies exceeding a threshold are marked as high-frequency queries.

[0071] In this embodiment, after determining the weighted field combination for high-frequency queries, the number of connections for each HIS system can be dynamically adjusted through the database connection pool, and database resources can be adaptively allocated according to the load of each HIS system. Specifically, the steps are as follows: S1. The unified identity platform collects key performance indicators of each HIS system in real time through the load monitoring module. Key performance indicators include CPU utilization, memory usage, disk I / O load, number of database connections, number of active connections, number of waiting connections, query response time, transaction processing speed, network latency, and bandwidth usage; S2. Calculate the system load weight value. Based on the collected performance indicators, a weighted algorithm can be used to calculate the load weight value of each HIS system; S3. According to the load weight value, the database connection pool parameters of each HIS system are dynamically adjusted. The specific adjustment strategies are as follows: Low load system (weight value < 30%): Increase the connection pool size to improve concurrent processing capabilities; Medium load system (30% ≤ weight value < 70%): Maintain the current connection pool configuration; High load system (weight value ≥ 70%): Reduce the connection pool size to avoid system overload. S4: Implement an adaptive resource allocation strategy as follows: reallocate idle connections from low-load systems to high-load systems; prioritize routing new query requests to low-load HIS systems; cache query results from high-load systems for a longer period of time; S6: when the load of any HIS system increases within a preset duration, trigger an alarm and enable a standby connection pool or switch to a standby database.

[0072] The dynamic connection pool management mechanism described above can effectively improve the utilization efficiency of database resources, ensure that each HIS system can maintain good performance under different load conditions, and avoid system bottlenecks caused by uneven resource allocation.

[0073] Composite indexes, created based on weighted field combinations and priority sorting, can be implemented using Oracle's B-tree indexing technology and field sorting strategies. The creation process first determines the list of fields to be included in the index. Based on the high-frequency query weighted field combinations identified in step S410, the 3-5 most frequently queried field combinations are selected as candidate fields for the composite index. The order of fields in the index strictly follows the priority sorting of the weighted fields, with the field with the highest weight serving as the leading column, followed by other fields. This sorting strategy ensures that the index can maximize support for various query patterns, especially prefix and range queries. Composite indexes use Oracle's B-tree structure, supporting efficient equality queries, range queries, and sorting operations.

[0074] The index creation process employs online DDL technology to avoid blocking ongoing data operations. Index naming follows standardized conventions, including table name, field names, and creation time, facilitating subsequent management and maintenance.

[0075] Precise configuration of composite index storage parameters is crucial for optimizing index performance, involving several important parameters such as index tablespace selection, fill factor settings, and parallelism configuration. The selection of the index tablespace is based on a comprehensive consideration of storage performance and capacity planning, prioritizing tablespaces configured with high-speed SSD storage to ensure low latency and high throughput for index access. Tablespace configuration includes setting the data file size, auto-expansion parameters, and maximum size limits. The initial size is set to 1.2 times the estimated index size, the auto-expansion step size is set to 100MB, and the maximum size is reasonably planned based on storage capacity. The tablespace is also configured with an appropriate block size; for index-intensive applications, a data block size of 16KB or 32KB is recommended to balance storage efficiency and I / O performance.

[0076] The fill factor setting directly affects the index's storage efficiency and maintenance performance, and is precisely calculated based on the data update frequency. For patient basic information indexes with low update frequency, a fill factor of 10% is set to maximize storage density; for contact information indexes with high update frequency, a fill factor of 20% is set to reserve sufficient space for subsequent data updates. The formula for calculating the fill factor is: Optimal fill factor = (1 - Expected update rate) × 100%, where the expected update rate is derived from historical data statistics. Parallelism configuration is optimized based on the number of CPU cores on the server and the expected query concurrency. Parallelism is set to 50%-75% of the number of CPU cores to avoid excessive resource contention. Parallelism configuration includes parallelism during index creation and parallelism during index maintenance. Higher parallelism can be set during creation to speed up creation, while the parallelism during maintenance needs to consider the impact on online business. Storage parameters also include index compression options. Enabling Oracle's advanced compression technology reduces the index's storage space usage; compression ratios can typically reach 2:1 to 4:1. The buffer pool configuration prioritizes caching index data in memory to improve access speed, and the buffer pool size is rationally allocated based on the index size and available memory. This step achieves precise optimization of the composite index storage parameters, ensuring that the index maintains optimal performance under various workloads.

[0077] Finally, the configured composite index is set as the patient's primary index.

[0078] The composite index in this implementation is created based on the priority sorting of weighted fields and query frequency analysis, constructing an optimal index structure. The arrangement order of the index fields ensures the best support effect for various query modes. The configuration of storage parameters, by comprehensively considering storage performance, data update frequency, etc., achieves the optimal configuration of index storage, improves the storage efficiency and query performance of the index, thereby significantly improving the overall efficiency of patient record data merging and processing, providing strong technical support for high-performance data processing of medical information systems, and ultimately realizing rapid retrieval and efficient integration of patient record data.

[0079] In one embodiment of this example, in response to a patient's file creation request, a unique master index identifier is generated, including the following steps: S510. Parse the patient's file creation request to obtain the patient's basic information, and determine whether there is a patient record with the same basic information in the preset patient file database. S520. If no identical patient records exist, create a patient profile in the local database and generate a unique primary index identifier for the patient profile.

[0080] Parsing and duplicate detection of patient registration requests ensures the uniqueness of patient identities. The parsing process begins by validating the format and analyzing the structure of the received request data. Registration requests are typically transmitted in JSON or XML format and contain basic patient information. After extracting the basic patient information, a duplicate detection is performed in a pre-defined patient database. This duplicate detection uses a matching algorithm, initially performing an exact match by checking the uniqueness of fields in the patient's basic information, such as birthday and personal ID. Records with identical fields are directly identified as duplicates. In cases of mismatch, fuzzy matching can be performed, thus achieving precise parsing of patient identity information and high-accuracy duplicate detection.

[0081] After confirming that there are no duplicate patient records, a patient profile is created in the local database, and a unique primary index identifier is generated for each patient profile. Specifically, the patient profile creation process first establishes complete basic patient information records in the local database. The patient profile table contains a complete field structure, covering multiple dimensions such as basic patient information, extended information, and system information. The data insertion process employs a transaction processing mechanism to ensure data atomicity and consistency. If an exception occurs during insertion, all operations are automatically rolled back to guarantee database integrity. The unique primary index identifier is generated using an identifier generation algorithm, with the following format: organization prefix (3 digits) + year (4 digits) + month and day (4 digits) + hour, minute, and second (6 digits) + random sequence (6 digits) + checksum (2 digits), for a total length of 25 characters.

[0082] In this embodiment, the existence of patient records with the same basic information as the patient is determined in the preset patient file database. By combining precise matching and fuzzy matching strategies, various forms of duplicate patient records are effectively identified, significantly reducing the occurrence of duplicate records. The unique master index ensures the absolute uniqueness and traceability of each patient identifier, effectively reducing the rate of duplicate patient records and improving the accuracy of patient identification, thus significantly improving the quality and efficiency of medical services.

[0083] In one embodiment of this invention, the target HIS system generates filing information based on a unique master index identifier and sends the filing information to a unified identity platform, including the following steps: S610. The target HIS system determines the patient's basic information based on the unique primary index identifier, creates patient file records in the internal patient database, and uses the unique primary index identifier as a foreign key association. S620, The target HIS system generates local patient IDs and establishes a mapping relationship between local patient IDs and unique master index identifiers; S630, the target HIS system encapsulates the registration information, which includes the local patient ID, registration status and registration timestamp; S640, the target HIS system will send the filing information to the unified identity platform.

[0084] The target HIS system determines basic patient information and creates patient records based on a unique master index identifier. The determination of basic patient information is achieved by calling the query interface of the unified identity platform. The target HIS system uses the unique master index identifier as the query key and sends a patient information query request to the unified identity platform. The query request adopts a RESTful API format, including fields such as identifier value, query type, timestamp, and digital signature, ensuring the security and reliability of the query. After receiving the query request, the unified identity platform retrieves the corresponding basic patient information from the master index database and returns it to the target HIS system through an encrypted channel. The creation process of patient records in the internal patient database first involves format conversion and field mapping of the basic patient information according to the data model of the target HIS system. Different HIS systems may have different data structures and naming conventions; the conversion process requires field mapping according to pre-configured mapping rules, for example, mapping the patient_name field of the unified platform to the name field of the HIS system.

[0085] The unique primary index identifier is stored as a foreign key in the associated table, which contains fields such as local patient record ID, unique primary index identifier, association time, and status identifier, establishing a reliable mapping relationship between local data and global identifier.

[0086] The target HIS system generates local patient IDs and establishes mapping relationships to achieve internal patient identification management. The mapping relationships are managed through a mapping table with a bidirectional index design, supporting lookup of the unique primary index identifier using the local patient ID and vice versa. The mapping table's fields include mapping ID, local patient ID, unique primary index identifier, creation time, update time, status identifier, and version number, supporting complete lifecycle management of the mapping relationships. The mapping relationships are maintained using an optimistic locking mechanism, controlling concurrent updates through version numbers to avoid data conflicts. The mapping table is also configured with an appropriate index structure, including unique indexes for both the local patient ID and the unique primary index identifier, ensuring optimized query performance. Through this step, a comprehensive local patient identification management system and a reliable mapping relationship maintenance mechanism are established, achieving seamless conversion between global and local identifiers.

[0087] The target HIS system encapsulates patient registration information, including the local patient ID, registration status, and registration timestamp. The encapsulation process first collects key data from the registration operation, including the local patient ID generated in step S620, the execution status of the registration operation, and detailed timestamp information. The local patient ID serves as the primary identifier for the registration information, used for precise location of patient records in subsequent data synchronization and query operations. The registration status is determined based on the execution result of the registration operation, categorized into several types, including SUCCESS (successful registration), FAILED (failed registration), PARTIAL (partial success), and PENDING (in progress). The status judgment logic comprehensively evaluates the execution results of each stage, including patient file creation, mapping relationship establishment, and data verification; only when all stages are successfully completed is the status marked as SUCCESS. The registration timestamp uses high-precision time recording, accurate to the millisecond level, ensuring the accuracy and traceability of the time information.

[0088] The target HIS system sends registration information to the unified identity platform. The process begins by establishing a secure communication connection with the unified identity platform, using HTTPS protocol for data transmission to ensure encryption and security. Upon receiving the registration information, the unified identity platform returns a response, including processing status, response time, and confirmation code. The target HIS system parses the response and determines success based on the returned status code. Upon successful transmission, the target HIS system updates its local registration status record, marking that the patient's registration information has been successfully synchronized to the unified identity platform. Simultaneously, a detailed operation log is generated, recording the sending time, response status, processing time, and other information, providing data support for subsequent troubleshooting and performance analysis. This process ensures reliable transmission and status feedback of registration information, completing the full data interaction flow between the target HIS system and the unified identity platform.

[0089] This implementation establishes a mapping relationship between local patient IDs and unique master index identifiers, thereby creating a comprehensive local patient identifier management system and a reliable mapping relationship maintenance mechanism. It achieves seamless conversion between global and local identifiers and enables real-time synchronization of patient data through data interaction between the target HIS system and the unified identity platform.

[0090] In one embodiment of this example, publishing a filing service message to a message queue service based on the filing information includes the following steps: S710: Parse the registration information to obtain the local patient ID and registration status; S720. When the registration status is successful, construct a registration service message based on the local patient ID. The registration service message includes a unique master index identifier, basic patient information and target HIS system identifier. S730. Determine the list of non-target HIS systems whose information needs to be synchronized and generate a corresponding message topic for each non-target HIS system. S740: Publish the document creation service message to the message queue service through the message queue interface.

[0091] Parsing the filing information requires format verification and structural analysis of the information received from the target HIS system. Filing information is typically transmitted in JSON or XML format and contains multi-level data structures and field information. Format verification includes syntax correctness checks, character encoding verification, and data integrity checks to ensure that the received data conforms to predefined specifications. Structural analysis identifies the location and content of key information by parsing the hierarchical relationships and field mappings of the data.

[0092] The process of extracting local patient IDs needs to be adapted to the data format of different HIS systems. Since different vendors' HIS systems may use different field naming and data organization methods, multiple naming formats such as localPatientId, patient_id, and local patient number can be identified through field mapping rules.

[0093] The identification of filing status adopts a multi-level status mapping mechanism. Different HIS systems may use different status representation methods, such as numerical encoding, string description, Boolean values, etc. The status mapping table predefines various possible status representations and their corresponding standard status values. For example, 1, SUCCESS, success, true, etc. are all mapped to the success status, while 0, FAILED, failure, false, etc. are all mapped to the failure status.

[0094] Assuming the registration status is successful, a registration service message is constructed. Specifically, the message construction process first collects complete patient information based on the parsed local patient ID, and then retrieves all basic information related to the patient by querying the patient master index database of the unified identity platform.

[0095] The data collection process employs multi-table join query technology, using a unique primary index as the join key to integrate patient information scattered across different tables. During the query process, version information and last update time are also retrieved to ensure that the messages contain the latest patient information. The structure of the registration service messages adopts a hierarchical JSON format, comprising three main parts: message header, message body, and message footer. The message header contains metadata information such as message ID, message type, sending time, sender identifier, and message version. The message ID is generated using a UUID algorithm to ensure the global uniqueness of each message. The message body contains core business data. The unique primary index serves as the global identity identifier for the patient, ensuring that the recipient can accurately identify the patient's identity. Basic patient information is organized in a structured manner, including complete field names and corresponding values. The target HIS system identifier is used to identify the system initiating the registration operation, facilitating source identification and processing strategy selection by the recipient.

[0096] The message body also includes contextual information about the filing operation, such as filing time, operation type, and business scenario, providing necessary background information for the recipient's business processing. The message footer contains data integrity verification information, such as the MD5 hash value and digital signature of the message body, ensuring the integrity and security of the message during transmission. Through this step, a complete, standardized, and secure filing service message is generated, laying a solid foundation for subsequent message routing and publishing.

[0097] Determining the list of non-target HIS systems to be synchronized and generating message topics enables precise message routing. The process of determining the non-target HIS system list first retrieves information on all registered HIS systems from the unified identity platform's system registry. The system registry contains detailed information such as system identifier, system name, system type, business scope, connection status, and permission level. The system identification process compares the system identifier with the target HIS system identifier to filter out all other HIS systems, forming a preliminary candidate list of non-target systems. Further filtering of the candidate list is based on multiple criteria, including system online status, business relevance, permission level, and synchronization strategy. Online status checks use a heartbeat monitoring mechanism to confirm whether the system is in a message-receiving state; offline or faulty systems are temporarily excluded from the synchronization list.

[0098] Business relevance assessment is based on the patient's medical records and business relevance. For example, if a patient has a medical record in a certain HIS system, that system has high business relevance and should be prioritized for data synchronization. Permission level checks ensure that only systems with the appropriate permissions can receive sensitive patient information; systems with insufficient permissions will receive basic, anonymized information. Synchronization policy configuration allows administrators to set different synchronization rules for different systems, such as real-time synchronization, batch synchronization, and selective synchronization. Message topics are generated using standardized naming conventions and a hierarchical topic structure. The topic name format is patient.archive.sync.{system identifier}.{message type}, for example, patient.archive.sync.HIS001.create represents a patient profile creation message sent to the HIS001 system.

[0099] Documentation service messages are published via a message queue interface. The message queue interface is implemented using message middleware technology. Connection pooling is used to establish the interface connection, pre-creating and maintaining multiple connection instances to avoid performance impact from frequent connection establishment and release operations. The message publishing process first performs message serialization, converting the JSON format message constructed in step S720 into a byte stream format for easier network transmission and storage. Serialization also includes compression, using GZIP or LZ4 algorithms to compress the message content, reducing the amount of data transmitted over the network and storage space usage. Message publishing uses an asynchronous batch mode, packaging multiple messages into batches for sending, improving sending efficiency and throughput. The batch size is dynamically adjusted based on the average message size and network bandwidth, typically set to 100-1000 messages or 1-10MB of data.

[0100] During the publishing process, appropriate metadata is set for each message, including message key, partitioning strategy, timestamp, and expiration time. The message key is generated based on the patient's unique master index identifier, ensuring that related messages for the same patient can be routed to the same partition, guaranteeing message order. The partitioning strategy uses a consistent hashing algorithm to distribute messages evenly across different partitions, achieving load balancing and parallel processing. The message persistence configuration ensures that messages are reliably stored after publishing, preventing loss even in the event of system failure. The persistence level is set to synchronous replication mode, requiring successful writing to multiple replicas before a successful publishing confirmation is returned. The publishing process also includes retry mechanisms and error handling. When publishing fails, appropriate handling is performed based on the error type: network errors trigger automatic retries, and format errors are logged in detail and alerts are sent. The retry strategy uses an exponential backoff algorithm to avoid putting pressure on the message queue due to frequent retries.

[0101] Upon successful publication, a unique identifier and partition offset of the message are returned for subsequent message tracking and status queries. This step enables efficient publication and reliable delivery of filing service messages, ensuring that messages are promptly communicated to all relevant non-target HIS systems.

[0102] This implementation not only solves the performance bottlenecks and reliability issues in traditional message publishing, but also significantly improves the efficiency and accuracy of data synchronization between multiple systems through intelligent routing strategies and standardized message formats. It enables efficient publishing and reliable delivery of filing service messages, ensuring that messages can be delivered to all relevant non-target HIS systems in a timely manner.

[0103] In one embodiment of this invention, each non-target HIS system determines the file information based on the file creation service message, including the following steps: S810. For any non-target HIS system, subscribe to and receive filing service messages from the message queue service. S820, non-target HIS system parses the file creation service message to obtain a unique master index identifier and patient basic information; The S830 non-target HIS system performs patient record creation operations in the internal database based on a unique master index identifier and basic patient information, generating local patient record records. S840, the non-target HIS system creates file information based on local patient file records. The file information includes the local patient ID, file creation time, and system identifier.

[0104] To achieve automated data synchronization, non-target HIS systems subscribe to and receive patient record service messages from a message queue service. The message subscription process first establishes a stable connection with the message queue service, employing a long-lived connection mode to avoid frequent connection establishment and termination. The connection establishment process includes steps such as authentication, permission verification, and connection parameter negotiation, ensuring that only authorized HIS systems can subscribe to the corresponding message topics. Authentication uses API keys or digital certificates, and each HIS system is configured with unique authentication credentials to prevent unauthorized access. Permission verification is based on a pre-configured permission matrix to determine the range of message topics each system can subscribe to; for example, a specialist hospital's HIS system may only be able to subscribe to patient record messages relevant to its business.

[0105] The message topic subscription employs pattern matching technology. Subscription configuration includes key parameters such as consumer group ID, offset management strategy, and message acknowledgment mode. The consumer group ID ensures that multiple system instances of the same type can process messages in a load-balanced manner, avoiding message duplication. The offset management strategy determines the system's starting position for message consumption, allowing it to choose from the latest message, the earliest message, or a specified position. Message reception uses a push-pull hybrid model; the message queue service actively pushes messages to the subscribing system, while the system can also actively pull messages awaiting processing. Successfully received messages are temporarily stored in a local buffer, awaiting subsequent parsing and processing. This process establishes a stable and reliable message reception channel, ensuring that non-target HIS systems can promptly obtain relevant archiving service messages.

[0106] Subsequently, the non-target HIS system parses the registration service message to obtain a unique master index identifier and basic patient information. The registration service message uses a standardized JSON format and includes three main parts: a message header, a message body, and a message footer. Parsing the message header extracts metadata information such as message ID, message type, sending time, and sender identifier. This information is used for message routing, duplicate detection, and source verification. Parsing the message body extracts key data such as the unique master index identifier and basic patient information. After parsing, the extracted data is organized into standardized data objects for easy use in subsequent registration operations. This step achieves accurate parsing of the registration service message and reliable extraction of key data, providing accurate data input for subsequent patient registration operations.

[0107] The non-target HIS system performs local patient registration based on the parsed patient information, thus achieving data synchronization. It employs transactional database operations and an intelligent conflict resolution mechanism. The patient registration process first performs a duplicate check to prevent duplicate registrations caused by message duplication or system anomalies. The duplicate check performs an exact match based on a unique master index identifier, searching the system's patient master index mapping table for a record with the same identifier. If an existing record is found, the consistency of the patient's basic information is further compared to determine if a data update is necessary. Data consistency comparison uses field-level difference detection, comparing key fields one by one to identify changed fields. For discovered data differences, the latest timestamp data typically overwrites the older data.

[0108] Once it's confirmed that a new patient record needs to be created, the database insertion operation begins. Creating a patient record involves inserting data into several related tables, primarily the patient basic information table, the patient extended information table, and the primary index mapping table. The patient basic information table stores core identity information; these fields are typically set to NOT NULL constraints to ensure data integrity. The patient extended information table stores optional fields such as contact information, address information, and medical information, supporting future business expansion. The primary index mapping table establishes a unique relationship between the primary index identifier and the local patient ID; this table includes foreign key constraints to ensure referential integrity. The local patient ID is generated according to the system's internal identification specifications, using an auto-incrementing sequence or specific encoding rules to ensure uniqueness within the system. Through this step, a complete patient record is successfully created in the non-target HIS system, achieving localized storage and management of patient data.

[0109] The non-target HIS system creates file information based on local patient records. The file creation process first collects key result data from the file creation operation, including core fields such as the local patient ID generated in step S830, the execution time of the file creation operation, and system identification information. The local patient ID serves as the primary identifier for the file information, used for precise location of patient records in subsequent data queries and association operations. The ID is obtained by querying the newly created patient file record, ensuring that the most recently generated and valid identifier is retrieved. The file creation time is recorded using a high-precision timestamp format, accurate to the millisecond level, ensuring the accuracy and traceability of the time information. The system identification information includes detailed information such as the HIS system's unique identifier, system name, version information, and deployment location, used to indicate the source and processing environment of the file information. The system identifier is obtained from the system configuration file or registration information, ensuring the accuracy and consistency of the identifier. Through this step, complete and accurate file information is successfully created, fully preparing for data feedback to the unified identity platform.

[0110] This implementation method creates complete patient records in a non-target HIS system, realizes localized storage and management of patient data, and creates complete and accurate record information, which fully prepares for data feedback to the unified identity platform, and ultimately realizes automatic synchronization and unified management of patient records between multiple HIS systems.

[0111] In one embodiment of this invention, the method further includes the following steps: S910. In response to receiving a patient information query request, parse the patient information query request and obtain the patient identification information; S920. Based on the patient identification information, query the corresponding unique primary index identifier in the primary index data table; S930. Based on the unique master index identifier, send patient record query requests to multiple HIS systems associated with it; S940. Summarize patient record information from multiple HIS systems and return the summarized complete patient record information to the query request initiator.

[0112] Upon receiving a patient information query request, the unified identity platform first performs a comprehensive parsing and verification process. In practice, patient information query requests may originate from multiple sources, including doctor workstations, nurse station terminals, mobile medical applications, third-party medical systems, or patient self-service terminals. Query requests are typically transmitted using standard HTTP or SOAP protocols and include the query initiator's authentication information, query permission level, and patient identification information. Upon receiving the query request, the platform first performs identity verification and permission checks to ensure the query initiator has legitimate access to the relevant patient information. Next, the platform parses the structure of the request message and extracts key information fields. Patient identification information may exist in various forms, including patient name, ID card number, mobile phone number, medical card number, medical insurance card number, or a known local patient ID from a HIS system. The platform identifies and extracts these different types of patient identification information according to preset parsing rules.

[0113] Based on the parsed patient identification information, the unified identity platform performs a precise query operation in the main index data table to obtain the corresponding unique main index identifier. The main index data table is the core data structure of the entire unified identity platform, stored using a high-performance relational database (such as Oracle or MySQL), and contains the basic information of all registered patients and their corresponding unique main index identifiers.

[0114] The query process employs a multi-level matching strategy to ensure the accuracy and completeness of the query results. First, the platform attempts to use the most precise identifier, such as a unique card number. If an exact match is successful, the corresponding unique primary index identifier is returned directly. If an exact match fails, the platform uses a fuzzy matching algorithm, combining multiple fields such as patient name, date of birth, and contact number for a combined query. The fuzzy matching algorithm uses edit distance and phonetic matching algorithms to handle data discrepancies caused by data entry errors or information updates. To improve query efficiency, the primary index table has multiple composite indexes, including a primary key index based on the ID card number, a composite index based on name and date of birth, and a secondary index based on contact information. During the query process, the platform automatically selects the optimal index strategy based on the query conditions and utilizes the database's query optimizer to improve query performance. When multiple candidate matches exist, the platform calculates the matching score for each candidate result according to preset weight rules and selects the result with the highest score as the final unique primary index identifier.

[0115] Based on the obtained unique master index identifier, the unified identity platform sends patient profile query requests to multiple HIS systems associated with that identifier to collect complete patient profile information in each system. In practice, the platform first queries the master index association table, which records the mapping relationship between each unique master index identifier and the local patient ID in each HIS system. Through this mapping relationship, the platform can determine which HIS systems to query and which local patient ID to use for the query in each system. Next, the platform sends query requests to all relevant HIS systems in parallel. Each query request is customized according to the interface specifications of the target HIS system, including setting the correct API endpoint, authentication method, request format, and parameter structure. To ensure the real-time performance and reliability of the query, the platform sends query requests asynchronously and concurrently, and sets reasonable timeouts and retry mechanisms for each request. The query request includes the local patient ID, query scope (such as time period, data type, etc.), and the permission information of the query initiator. After receiving the query request, each HIS system retrieves the corresponding patient's profile information from its respective database, including basic information, medical records, examination results, medication records, surgical records, and other types of medical data. To protect patient privacy and data security, each HIS system returns data within a specified range based on the query initiator's permission level, and sensitive information is anonymized. Query results are returned to the unified identity platform in a standardized data format (such as HL7 FHIR or JSON) to ensure data consistency and interoperability.

[0116] After receiving patient profile information from multiple HIS systems, the unified identity platform performs comprehensive data aggregation and integration processing, ultimately generating complete patient profile information and returning it to the requesting party. The data aggregation process first verifies the format and checks the completeness of the response data from each system to ensure data validity and consistency. The platform then categorizes and organizes patient information from different systems according to chronological order, importance level, and data type, based on preset data fusion rules. For conflicting data items, the platform employs an intelligent data fusion algorithm that considers factors such as data source credibility, update time, and completeness to determine the final data value used. For example, if a patient's contact number differs across systems, the platform prioritizes the data with the most recent update and the highest source credibility.

[0117] During the aggregation process, the platform also performs data deduplication to prevent identical medical records from appearing repeatedly in the final results. To provide a better user experience, the aggregated patient profile information is organized according to a unified data structure, including modules such as basic patient information, historical medical records, examination and test results, medication records, and allergy history. The platform will appropriately filter and format the aggregated data based on the query initiator's permissions and needs. Finally, the complete patient profile information will be returned to the query requester in a standardized format. Simultaneously, the platform will record log information for this query, including query time, query initiator, query scope, and a summary of the returned data, for subsequent auditing and analysis.

[0118] This implementation effectively solves the data silo problem in traditional medical information systems, enabling medical staff to access complete patient medical records across multiple systems through a single query portal. The highly automated and intelligent query process significantly improves the efficiency and quality of medical services, reducing the time cost for medical staff to switch between different systems. Simultaneously, a unified identity recognition and data integration mechanism ensures the consistency and accuracy of patient information, avoiding the risk of medical errors caused by data fragmentation. This method also possesses good scalability and compatibility, adapting to HIS systems from different vendors and with different technical architectures, providing a flexible solution for the informatization construction of medical institutions. Through real-time data aggregation and intelligent conflict resolution, this method can provide more comprehensive and reliable data support for clinical decision-making, thereby improving the overall level of medical services and patient satisfaction.

[0119] This application also provides a unified identity platform, which includes a cloud server and a client. The client is used to send a request to the cloud server, and the cloud server is used to execute the operation steps of the above-described file synchronization method for multiple HIS systems according to the request.

[0120] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0121] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0122] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0123] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0124] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0125] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0126] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0127] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0128] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for synchronizing archives across multiple HIS systems, characterized in that, Applied to a unified identity platform, which connects to multiple HIS systems through a pre-defined interface, the method includes: In response to a patient's request to establish a medical record, the target HIS system is determined based on a preset routing table, and a unique master index identifier is generated. Send a unique master index identifier to the target HIS system, whereby the target HIS system uses the unique master index identifier to generate filing information and send the filing information to the unified identity platform; Based on the filing information, a filing service message is published to the message queue service. The message queue service is used to receive and save the filing service message and send the filing service message to the corresponding non-target HIS system. Each non-target HIS system is used to determine the file information based on the filing service message and write the file information back to the unified identity platform. Acquire archive information written back from multiple non-target HIS systems and identify patient archive data in each archive information; Merge all patient profile data and generate a master patient index based on the merged patient profile data.

2. The method according to claim 1, characterized in that, Merge all patient record data and generate a master patient index based on the merged patient record data, including: Merge all patient record data using Oracle temporary tables; The weighting strategy is dynamically loaded into the memory cache, and the priority order of the weight fields in the merged patient profile data is determined based on the weighting strategy. The patient master index is created by prioritizing the weight field.

3. The method according to claim 2, characterized in that, The weighting strategy is dynamically loaded into the memory cache, and the priority order of the weight fields in the merged patient profile data is determined based on the weighting strategy, including: Read the weight strategy configuration information from the preset configuration file; Load the weight strategy configuration information into the Redis memory cache to improve the access efficiency of the weight strategy; Parse patient record data, extract patient personal data, and use patient personal data as candidate weight fields; According to the weighting strategy, assign a corresponding weight value to each candidate weight field; The priority order of weight fields in patient record data is determined based on the order of their weight values.

4. The method according to claim 2, characterized in that, The primary index for patients is created by prioritizing the weight field, including: The distribution characteristics of patient record data in the Oracle temporary table were analyzed, and the weight field combination for high-frequency queries was determined based on the distribution characteristics. Create a composite index based on the combination of weighted fields and the priority sorting of weighted fields; Configure the storage parameters for the composite index, including the index tablespace, fill factor, and parallelism configuration. Use the configured composite index as the patient's primary index.

5. The method according to claim 1, characterized in that, Generate a unique primary index identifier, including: The system parses the patient's file creation request to obtain the patient's basic information and then checks in the preset patient file database to see if there is a patient record with the same basic information. If no identical patient records exist, create a patient profile in the local database and generate a unique primary index identifier for the patient profile.

6. The method according to claim 1, characterized in that, The target HIS system generates registration information based on a unique master index identifier and sends the registration information to the unified identity platform, including: The target HIS system determines the patient's basic information based on the unique primary index identifier, creates patient file records in the internal patient database, and uses the unique primary index identifier as a foreign key for association; The target HIS system generates local patient IDs and establishes a mapping relationship between local patient IDs and unique master index identifiers; The target HIS system encapsulates the patient registration information, which includes the local patient ID, registration status, and registration timestamp. The target HIS system will send the registration information to the unified identity platform.

7. The method according to claim 6, characterized in that, Based on the filing information, a filing service message is published to the message queue service, including: Parse the registration information to obtain the local patient ID and registration status; When the registration status is successful, a registration service message is constructed based on the local patient ID. The registration service message includes a unique master index identifier, basic patient information, and target HIS system identifier. Identify the list of non-target HIS systems whose information needs to be synchronized and generate a corresponding message topic for each non-target HIS system; The document creation service message is published to the message queue service via the message queue interface.

8. The method according to claim 1, characterized in that, Each non-target HIS system determines the file information based on the file creation service message, including: For any non-target HIS system, subscribe to and receive filing service messages from the message queue service; The non-target HIS system parses the registration service message to obtain a unique master index identifier and basic patient information; Non-target HIS systems perform patient record creation operations in the internal database based on a unique master index identifier and basic patient information, generating local patient record records. Non-targeted HIS systems create patient profile information based on local patient records. This information includes the local patient ID, profile creation time, and system identifier.

9. The method according to claim 1, characterized in that, The method also includes: In response to receiving a patient information query request, the system parses the patient information query request and obtains the patient identification information; Based on the patient identification information, query the corresponding unique primary index identifier in the primary index data table; Based on the unique master index identifier, send patient record query requests to multiple HIS systems associated with it; It aggregates patient profile information from multiple HIS systems and returns the aggregated complete patient profile information to the query request initiator.

10. A unified identity platform, characterized in that, The unified identity platform includes a cloud server and a client. The client is used to send a request to the cloud server, and the cloud server is used to execute the operation steps of any one of the methods described in claims 1-9 according to the request.

Images